Subject: [IPsec] RFC5996bis editorial change in section 1. Introduction (Was Re: Editorial changes to RFC5996)

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 17:13:23 +0200

[I am now doing these editorial changes, and I will be sending
separate emails for each of them, just so I can keep track of what is
changed and where, and you can complain if I miss or misinterpret
something (but do not complain about missing changes before I send
email that I have processed all of the changes).]

Yaron Sheffer writes:
> By the way, your correction #2 still does not do it IMHO. The sentence 
> refers to RFC 5996. So:
> 
> "IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was 
> not backward compatible. RFC 5996 revised RFC 4306 to provide a 
> clarification of IKEv2, making minimum changes to the IKEv2 protocol. 
> The current document slightly revises RFC 5996 to make it suitable for 
> progression to Internet Standard."

Changed

	IKEv2 was a change to the IKE protocol that was not backward
	compatible. In contrast, the current document not only
	provides a clarification of IKEv2, but makes minimum changes
	to the IKE protocol. A list of the significant differences
	between RFC 4306 and RFC 5996 is given in <xref
	target='sect-1.7'/> and differences between RFC 5996 and this
	document is given in <xref target='sect-1.8' />.</t>

to:

	IKEv2 as stated in RFC 4306 was a change to the IKE protocol
	that was not backward compatible. RFC 5996 revised RFC 4306 to
	provide a clarification of IKEv2, making minimum changes to
	the IKEv2 protocol. The current document slightly revises RFC
	5996 to make it suitable for progression to Internet Standard.
	A list of the significant differences between RFC 4306 and RFC
	5996 is given in <xref target='sect-1.7'/> and differences
	between RFC 5996 and this document is given in <xref
	target='sect-1.8' />.</t>
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 12 Nov 2013 17:18:00 +0200

Looks good to me.

	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 17:57:44 +0200

Valery Smyslov writes:
> 1. Section 1.6 Requirements Terminology is placed far from the begining
>     of the document and all the requirements words, along with terms
>     from RFC4301 etc. are used before they are formally introduced.
>     I don't think it is appropriate for standards track document.
>     I suggest to move this section before Introduction.

We had this discussion twice when we were making RFC5996 (
http://www.ietf.org/mail-archive/web/ipsec/current/msg03051.html and
http://www.ietf.org/mail-archive/web/ipsec/current/msg04526.html ).

The fist of this emails (Yaron's notes) caused ticket #51 to be
opened:

http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/51

And the resolution for that ticket #51 was closed as "wontfix" and
with comments:

> There is no other good place to do this without messing up the section
> numbering.
> 
> This is too difficult to do well, and it really isn't that important.

And I think that same thing holds still. The problem is that there are
lots of people who refer to the IKEv2 specification by section
numbers, and if we change those that will cause all those references
to be invalid, which might cause confusion.

For the second email there was much bigger reordering of the sections
suggested, and looking at the email exchange people were in favor of
it, but then nothing was changed. There is nothing on the list about
this, so it might be it was discussed in the IETF meeting. 

Anyways we decided against this last time, so I will not be doing this
change unless I get more support for this from the WG, and I agree
with #51 resoluton, that there is no other good place to do this
without messing up the section numbers.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 12 Nov 2013 10:58:48 -0500

Agreed.

Valery.

-----Original Message----- 
From: Yaron Sheffer
Sent: Tuesday, November 12, 2013 10:18 AM
To: Tero Kivinen
Cc: Valery Smyslov ; [email-masked]
Subject: Re: RFC5996bis editorial change in section 1. Introduction (Was Re: 
[IPsec] Editorial changes to RFC5996)

Looks good to me.

Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 12 Nov 2013 18:04:17 +0200

I agree with Tero's reasoning, even though I raised this issue in the 
past (and I still think the text is kind of weird).

Let's keep changes in this "bis" to the minimum possible.

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 18:07:58 +0200

Valery Smyslov writes:
> 3. Page 10.
>    "HDR contains the Security Parameter Indexes (SPIs), version numbers,
>    and flags of various sorts."
> 
> Not mentioned Message ID, Exchange Type (and Next Payload and length,
> but they are not very important here). I suggest to change:
> 
>    "HDR contains the Security Parameter Indexes (SPIs), version numbers,
>    Type of Exchange, Message ID and flags of various sorts."

I was first thinking that Message ID and Exchange Type are not very
important here either, but as I noticed that the same section do
explain Message ID earlier, and talks about Exchanges even when it
does not yet specify how different exchanges are indicated, so I think
this addition might clarify things.

Changed:

<t>HDR contains the Security Parameter Indexes (SPIs), version
numbers, and flags of various sorts.  The SAi1 payload states the
cryptographic algorithms the initiator supports for the IKE SA.  The
KE payload sends the initiator's Diffie-Hellman value.  Ni is the
initiator's nonce.</t>

to:

<t>HDR contains the Security Parameter Indexes (SPIs), version
numbers, Exchange Type, Message ID, and flags of various sorts. The
SAi1 payload states the cryptographic algorithms the initiator
supports for the IKE SA. The KE payload sends the initiator's
Diffie-Hellman value. Ni is the initiator's nonce.</t>
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 18:38:22 +0200

Valery Smyslov writes:
> 4. Page 11.
>    "At this point in the negotiation, each party can generate SKEYSEED,
>    from which all keys are derived for that IKE SA."
> 
> Term SKEYSEED pops up from nowhere. No reference is gived and
> even no word is explained what is it all about. First-time readers will
> definitely be puzzled. I suggest to change:
> 
>    "At this point in the negotiation, each party can generate a quantity
>     called SKEYSEED (see section 2.14), from which all keys are derived
>     for that IKE SA."

Changed:

	<t>At this point in the negotiation, each party can generate
	SKEYSEED, from which all keys are derived for that IKE SA.

To:

	<t>At this point in the negotiation, each party can generate a
	quantity called SKEYSEED (see <xref target="sect-2.14"/>),
	from which all keys are derived for that IKE SA.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 20:55:38 +0200

Valery Smyslov writes:
> 5. Page 14, 15 and 16
>    "The responder replies (using the same Message ID to respond) with the
>    accepted offer in an SA payload, and a Diffie-Hellman value in the
>    KEr payload if KEi was included in the request and the selected
>    cryptographic suite includes that group."
> 
>    "The responder replies (using the same Message ID to respond) with the
>    accepted offer in an SA payload, and a Diffie-Hellman value in the
>    KEr payload if the selected cryptographic suite includes that group."
> 
>    "The responder replies (using the same Message ID to respond) with the
>    accepted offer in an SA payload, and a Diffie-Hellman value in the
>    KEr payload if KEi was included in the request and the selected
>    cryptographic suite includes that group."
> 
> All three sentencies look like they were copy-pasted and all three
> lacks mention Nonce Payload. I think it should be explicitely
> mentioned here, as it was mentioned in descriptions of Initiator's message,
> above each of this sentencies.

I agree on adding the comment about nonce in those copied sections.
The reason for copying is because the original section 1.3 in RFC4306
was split 3 ways in RFC5996. 

> And I also think that words in parentheses here are superfluous, as
> this requirement is comon for all exchanges, not only for
> CREATE_CHILD_SA, and stated several times in the document. So, I
> suggest to change:

This was propsed for the RFC5996 already (by me :-) and there was
ticket #34 opened for it and the change was not done as it was
considered important to keep it there:

My original email opening the issue:

http://www6.ietf.org/mail-archive/web/ipsec/current/msg02953.html

ticket opened by it

http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/34

and more of my comments to the issue:

http://www6.ietf.org/mail-archive/web/ipsec/current/msg03155.html

and I think this caused we to add definition of Message ID in the
beginning of section 1.2. 

>    "The responder replies with the accepted offer in an SA payload,
>     nonce in the Nr payload and a Diffie-Hellman value in the
>    KEr payload if KEi was included in the request and the selected
>    cryptographic suite includes that group."
> 
>    "The responder replies with the accepted offer in an SA payload,
>     nonce in the Nr payload and a Diffie-Hellman value in the
>    KEr payload if the selected cryptographic suite includes that group."
> 
>    "The responder replies with the accepted offer in an SA payload,
>     nonce in the Nr payload and a Diffie-Hellman value in the
>    KEr payload if KEi was included in the request and the selected
>    cryptographic suite includes that group."

Changed:

	<t>The responder replies (using the same Message ID to
	respond) with the accepted offer in an SA payload, and a
	Diffie-Hellman value in the KEr payload if KEi was included in
	the request and the selected cryptographic suite includes that
	group.</t>

...

	<t>The responder replies (using the same Message ID to
	respond) with the accepted offer in an SA payload, and a
	Diffie-Hellman value in the KEr payload if the selected
	cryptographic suite includes that group. A new responder SPI
	is supplied in the SPI field of the SA payload.</t>

...

	<t>The responder replies (using the same Message ID to
	respond) with the accepted offer in an SA payload, and a
	Diffie-Hellman value in the KEr payload if KEi was included in
	the request and the selected cryptographic suite includes that
	group.</t>

To:

	<t>The responder replies (using the same Message ID to
	respond) with the accepted offer in an SA payload, nonce in
	the Nr payload, and a Diffie-Hellman value in the KEr payload
	if KEi was included in the request and the selected
	cryptographic suite includes that group.</t>

...

	<t>The responder replies (using the same Message ID to
	respond) with the accepted offer in an SA payload, nonce in
	the Nr payload, and a Diffie-Hellman value in the KEr payload
	if the selected cryptographic suite includes that group. A new
	responder SPI is supplied in the SPI field of the SA
	payload.</t>

...

	<t>The responder replies (using the same Message ID to
	respond) with the accepted offer in an SA payload, nonce in
	the Nr, and a Diffie-Hellman value in the KEr payload if KEi
	was included in the request and the selected cryptographic
	suite includes that group.</t>

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 21:01:44 +0200

Valery Smyslov writes:
> 6. Page 19.
>     "The recipient of this notification cannot tell
>    whether the SPI is for AH or ESP, but this is not important because
>    the SPIs are supposed to be different for the two."
> 
> Why "is supposed to be different"? RFC4301 clearly states:
>     "For a unicast SA, the SPI can be used by itself to specify an SA, or it 
> may be
>       used in conjunction with the IPsec protocol type."
> 
> So I suggest to change as follows:
> 
>     "The recipient of this notification cannot tell
>    whether the SPI is for AH or ESP, but this is not important because
>     in many cases the SPIs will be different for the two."
> 
> And some words should be added for the case when SPIs are not
> different for AH and ESP. I have no good suggestion here.

Changed:

	The recipient of this notification cannot tell whether the SPI
	is for AH or ESP, but this is not important because the SPIs
	are supposed to be different for the two.

To:

	The recipient of this notification cannot tell whether the SPI
	is for AH or ESP, but this is not important because in many
	cases the SPIs will be different for the two.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 21:08:56 +0200

Valery Smyslov writes:
> 7. Page 31.
> Phrase "(see Section 2.6)" actually references the same section. It should 
> either
> be removed or corrected.

Changed:

	<t>In the first message of an initial IKE exchange, the
	initiator will not know the responder's SPI value and will
	therefore set that field to zero. When the IKE_SA_INIT
	exchange does not result in the creation of an IKE SA due to
	INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, or COOKIE (see <xref
	target="sect-2.6" />), the responder's SPI will be zero also
	in the response message. However, if the responder sends a
	non-zero responder SPI, the initiator should not reject the
	response for only that reason.</t>

To:

	<t>In the first message of an initial IKE exchange, the
	initiator will not know the responder's SPI value and will
	therefore set that field to zero. When the IKE_SA_INIT
	exchange does not result in the creation of an IKE SA due to
	INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, or COOKIE, the
	responder's SPI will be zero also in the response message.
	However, if the responder sends a non-zero responder SPI, the
	initiator should not reject the response for only that
	reason.</t>

Not sure where it could point, so I removed it. And there you can also
see why it is not so easy to see it points to section itself :-)
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 21:13:21 +0200

Valery Smyslov writes:
> 8. Page 31.
>     "However, if the responder sends a non-zero
>    responder SPI, the initiator should not reject the response for only
>    that reason."
> 
> Should here "should not" be "SHOULD NOT"?

If I correctly parsed exchanges in the mailing list concensus was to
skip this change? Was my interpretation correct? So currently this
change was skipped.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 21:40:38 +0200

Valery Smyslov writes:
> 9. Page 49.
>     "There are two types of EAP authentication (described in
>    Section 2.16), and each type uses different values in the AUTH
>    computations shown above.  If the EAP method is key-generating,
>    substitute master session key (MSK) for the shared secret in the
>    computation.  For non-key-generating methods, substitute SK_pi and
>    SK_pr, respectively, for the shared secret in the two AUTH
>    computations."
> 
> Isn't this para superfluous here? Its content belongs to EAP
> authentication and in fact it is described in more details two pages
> below.

That text was added in the draft-ietf-ipsecme-ikev2bis-08 because of
the ticket #151:

http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/151

Because of that I would like to get more feedback from WG before I
revert that change. I.e no changes done.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 21:44:01 +0200

Valery Smyslov writes:
> 10. Page 51.
>     "As described in Section 2.2, when EAP is used, each pair of IKE SA
>    initial setup messages will have their message numbers incremented;
>    the first pair of AUTH messages will have an ID of 1, the second will
>    be 2, and so on."
> 
> Should be:
> 
>     "As described in Section 2.2, when EAP is used, each pair of IKE SA
>    initial setup messages will have their message numbers incremented;
>    the first pair of IKE_AUTH messages will have an ID of 1, the second will
>    be 2, and so on."

Changed:

	<t>As described in <xref target='sect-2.2'/>, when EAP is
	used, each pair of IKE SA initial setup messages will have
	their message numbers incremented; the first pair of AUTH
	messages will have an ID of 1, the second will be 2, and so
	on.</t>

To:

	<t>As described in <xref target='sect-2.2'/>, when EAP is
	used, each pair of IKE SA initial setup messages will have
	their message numbers incremented; the first pair of IKE_AUTH
	messages will have an ID of 1, the second will be 2, and so
	on.</t>
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 21:49:56 +0200

Valery Smyslov writes:
> 11. Page 52:
>     "A single CHILD_SA negotiation may result in multiple Security
>    Associations."
> 
> Should be:
> 
>    "A single CREATE_CHILD_SA negotiation may result in multiple Security
>    Associations."

Changed:

	<t>A single CHILD_SA negotiation may result in multiple
	Security Associations.

To:

	<t>A single CREATE_CHILD_SA negotiation may result in multiple
	Security Associations.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Nov 2013 21:53:34 +0200

Valery Smyslov writes:
> Just came across one more small editorial issue in RFC5996.
> Page 73, description of "Next Payload" field, sentence
> 
>       In the header of an Encrypted payload, the Next Payload field is set
>       to the payload type of the first contained payload (instead of 0);
>       conversely, the Next Payload field of the last contained payload
>       is set to zero).  
> 
> has extra round bracket at the end.

Removed.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Nov 2013 15:44:44 -0500 (EST)

On Thu, 17 Oct 2013, Tero Kivinen wrote:

[forgive me if already reported]

Section 3.1 states:

    o  Major Version (4 bits) - Indicates the major version of the IKE
       protocol in use.  Implementations based on this version of IKE
       MUST set the major version to 2.  Implementations based on
       previous versions of IKE and ISAKMP MUST set the major version to
-->   1.  Implementations based on this version of IKE MUST reject or
       ignore messages containing a version number greater than 2 with an
       INVALID_MAJOR_VERSION notification message as described in Section
       2.5.

The reading of "this version" on the line marked "-->" is a little
unclear. Does it refer to the previous sentence's version (version 1)
or this version as in "this document's" version (version 2). I suggest
replacing "this version" with "this document's version"

    o  Minor Version (4 bits) - Indicates the minor version of the IKE
       protocol in use.  Implementations based on this version of IKE
       MUST set the minor version to 0.  They MUST ignore the minor
       version number of received messages.

For the Major we tell what IKEv1 implementations should do. Why don't we
do that for the Minor as well? Suggested addition:

 	Implementations based on the previous major version of IKE and
 	ISAKMP MUST set the minor version to 0 and reject or ignore
 	messages containing a minor version number greater than 0 with
 	an INVALID_MINOR_VERSION  notification message.

Paul