[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] Few comments to draft-ietf-ipsecme-ikev2-intermediate
From: Tero Kivinen <kivinen () iki ! fi>
Date: 2021-08-01 19:42:27
Message-ID: 24838.63779.831896.747620 () fireball ! acr ! fi
[Download RAW message or body]
Valery Smyslov writes:
> Hi Tero,
>
> > I was reading the draft-ietf-ipsecme-ikev2-intermediate through and I
> > think it might be good thing to add a note at the end of section 3.3.1
> > Protection of the IKE_INTERMEDIATE messages to clarify which SK_e[i/r]
> > and SK_a[i/r] are to be used for the IKE_AUTH after all
> > IKE_INTERMEDIATE exchanges (I assume it is the latest one).
>
> Your assumption is correct.
>
> I can add the following text at the end of 3.3.1:
>
> Once all IKE_INTERMEDIATE exchanges are completed, the most recently calculated
> SK_e[i/r] and SK_a[i/r] keys are used for protection of the IKE_AUTH and all the
> subsequent exchanges.
>
> Are you OK with this?
Looks good for me.
> > Also perhaps we should have appendix showing the full protocol
> > exchange example. I.e. something like this:
> >
> > ----------------------------------------------------------------------
> >
> > Appendix A. Example of IKE_INTERMEDIATE exchange.
> >
> > This appendix contains a short example of the messages using
> > IKE_INTERMEDIATE. This appendix is purely informative; if it
> > disagrees with the body of this document, the other text is
> > considered correct.
> >
> > In this example there is one IKE_SA_INIT exchange, two
> > IKE_INTERMEDIATE key exchanges followed by the IKE_AUTH exchange to
> > authenticate the exchange. The xxx in the HDR(xxx,MID=yyy)
> > indicates the exchange type, and yyy tells the message id used for
> > that exchange. The keys used for each SK {} payload is indicated in
> > the parenthesis after the SK. Otherwise payload notation is same as
> > is used in the RFC7296.
> >
> >
> > Initiator Responder
> > -------------------------------------------------------------------
> > HDR(IKE_SA_INIT,MID=0),
> > SAi1, KEi, Ni,
> > N(INTERMEDIATE_EXCHANGE_SUPPORTED) -->
> >
> > <-- HDR(IKE_SA_INIT,MID=0),
> > SAr1, KEr, Nr, [CERTREQ],
> > N(INTERMEDIATE_EXCHANGE_SUPPORTED)
> >
> > <Generate SK_[aip][ir] and store them as SK_[aip][ir]_1, start
> > using them for SK {} payloads>
> >
> > HDR(IKE_INTERMEDIATE,MID=1),
> > SK(SK_ei_1,SK_ai_1) { ... } -->
> >
> > <Calculate IntAuth_1_I = prf(SK_pi_1, ...)>
> >
> > <-- HDR(IKE_INTERMEDIATE,MID=1),
> > SK(SK_er_1,SK_ai_1) { ... }
> >
> > <Calculate IntAuth_1_R = prf(SK_pr_1, ...)>
> >
> > <If this IKE_INTERMEDIATE did a new key exchange then update
> > SK_[aip][ir] and store them as SK_[aip][ir]_2, start using them for
> > SK {} payloads>
> >
> > HDR(IKE_INTERMEDIATE,MID=2),
> > SK(SK_ei_2,SK_ai_2) { ... } -->
> >
> > <Calculate IntAuth_2_I = prf(SK_pi_2, ...)>
> >
> > <-- HDR(IKE_INTERMEDIATE,MID=2),
> > SK(SK_er_2,SK_ai_2) { ... }
> >
> > <Calculate IntAuth_2_R = prf(SK_pr_2, ...)>
> >
> > <If this IKE_INTERMEDIATE did a new key exchange then update
> > SK_[aip][ir] and store them as SK_[aip][ir]_3, start using them for
> > SK {} payloads>
> >
> > HDR(IKE_AUTH,MID=3),
> > SK(SK_ei_3,SK_ai_3) {IDi,
> > [CERT,] [CERTREQ,]
> > [IDr,] AUTH, SAi2,
> > TSi, TSr} -->
> >
> > <-- HDR(IKE_AUTH,MID=3),
> > SK(SK_er_3,SK_ar_3) {IDr,
> > [CERT,] AUTH,
> > SAr2, TSi, TSr}
> >
> > ----------------------------------------------------------------------
> >
> > I think having such appendix would make things easier to understand.
>
> OK, will add it.
Thanks. Just make sure you read it through and verify that my
understanding of the exchange process was correct.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic