Subject: [IPsec] IKEv2-bis notes

From: Yaron Sheffer <[email-masked]>
Date: Thu, 28 Aug 2008 09:49:13 +0300

Hi,

the comments below refer to the previous version of the draft. But Paul 
promises me that they should still be applicable (including unchanged 
section numbers).

Thanks,

    Yaron

- Sec. 1: "intended to replace": the status WRT IKEv1 and IKEv2 is 
obviously very different. I suggest:

    [4306] has obsoleted the IKEv1 document set. The current document 
replaces [IKEv2] and [Clarif] by a single unified description of the 
IKEv2 protocol.

- Sec. 1 (editorial): is there a good reason to call Child SAs 
"CHILD_SAs" rather than "Child SAs" (why the Fortran-like underscore?). 
"That's the way 4306 has it" is not a sufficient reason.

- Sec. 1: liveness tests are described here and in Sec. 2.4 and 2.21. 
They deserve their own subsection, as well as mention of the commonly 
used name "DPD, dead peer detection".

- 1.1.2: "if there is an inner IP header" then this is not transport 
mode, contrary to the previous sentence.

- 1.1.3: this text "for the initiator to request an IP address owned by 
the security gateway for use for the duration of its SA" implies that 
the lifetime of the address is identical to that of the IKE SA. If this 
is true, it should be explicit in the text of 3.15.1.

- 1.2 "All but the headers of all the messages that follow are encrypted 
and integrity protected." This sentence is hard to understand. I 
suggest: "The messages that follow are encrypted and integrity protected 
in their entirety, with the exception of message headers."

- 1.2: Clarif-4.3 is a nit, it probably belongs somewhere else, rather 
than the first description of the protocol.

- 1.3.1: the two clarifications at the end are a bit confusing. TFC is 
negotiated separately for each peer, but non-first-fragment is 
apparently negotiated for both sides. But this is not explicity stated 
for the latter. Also, please reword "If the peer rejects the proposal of 
the SA" as "If the peer is unwilling to send or to receive non-first 
fragments".

- 1.3.2: "supplied in the SPI fields", add: "of the SA payload".

- Need a reference to 2.14 (generation of the IKE_SA crypto material) 
from both 1.2 and 1.3.2.

- 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it 
is omitted?

- 1.4: "replaced for the purpose of rekeying" - replace by "rekeyed".

- 1.4: "This is the expected way an endpoint can ask the other endpoint 
to verify that it is alive." Add: "This is often referred to as a 
liveness check, or Dead Peer Detection (DPD)".

- 1.4: "in inbound half" should be "the inbound half".

- 1.4: the section should be broken into two, maybe "The INFORMATIONAL 
Exchange" and "Deleting an SA".

- 1.6: page 17 is a bit late in the game to introduce the word "MUST".

- 1.7: I don't know what "amplifications" means. Also, the following 
paragraph (major and minor numbers) is redundant and confusing. This 
*is* the same protocol.

- 2. Clarif-7.5 is redundant, it is mentioned in 2.23.

- 2.3: The first paragraph contains an apparent contradiciton. It 
mentions that pipelining is done "if the other endpoint has indicated 
its ability to handle such requests" and then goes on to describe how a 
pipelining implementation can interoperate with a non-pipelining one. 
Which should be trivial if the pipelining side knows what the other side 
is capable of.

- 2.4: Clarif-7.9 is unclear: "however, receiving parties need to deal 
with it in other requests" - what requests? How? Why should it ever happen?

- 2.6: "needs to choose them so as to be unique identifiers of an 
IKE_SA" - why was the SHOULD demoted? Uniqueness of the SPI is essential 
to the protocol.

- 2.9 "an IP packet and matches" should be "an IP packet that matches".

- 2.9: I believe it is more appropriate to describe PFKEY as an API, 
rather than protocol.

- 2.12: "In particular, it MUST forget [...] any state that may persist 
in the state of a pseudo-random number generator that could be used to 
recompute the Diffie-Hellman secrets". This is confusing and probably 
incorrect. Any PRNG state used to generate the DH value is long past by 
the time the IKE SA is deleted. And ff it isn't, then what we are asking 
here is to reset the PRNG to a base (0-state) configuration, which is 
insecure.

- 2.12: Exponential reuse - can we give a reference on how to do it 
securely?

- 2.16: "The shared key generated during an IKE exchange MUST NOT" - it 
would be clearer to refer to the previous sentence, "This key MUST NOT".

- 2.19: INTERNAL_ADDRESS_EXPIRY is gone, but shouldn't we specify what 
the gateway should do if the address lease expires? On a related note, 
the section does not specify the lifetime of the configuration values, 
i.e. should they be renewed by the next IKE SA rekey, or 
reauthentication, or never?

- 2.22: I suggest to add the following last paragraph: In some cases 
Robust Header Compression (ROHC) may be more appropriate than IP 
Compression. The reader is referred to an extension [informational ref] 
that defines the use of ROHC with IKEv2 and IPsec.

- 2.23: in the 2nd bullet, "the location... are" ==> "is".

- 3.1 under Flags: "Presence of options are" ==> "is".

- 3.1: V flag: since no implementation has V=1 yet, can we define that 
it is also set for minor version changes? Otherwise an attacker can 
downgrade the minor version advertised by the peers, which could affect 
their functionality.

- 3.3.2: "This syntax is inherited from ISAKMP, but is unnecessary 
because the last Proposal could be identified from the length of the 
SA." Should be: "This syntax is inherited from ISAKMP, but is 
unnecessary because the last Transform could be identified from the 
length of the Proposal."

- 3.3.2: there is no explanation here or elsewhere what is meant by the 
D-H transform for ESP and AH. If nobody's using it, it should be depracated.

- 3.3.2: "tranform" - typo.

- 3.3.2: please add at the bottom of the section: "Numerous additional 
transform types have been defined since the publication of RFC 4306. 
Please refer to the IANA IKEv2 registry for details."

- 3.3.4, 2nd paragraph: many things have changed in the last few years. 
Please remove all the text starting "For example".

- 3.5: this section is extremely liberal on what access control policies 
people can implement, but that's too late to change now. However, we CAN 
at least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 
4945, pki4ipsec).

- 3.5: we mention that ID_KEY_ID is opaque and vendor specific, and then 
we have a MUST implement of ID_KEY_ID for interoperability. This is a 
contradiction.

- 3.6: it is unclear exactly which X.509 format implementations MUST 
support (presumably #4). Also, the last paragraph is unclear on whether 
4 certificate payloads or a bundle with 4 certificates MUST be supported.

- 3.12: "Writers of Internet-Drafts who wish to extend this protocol 
MUST define a Vendor ID payload to announce the ability to implement the 
extension in the Internet-Draft." The rules for notifications mean that 
this is often not needed, because you can ignore unknown notifications. 
Can we eliminate this requirement?

- 3.15.3: shouldn't we remove the whole section, and add a reference to 
the work-in-progress in IPv6 configuration?

- 5: "It is assumed that all Diffie-Hellman exponents are erased from 
memory after use.  In particular, these exponents MUST NOT be derived 
from long-lived secrets like the seed to a pseudo-random generator that 
is not erased after use." This is kind of strange: how is an 
implementation supposed to derive these exponents then?

- 5: Additional proposed text for the Security Considerations:

Admission control is critical to the security of the protocol. For 
example, IKE trust anchors must be separate from those used for other 
forms of trust, e.g. to identify trusted Web servers. Moreover, although 
IKE provides a wide leeway in defining the security policy for trusted 
peers' identity, credentials and the correlation between them, having 
such security policy defined explicitly is essential to a secure 
implementation.

Both IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator is 
authenticated. As a result, an implementation of this protocol (all 
100-odd pages!) must be completely robust when deployed on any insecure 
network. Any implementation vulnerability can and will be exploited by 
unauthenticated peers. This applies in particular to denial of service 
attacks, and we note the particular potential issue with the unlimited 
number of messages in EAP-based authentication.

- 7: last paragraph: add "Note to RFC Editor" or the poor guy/gal might 
miss it.

- Appendix C: please also mention extension notifications [N+]. Also, 
Vendor ID in the CCSA exchange.

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Aug 2008 13:23:48 +0300

I agree your other notes, just commenting few of them.

> used name "DPD, dead peer detection".

The reason it is liveness test instead of dead peer detection, is that
we are not detecting whether the other end is dead, we are detecting
whether the other end is live. If the other end is not alive, then we
will be retransmitting packets until we time out. Thats why I think
liveness test is much better term than dead peer detection. 

> is true, it should be explicit in the text of 3.15.1.

The INTERNAL_ADDRESS_EXPIRY was already removed from 3.15.1, but I
agree that we need explicit text there too. 

> - 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it 

We had this discussion April 2005, and I think we did not reach
concensus on the matter:

http://www.ietf.org/mail-archive/web/ipsec/current/msg01421.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01437.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01831.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01832.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg01833.html

Perhaps we can now reach concensus how it should be. I still think
that you MUST do Diffie-Hellman when doing IKE_SA rekey, thus
Diffie-Hellman group cannot be NONE, and KE payloads MUST be present.

If the Diffie-Hellman is not mandatory, i.e. Diffie-Hellman group can
be NONE (it cannot be left out,as the Diffie-Hellman Group transform
type is mandatory for IKE), then KE payloads would be ommitted.

The original RFC4306 text was confusing as it shared the same picture
and text for Child SA creation and rekeying of both IPsec SA and IKE
SA. The new text is much better.

> with it in other requests" - what requests? How? Why should it ever happen?

I think the text is there to say that even if other end sends
INITIAL_CONTACT as separate informational exchange or some other
IKE_AUTH request (i.e. not first), then receiving end needs to ignore
it or something (i.e. it is not fatal error to see it in other
places). I agree this text should be clarified.

> reauthentication, or never?

The needs to be renewed when new IKE SA is negotiated, they do not need
to renewed on IKE SA rekey or based on time. As there is no longer
INTERNAL_ADDRESS_EXPIRY the address lease will not expire anymore, but
if server side is using some mechanism which have address expiry, it
needs to renew it by himself, and if that fails, I think the only
thing it can do is to tear down the IKE SA, which will force other end
to restart IKE SA negotiation and request addresses again.

Reauthentication is just starting IKE SA from the start, thus it needs
to request addresses again. 

> downgrade the minor version advertised by the peers, which could affect 

There is no need, as the major and minor version numbers are
authenticated after the exchange finishes, so if attacker modifies
minor version number both ends will fail the authentication, thus SA
creation will fail. The reason it is needed for major version number,
is that in that case the responder cannot reply with authenticated
error for bigger version number, thus we need to trust unauthenticated
error and fall back to lower version. 

> D-H transform for ESP and AH. If nobody's using it, it should be depracated.

See 1.3.1 and the KE payloads there. D-H transforms are used to
provide PFS for IPsec SAs, and it is widely used.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 28 Aug 2008 13:45:35 +0300

HI Tero,

thanks for your response. See below.

    Yaron

> I agree your other notes, just commenting few of them.
Same here.
> liveness test is much better term than dead peer detection. 
No problem. I am OK with "liveness test" being the preferred name, but 
we still need to mention the commonly used synonym. And my essential 
point is, instead of mentioning it 3-4 times, we should have one section 
describing it.

[snip]
> SA. The new text is much better.
We are not changing the protocol this time (although my original comment 
did imply that), even if we don't like this "SHOULD". But then we still 
need to explain how the SA is generated if KE is not there. Sec. 2.14 
always requires the quantity "g^ir".

[snip]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 Aug 2008 13:53:43 +0300

> always requires the quantity "g^ir".

2.14 requires it, which means KE is mandatory in the initial exchange.
2.18 does not require it, which means it could be left out for IKE SA
rekey.

There is also Clarif-5.12 there explaining the situation. Perhaps we
should add pointer to 1.3.2 to 2.18?
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 28 Aug 2008 13:58:48 +0300

You are right, I missed 2.18, and a pointer to it in 1.3.2 would help.

    Yaron