Subject: [Ipsec] doubts about IKEv2 implementation

From: "Soumya Sen" <[email-masked]>
Date: Tue, 5 Apr 2005 19:28:02 +0530

Hello,

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?

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*).

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?

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?

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"?

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?

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?

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?

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?

Q10: Am I correct to think that the outer header(HDR) in the
CREATE_CHILD_SA has the SPIs corresponding to the parent 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?

I will be glad to have your response to my doubts.

Thanking you in advance,

Soumya.

**********************************************************************************************************************************************************

This email message is for the sole use of the intended recipient(s)and may contain CONFIDENTIAL and PRIVILEGED information.
LG Soft India will not be responsible for any viruses or defects or any forwarded attachments emanating either from within
LG Soft India or outside. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender By reply email and destroy all copies of the original message.

**********************************************************************************************************************************************************

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Charlie Kaufman" <[email-masked]>
Date: Tue, 5 Apr 2005 17:55:17 -0700

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 
Sent: Tuesday, April 05, 2005 5:48 PM
To: 'Soumya Sen'
Subject: RE: doubts about the IKEv2 implementation

I've embedded comments below... Charlie

________________________________

From: Soumya Sen [mailto:[email-masked]] 
Sent: Tuesday, April 05, 2005 5:33 AM
To: Charlie Kaufman
Subject: doubts about the IKEv2 implementation

Dear Sir,

Best regards, 

Soumya Sen.

India.

IKE_INIT_SA request:

IKE_INIT_SA response:

> Yes.

> 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:
 
> 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.
 
> 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:

> 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.
 
> 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.
> Yes, except that technically it's a pair of SAs being rekeyed, so your
sentence
> should say "...deleted the SAs corresponding...".

> 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.
 
> 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).

> Yes. All IKE messages have the SPIs corresponding to the outer IKE.
 
> 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).

Thanking you in advance,

Soumya.

************************************************************************
************************************************************************
**********

This email message is for the sole use of the intended recipient(s)and
may contain CONFIDENTIAL and PRIVILEGED information.
LG Soft India will not be responsible for any viruses or defects or any
forwarded attachments emanating either from within 
LG Soft India or outside. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended 
recipient, please contact the sender By reply email and destroy all
copies of the original message.

************************************************************************
************************************************************************
**********