Subject: Re: [IPsec] IKEv2-bis notes

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Oct 2008 16:23:37 -0700

Sorry for the delayed reply. I am now catching up so that we can turn a -01 in before the cutoff deadline.

There are three types of responses. Each type has a different effect on the new WG issue tracker. My responses are marked with "===" at the beginning of the line.

- Done. This is now in my working copy of -01. Yaron won't fill these in the tracker.

- Not done, but take it to the list. This is not a simple editorial change or clarification, and needs to be taken to the list for discussion. Yaron will mark these in the tracker as open issues.

- Not done and disagree. Some of these are editorial changes that make things harder to understand, others are disagreements about whether they are correct. Yaron will mark these in the issue tracker as closed issues; someone can re-open them if sufficiently motivated.

At 9:49 AM +0300 8/28/08, Yaron Sheffer wrote:

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

===Not done, take this to the list. I think the current working is actually more correct than the proposed rewording.

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

===Done. Also changed "IKE_SA" to "IKE SA".

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

===Partially done. Added a sentence to 2.4 saying that liveness detection is sometimes called dead peer detection, but did not create a separate section about it because it really does warrant metion in 1, 2.4, 2.21, and 3.9.

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

===Done

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

===Not done, but will do so after more discussion. In 3.15.1, it already says:
"The requested address is valid until there are no IKE SAs between the peers. This is described in more detail in Section 3.15.3." That is different than what you say above. Which do we want?

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

===Done.

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

===Not done. This is not a nit, and is very much about what is and is not OK in the exchanges.

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

===Done.

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

==Done.

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

==Done. Added to 1.2 and 1.3, but not to the sub-sections of 1.3.

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

===Not done. This needs to be brought up as a separate thread on the mailing list with the stuff that Yaron and Tero discussed, as well as the old discussion. I am not hopeful....

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

===Done.

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

===Not done; did it in 2.4 instead, as above.

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

===Done.

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

===Done. Good catch. This was classic documentation creep.

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

===Not done. There is no other good place to do this without messing up the section numbering.

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

===Not done. "Amplification" means that some things from the earlier document are described in more detail (although not louder...). The major/minor stuff is not redundant: it is relevant to what has changed in this document, namely that it is not a protocol change. I added a short note about that.

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

===Not done. It is redundant, and is important to say in both places.

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

===Not done, definitely worth discussing on the list.

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

===Not done, needs to be discussed on the list.

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

===Done.

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

===Done.

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

===Not done, for the list.

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

===Done.

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

===Not done, need someone to provide it.

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

===Done.

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

===Not done, definitely needs more list discussion, including Tero's comments.

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

===Done.

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

===Done.

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

===Done.

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

===Not done. Bad idea, not needed.

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

===Done.

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

===Not done. This is for PFS, yes?

- 3.3.2: "tranform" - typo.

===Done.

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

===Done.

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

===Done.

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

===Not done, take to the list.

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

===Not done. Removing this from the mandatory list would be a technical change that could cause failures.

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

===Not done. Specifying a particular one at this late date would be a technical change.

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

===Not done; take to the list to see if anyone objects.

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

===Not done, but might do so after the new document moves forwards in the WG.

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

===Done. Good catch.

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

===Not done, take to the list.

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

===Done.

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

===Partially not done. The N+ is already in C.6; where else did you think it should be? I did add [V+] to C.4 and C.5.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Oct 2008 13:50:42 +0300

Paul Hoffman writes:
>     [4306] has obsoleted the IKEv1 document set. The current
>     document replaces [IKEv2] and [Clarif] by a single unified
>     description of the IKEv2 protocol. 
> 
> ===Not done, take this to the list. I think the current working is
> actually more correct than the proposed rewording.

What is the current text for that? I think we should be clear that
this document plans to obsolete the RFC4306 which already obsoleted
IKEv1.

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

I do not really see what is the contradiction there. Could you explain
better what you think is the problem there. 

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

I would interpret that text so that it should cause the other end
crash, or fail the whole negotiation even if INITIAL_CONTACT
notification is sent in the wrong message, i.e. implementations can
either silently ignore it or processes it if it comes in the wrong
message. I.e. even if it comes in IKE_SA_INIT or some other IKE_AUTH
than first, or as separate INFORMATIONAL exchange, the receiving end
of that should allow the exchange to continue.

The reason it can come in wrong exchange, is that some implmentation
sent it in wrong place as the original RFC4306 didn't specify fixed
place for it. That kind of implementation is not conformant with the
ikev2bis document (violating MUST), but it was conframnt to RFC4306 as
it didn't specify where the notification needs to be, so that kind of
RFC4306 style implementations might be out there and we want to keep
backward compatibility with them still. 

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

Yes, and is very commonly used and part of testing done in interops.

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

I do not see any contradiction there. We could perhaps add text saying
that implementations should allow way to enter ID_KEY_ID any octect
string as ID_KEY_ID (either as binary or as hex). I.e. the text saying
it is opaque and vendor specific means that there is no format for it
defined here for IKEv2 it is just opaque string. Perhaps we should
remove the "vendor specific", as it is not really that, but more
likely it will be "scenario/environment specific".

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

The reason for requiring vendor id payloads is that before those
internet-drafts (note, note rfcs, but drafts) are published the
numbers used for them (i.e. the notify message types) are allocated
from the private use place, and there can be operlapping numbers for
them. Thus for testing those we need to have some way of telling which
numbers we are using, i.e. whether the notify message type 40960 means
MOBIKE_SUPPORTED or MULTIPLE_AUTH_SUPPORTED. When those drafts go to
the RFCs and the private use numbers are replaced with proper iana
allocated numbers then there is no need for vendor id payloads
anymore.

But the vendor id payloads are still needed for the
before-iana-allocation phase.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Oct 2008 07:55:21 -0700

Tero, it would be better if each of the issues had their own thread, just as we did for your list of issues on the same document. Please wait until Yaron and I start those threads, and then comment. Putting all the open issues into one thread will not be helpful to the WG.

--Paul Hoffman, Director
--VPN Consortium