 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
I got this same question privately, and responded (see below). I’m forwarding this to the list to make sure no one else takes the time to respond. (Unless of course they have a different answer, in which case that should be on the list too!).
--Charlie
From: Charlie Kaufman
I’ve embedded comments below… Charlie
From: Soumya Sen
[mailto:soumya.sen at lgsoftindia.com]
Dear Sir,
I am a senior undergraduate student, presently undergoing industrial project training. I am trying to understand the IKEv2 protocol and went through the draft. However, I got certain doubts and interpreted certain things in my own way, but I am not sure whether the understanding is correct or flawed. I will be very grateful if you kindly take out some time to clear the doubts that I have listed below. Please explain the relevant concepts if my interpretation is wrong. Thanking you very much in advance, Best regards, Soumya Sen. India.
NOTE: Here the SA payload contents have been shown in “(…)” and the contents are separated by “;”, while the payloads are separated by “,” and proposal structures are separated by “[“ or “]”.
IKE_INIT_SA request: HDR(“A”,0), SAi1([proposal#1; protocol ID:1 (for IKE); SPI size:0; …, <transforms>], [proposal #2; protocol ID:1; SPI size:0; …, <transforms>]), KEi, Ni.
Let the IKE is assigned the SPI of value “A” from the sender’s side. Let us assume only two proposals were made initially. No SPI field is present within the proposal substructures.
IKE_INIT_SA response: HDR(“A”, “B”), SAr1([proposal#1; protocol ID:1; SPI size:0; …; <1 transforms chosen from each transform type requested >]), KEr, Nr.
Proposal number 1 was chosen and one transform of each transform type under that proposal is returned. No SPI field is present within the proposal substructures.
Q1: Am I correct to believe that *always* in the response *only one* chosen proposal is present i.e. the chosen proposal mentioning one transforms of each transform type required? > Yes.
Q2: In the case, that the responder chooses a proposal that had the proposal number #3, will the Proposal number mentioned in the responder’s SA payload be 3(i.e. mention the chosen proposal number) or mentions the proposal no. as #1 always (*because only one proposal can be selected*). > In your example, the responder’s SA proposal number would be 3. It is used to help the initiator > figure out which of his proposals was accepted. IKE_AUTH request:HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,],AUTH, SAi2([proposal#1; protocol ID:2 (for AH); SPI size:4; …,SPI value: “C”; <transforms>], [proposal #2; protocol ID:3 (for ESP); SPI size:4; …,SPI value: “D”; <transforms>]), TSi, TSr} SPIs for the SAs are proposed in the SPI fields in the Proposal Substructure. The initiator chooses the SPI values of “C” and “D” for the two proposals. Q3: Is it that the values chosen for “C” and “D” *must* be different always? > No. I would expect that in most cases C and D would not be different.> The purpose of this SPI is to allow the initiator to identify the SA in the> processing of incoming ESP or AH packets, so if the initiator sets up> multiple SAs to the same IP address it would need for the SPIs to be> different. In expected implementations, a node would use different SPIs> for each of its open SAs even to different IP addresses. The only time> the initiator would put different SPIs in proposals for the same SA would> be if it wanted to use different SPIs depending on which of the proposals> the responder accepted. Q4: In the case where we want to propose that both AH and ESP are to be used for the traffic stream, we mark both the proposals as #1. In this case will the SPI value mentioned in the proposal substructure be different for the two proposals even though the Proposal no. is 1 for both the substructure? > Probably. When using both ESP and AH, the data packets have an ESP header> encapsulated in the AH data, so there are two SPIs. I would expect these two> SPIs would be different, though IKEv2 does not require that they be.
IKE_AUTH response:HDR, SK {IDr, [CERT,] AUTH, SAr2([proposal#1; protocol ID:2 (for AH); SPI size:4; …,SPI value: “E”; <1 transforms chosen from each transform type requested>]), TSi, TSr} Proposal no.1 was chosen, the SPI value associated by the responder is “E” for this SA chosen from the offered set of SAs. Q5: Am I correct to believe that the SPI value chosen by the responder for the chosen proposal is randomly chosen to be “E”. Can it also happen to choose the same value “C”? > The responder may choose E randomly or may choose it to index> some table in the responder’s memory. E could be the same as C. Q6: Am I correct to believe that the values chosen for this SA (here “C” on sender’s side and “E” on receiver’s side) are different and two distinct SA are existing in the two directions with *same* keys and *same* agreed upon set of algorithms? > Almost. The specification is awkward because ESP and AH insist on considering> the two directions of communication to be separate SAs, but the IKE SA is> bidirectional. So IKEv2 always creates and deletes ESP and AH SAs in pairs,> and I would expect implementations to treat them as a single entity, but the> spec has to say that they are separate SAs. The algorithms must be the same> in both directions, but the keys are different. The keys for both directions are> derived from a common base key as specified in the spec.Q7: To REKEY this SA, will the sender send a CREATE_CHILD_SA request mentioning the SPI value as “E”(its inbound value) in the ‘N’ payload and the if successful both of them delete the SA corresponding to “C” on sender’s side and “E” on responder’s side?> Yes, except that technically it’s a pair of SAs being rekeyed, so your sentence> should say “…deleted the SAs corresponding…”. Q8: This CHILD created from the initial exchange may follow the protocol types of ESP, AH, both ESP & AH etc. But they can never support the option for a DH group transform type in the proposal since no KE payload can be sent along with the AUTH exchange messages. So Perfect forward secrecy(PSF) cannot be supported in this child created through initial exchange?> Perfect forward secrecy comes from forgetting the DH private key (and SK_d) no later> than when the child SA is closed. To get PFS for the initial pair of child SAs, it is> necessary to first rekey the IKE SA, forget the keying material associated with it,> and then rekey the child SA. By design, PFS does not require an additional DH> exchange, though it is allowed because some crypto people don’t believe it. Q9: While “Rekeying” it is being said that the CHILD_SA creates an equivalent SA to the one to be replaced. Does it mean that in the SA payload we send the *only* the same proposal which is the *presently existing* suite for the SA?> People have debated what the phrase means. What you describe is the normal case.> Some people read the spec as saying that you can’t change cryptographic algorithms> or traffic selectors, while others think you can. This may be clarified in a future> revision of the spec. A conservative implementation would only propose the> presently existing suite but would accept changes if requested from the other side> (because then they would interoperate with anyone). Q10: Am I correct to think that the outer header(HDR) in the CREATE_CHILD_SA has the SPIs corresponding to the parent IKE?> Yes. All IKE messages have the SPIs corresponding to the outer IKE. Q11: When we Rekey an existing IKE_SA, in the CREATE_CHILD_SA do we need to mark the protocol ID as 3 (corresponding to IKE protocol value)? If we are creating an IKE then there should be no SPI value field mentioned in the SA structure, but again it is said that “the new initiator and responder SPIs are supplied in the SPI fields in the Proposal structure in the SA payload”. I am getting confused here. Does it mean that the SA that is being created to rplace the parent IKE by using CREATE_CHILD_SA has to be AH or ESP and not an IKE protocol? > In the initial exchange setting up an IKE_SA, the proposals contain no SPIs> because the SPIs implicitly are the values in the header of the messages> negotiating the IKE_SA. When a new IKE_SA is created within a> CREATE_CHILD_SA exchange, the eight byte SPIs are included in the> SA payloads. The new SPIs will be used in messages that are cryptographically> protected with the new keys (so an implementation can know which key to use> by looking at the SPI).
I will be glad to have your response to my doubts. Thanking you in advance, Soumya.
|
_______________________________________________ Ipsec mailing list Ipsec at ietf.org https://www1.ietf.org/mailman/listinfo/ipsec