Subject: [Ipsec] Comments on draft-hoffman-ikev2bis-01.txt

From: <[email-masked]>
Date: Fri, 22 Jun 2007 16:59:39 +0200

section 1.3 and chapter 4: A CREATE_CHILD_SA exchange may be
responded with NO_ADDITIONAL_SAS.  This response is used when
responder is unwilling to accept more CHILD SAs.  It should
also be named, that this response is used when responder is
unwilling to rekey an IKE SA.
 
section 1.5: The first sentence could start "If an encrypted
IKE request packet arrives ..."  This would clarify, that
handling of strange response packets should be avoided
leaving it to retransmission, exponential backoff, and
final deletion of IKE SA to clean up any mess, because
any node can generate a mysterious response packet with
unknown SPI values.
 
section 2.1, second paragraph, last sentence: "larger than"
to be replaced with "larger than or equal to".
 
section 2.2, fifth paragraph.  I think "or it is a
retransmission of an IKE_SA (in which case the responder
ignores it)." is not needed.
 
section 2.5, eighth paragraph: During implementation
it was not a help with a fixed order.  It has been a
help to work out (a) the count on the number of 
occurrences (the cardinality) of a payload in a packet 
and (b) any relations between payloads (for example if 
KE payload present, then also SA payload must be present),
and (c) any other constraints (for example CP(CFG_REQUEST) 
may appear only in an IKE request message).
 
section 2.8.1.  The line "<-- send resp4: D(SPIb1)"
should be "<-- send resp3: D(SPIb1)".
 
section 2.10: Because PRF functions now have variable
key length, I wonder if the note "and MUST be at least
half the key size of the negotiated prf" is still
relevant.  Maybe it should be suggested, that the
nonce length should be at least half the output length
of the PRF function in order to ensure enough
entropy is provided.
 
section 2.15, eighth paragraph: The paragraph starts
"This is typically insecure because..."  I think the final
sentence of the previous paragraph should be moved and
become the start of this paragraph.
 
section 2.17. I suggest the formula for the keying
material is also described as
{ CSK_ei, CSK_ai, CSK_er, CSK_ar } = prf+(SK_d, Ni | Nr)
 
section 2.18, fourth paragraph: Because PRF functions
now have variable key length, I wonder if the final
sentence is still needed.

Christian

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

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 24 Jun 2007 13:26:03 -0700

Thanks for your continued fine-toothed review of the document! I have 
incorporated the ones that Pasi responded to earlier in the next 
draft. Some comments below.

>unwilling to rekey an IKE SA.

That would be a significant change from the current definition of 
that notification. Do other IKEv2 implementers agree that this is a 
good idea?

>any node can generate a mysterious response packet with

That wording seems to weaken the statement unnecessarily. If the IKE 
packet is encrypted and it is an unknown SPI, the receiver doesn't 
know how to decrypt it and therefore doesn't know whether it is a 
request.

>to be replaced with "larger than or equal to".

Good catch.

>ignores it)." is not needed.

Can you say why? It seems relenvant to the logic.

>may appear only in an IKE request message).

We still want to hear from many other IKEv2 developers on this.

>should be "<-- send resp3: D(SPIb1)".

Got it.

>of the PRF function in order to ensure enough

The "MUST" is there in order to get enough entropy, so it is still relevant.

>become the start of this paragraph.

Indeed.

>{ CSK_ei, CSK_ai, CSK_er, CSK_ar } = prf+(SK_d, Ni | Nr)

That is an oversimplification of the list near the end of the section 
because there might not be authentication keys.

Is the following clearer?

CURRENT:

All keys for SAs carrying data from the initiator to the responder 
are taken before SAs going in the reverse direction.

If a single protocol has both encryption and authentication keys, the 
encryption key is taken from the first octets of KEYMAT and the 
authentication key is taken from the next octets.

PROPOSED:
First, extract the key for the SA from the initiator to the responder.
Next, if there is an authentication key, extract the key for the 
authentication from the initiator to the responder.
Next, extract the key for the SA from the responder to the initiator.
Finally, if there is an authentication key, extract the key for the 
authentication from the responder to the initiator.

>sentence is still needed.

Good catch.

Again, thanks for the review. All other IKEv2 implementers should 
consider this a good nudge for them to be doing such a careful review!

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Mon, 25 Jun 2007 12:15:56 +0200

> that notification. Do other IKEv2 implementers agree that this is a
 
Maybe the responder is not allowed to send NO_ADDITIONAL_SAS,
but then the responder can send any other error notification
which (according to 3.10.1) the initiator shall understand as
rekeying failed. Is there an assumption, that rekeying of an IKE SA
cannot fail?
 
> know how to decrypt it and therefore doesn't know whether it is a
 
Whether the packet is a request or response is told in a flag in the
IKE header, and the IKE header is not encrypted.
 
> Can you say why? It seems relenvant to the logic.
 
I mistook the first situation ("it is a retransmission belonging to
an existing "half-open" IKE_SA") to be the same as the third
situation ("it is a retransmission of an IKE_SA").  The difference
is that in the third situation the Initiator has sent an IKE_AUTH
and waits for a response to the IKE_AUTH.  So yes, it is
relevant to the logic.
 
> because there might not be authentication keys.
 
The original working is OK; the proposed working is also fine.
I just wanted to add a symbolic
representation in the same way as was done for an IKE SA.
To me it is no problem that CSK_ei is named but may have
key length 0.
 
Christian