The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-ietf-ipsecme-ikev2-null-auth-07

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ipsecme-ikev2-null-auth-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments:

IANA understands that upon approval of this document, there are two actions that need to be completed.

First, in the IKEv2 Authentication Method registry under the Internet Key Exchange Version 2 (IKEv2) Parameters heading at

http://www.iana.org/assignments/ikev2-parameters/

IANA has already registered the following value through the registry's Expert Review process. Upon approval of this document, IANA will update the reference for the registration and change its description from "NULL Authentication Method" to "NULL Authentication." IANA has sent the expert a note informing him of the update.

Value: 13
Authentication Method: NULL Authentication
Reference: [ RFC-to-be ]

Second, in the IKEv2 Identification Payload ID Types registry under the Internet Key Exchange Version 2 (IKEv2) Parameters heading at

https://www.iana.org/assignments/ikev2-parameters/

IANA has already registered the following value through the registry's Expert Review process. Upon approval of this document, IANA will update the reference for the registration. IANA has sent the expert a note informing him of the update.

Value: 13
ID Type: ID_NULL
Reference: [ RFC-to-be ]

IANA understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

[Ballot comment]
First: Thanks, Paul, for a very informative and useful shepherd writeup.

Editorial comment in Section 2:

  If a peer
  that requires authentication receives an AUTH payload containing the
  NULL Authentication method type, it MUST return an
  AUTHENTICATION_FAILED notification.

We're referring to NULL authentication as "authentication", so maybe this should say something like "If a peer that requires positive identification receives [...]", or "If a peer that requires authenticated identity receives [...]" ?

[Ballot comment]

- 2.1: just wanted to check as I didn't have time to go
through it all myself - are we confident that using
SK_pi/SK_pr in this way has no cryptographic downsides? The
reference to the EAP methods convinces me this is no worse
than an existing thing, but not (by itself) that it is
cryptographically sound, so I just wanted to check as I
think prf(SK_pr,IDr') has until now been calculated but not
transmitted, so there's a tiny change here maybe, but as I
said I didn't have time to fully check. If someone just
tells me that yes, the authors/wg did consider this, that'll
be fine, no need to fully explain to me why using SK_pr like
this is safe (though if you want to, that'd be fine too).

- 2.5: "hand out" is an odd phrase here - would be better
to expand on that I think and say more precisely what
should never be done.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The NULL Authentication Method in IKEv2 Protocol) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'The NULL Authentication Method in IKEv2 Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

This is a second last call, specifically to seek comments
on the downref to Experimental RFC 5739.

Abstract


  This document specifies the NULL Authentication method and the
  ID_NULL Identification Payload ID Type for the IKEv2 Protocol.  This
  allows two IKE peers to establish single-side authenticated or mutual
  unauthenticated IKE sessions for those use cases where a peer is
  unwilling or unable to authenticate or identify itself.  This ensures
  IKEv2 can be used for Opportunistic Security (also known as
  Opportunistic Encryption) to defend against Pervasive Monitoring
  attacks without the need to sacrifice anonymity.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot discuss]
First: Thanks, Paul, for a very informative and useful shepherd writeup.

I have no problem with the reference to Experimental RFC 5739, but I do have a problem with the downref not having been noted in the last call announcement, as required by RFC 3967 (BCP 97).  And I think the MUST in the last paragraph of Section 2.5 requires 5739 to be normative.  I hate to say this, but I think this requires a second last call on this document, which will really serve no one.  We really do need to do an update to BCP 97 to fix this, because it comes up all the time.

[Ballot comment]
Editorial comment in Section 2:

  If a peer
  that requires authentication receives an AUTH payload containing the
  NULL Authentication method type, it MUST return an
  AUTHENTICATION_FAILED notification.

We're referring to NULL authentication as "authentication", so maybe this should say something like "If a peer that requires positive identification receives [...]", or "If a peer that requires authenticated identity receives [...]" ?

Shepherd writeup for draft-ietf-ipsecme-ikev2-null-auth

1. Summary

Paul Hoffman is the document shepherd, and Kathleen Moriarty is the responsible Area Director.

This document defines a new authentication mechanism for IKEv2, appropriately called "NULL". The
NULL mechanism allows two IKE peers to establish either single-side or mutual authentication for
those use cases where a peer is unwilling or unable to authenticate or identify itself. This is
useful for using IPsec with opportunistic security without the need to sacrifice anonymity. The
document also defines a new identification type, ID_NULL.

2. Review and Consensus

The document was discussed fairly well in the WG. The WG Last Call elicited a lot of review and
changes to the document, which were then reviewed in a second WG Last Call.

After discussing with other ADs, our AD asked for this document to be labeled as "Updates 4301"
based on the text previously in Section 2.4. There was a bit of WG discussion about
whether or not this document fits the general definition of "updates" for another RFC,
with no strong feelings either way. The document was changed to say "Updates 4301",
and the prose now talks about the update.

3. Intellectual Property

Both authors have stated that they do not know of any relevant IPR for this document.

4. Other Points

Although the basic idea for null authentication is pretty simple, it turns out to be a bit complex
to add this to IKEv2 safely. This caused the discussion to go on longer than initially expected, but
the outcome is a more complete document.

The document has a normative reference to RFC 5739, which is Experimental, and some people might
have a problem with this. RFC 5739 really is experimental, and no one seems to want to do the
admittedly hard work to bring it to stanards track. If this becomes too much of an issue for the
purists, the reference can be moved to the Informative References section, but it is more
appropriate as a normative reference.

Shepherd writeup for draft-ietf-ipsecme-ikev2-null-auth

1. Summary

Paul Hoffman is the document shepherd, and Kathleen Moriarty is the responsible Area Director.

This document defines a new authentication mechanism for IKEv2, appropriately called "NULL". The
NULL mechanism allows two IKE peers to establish either single-side or mutual authentication for
those use cases where a peer is unwilling or unable to authenticate or identify itself. This is
useful for using IPsec with opportunistic security without the need to sacrifice anonymity. The
document also defines a new identification type, ID_NULL.

2. Review and Consensus

The document was discussed fairly well in the WG. The WG Last Call elicited a lot of review and
changes to the document, which were then reviewed in a second WG Last Call.

After discussing with other ADs, our AD asked whether or not this document should be labeled
as "Updates 4301" based on the text in Section 2.4. There was a bit of WG discussion about
whether or not this document fits the general definition of "updates" for another RFC,
with no strong feelings either way. The document was changed to say "Updates 4301",
and the prose now talks about the update.

3. Intellectual Property

Both authors have stated that they do not know of any relevant IPR for this document.

4. Other Points

Although the basic idea for null authentication is pretty simple, it turns out to be a bit complex
to add this to IKEv2 safely. This caused the discussion to go on longer than initially expected, but
the outcome is a more complete document.

The document has a normative reference to RFC 5739, which is Experimental, and some people might
have a problem with this. RFC 5739 really is experimental, and no one seems to want to do the
admittedly hard work to bring it to stanards track. If this becomes too much of an issue for the
purists, the reference can be moved to the Informative References section, but it is more
appropriate as a normative reference.

Shepherd writeup for draft-ietf-ipsecme-ikev2-null-auth

1. Summary

Paul Hoffman is the document shepherd, and Kathleen Moriarty is the responsible Area Director.

This document defines a new authentication mechanism for IKEv2, appropriately called "NULL". The
NULL mechanism allows two IKE peers to establish either single-side or mutual authentication for
those use cases where a peer is unwilling or unable to authenticate or identify itself. This is
useful for using IPsec with opportunistic security without the need to sacrifice anonymity. The
document also defines a new identification type, ID_NULL.

2. Review and Consensus

The document was discussed fairly well in the WG. The WG Last Call elicited a lot of review and
changes to the document, which were then reviewed in a second WG Last Call.

Our AD asked whether or not this document should be labeled as "Updates 4301" based on the
text in Section 2.4. There was a bit of discussion about whether or not this document fits the
general definition of "updates" for another RFC, with no strong feelings either way.
The document currently says "Updates 4301", and has related wording in the prose,
but the WG will accept whatever the IESG wants for this.

3. Intellectual Property

Both authors have stated that they do not know of any relevant IPR for this document.

4. Other Points

Although the basic idea for null authentication is pretty simple, it turns out to be a bit complex
to add this to IKEv2 safely. This caused the discussion to go on longer than initially expected, but
the outcome is a more complete document.

The document has a normative reference to RFC 5739, which is Experimental, and some people might
have a problem with this. RFC 5739 really is experimental, and no one seems to want to do the
admittedly hard work to bring it to stanards track. If this becomes too much of an issue for the
purists, the reference can be moved to the Informative References section, but it is more
appropriate as a normative reference.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ipsecme-ikev2-null-auth-06.  Please report any inaccuracies as soon as possible.

IANA's reviewer has the following comments:

IANA understands that upon approval of this document, there are two actions that need to be completed.

First, in the IKEv2 Authentication Method registry under the Internet Key Exchange Version 2 (IKEv2) Parameters heading at

https://www.iana.org/assignments/ikev2-parameters/

IANA has already registered the following value through the registry's Expert Review process. Upon approval of this document, IANA will update the reference for the registration and change its description from "NULL Authentication Method" to "NULL Authentication." IANA has sent the expert a note informing him of the update.

Value: 13
Authentication Method: NULL Authentication
Reference: [ RFC-to-be ]

Second, in the IKEv2 Identification Payload ID Types registry under the Internet Key Exchange Version 2 (IKEv2) Parameters heading at

https://www.iana.org/assignments/ikev2-parameters/

IANA has already registered the following value through the registry's Expert Review process. Upon approval of this document, IANA will update the reference for the registration. IANA has sent the expert a note informing him of the update.

Value: 13
ID Type: ID_NULL
Reference: [ RFC-to-be ]

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The NULL Authentication Method in IKEv2 Protocol) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'The NULL Authentication Method in IKEv2 Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-05-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies the NULL Authentication method and the
  ID_NULL Identification Payload ID Type for the IKEv2 Protocol.  This
  allows two IKE peers to establish single-side authenticated or mutual
  unauthenticated IKE sessions for those use cases where a peer is
  unwilling or unable to authenticate or identify itself.  This ensures
  IKEv2 can be used for Opportunistic Security (also known as
  Opportunistic Encryption) to defend against Pervasive Monitoring
  attacks without the need to sacrifice anonymity.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd writeup for draft-ietf-ipsecme-ikev2-null-auth

1. Summary

Paul Hoffman is the document shepherd, and Kathleen Moriarty is the responsible Area Director.

This document defines a new authentication mechanism for IKEv2, appropriately called "NULL". The
NULL mechanism allows two IKE peers to establish either single-side or mutual authentication for
those use cases where a peer is unwilling or unable to authenticate or identify itself. This is
useful for using IPsec with opportunistic security without the need to sacrifice anonymity. The
document also defines a new identification type, ID_NULL.

2. Review and Consensus

The document was discussed fairly well in the WG. The WG Last Call elicited a lot of review and
changes to the document, which were then reviewed in a second WG Last Call.

Our AD asked whether or not this document should be labeled as "Updates 4301" based on the
text in Section 2.4. There was a bit of discussion about whether or not this document fits the
general definition of "updates" for another RFC, with no strong feelings either way. The WG defers
this question to the IESG and will accept whatever the IESG wants for this.

3. Intellectual Property

Both authors have stated that they do not know of any relevant IPR for this document.

4. Other Points

Although the basic idea for null authentication is pretty simple, it turns out to be a bit complex
to add this to IKEv2 safely. This caused the discussion to go on longer than initially expected, but
the outcome is a more complete document.

The document has a normative reference to RFC 5739, which is Experimental, and some people might
have a problem with this. RFC 5739 really is experimental, and no one seems to want to do the
admittedly hard work to bring it to stanards track. If this becomes too much of an issue for the
purists, the reference can be moved to the Informative References section, but it is more
appropriate as a normative reference.

Shepherd writeup for draft-ietf-ipsecme-ikev2-null-auth

1. Summary

Paul Hoffman is the document shepherd, and Kathleen Moriarty is the responsible Area Director.

This document defines a new authentication mechanism for IKEv2, appropriately called "NULL". The
NULL mechanism allows two IKE peers to establish either single-side or mutual authentication for
those use cases where a peer is unwilling or unable to authenticate or identify itself. This is
useful for using IPsec with opportunistic security without the need to sacrifice anonymity. The
document also defines a new identification type, ID_NULL.

2. Review and Consensus

The document was discussed fairly well in the WG. The WG Last Call elicited a lot of review and
changes to the document, which were then reviewed in a second WG Last Call.

3. Intellectual Property

Both authors have stated that they do not know of any relevant IPR for this document.

4. Other Points

Although the basic idea for null authentication is pretty simple, it turns out to be a bit complex
to add this to IKEv2 safely. This caused the discussion to go on longer than initially expected, but
the outcome is a more complete document.

The document has a normative reference to RFC 5739, which is Experimental, and some people might
have a problem with this. RFC 5739 really is experimental, and no one seems to want to do the
admittedly hard work to bring it to stanards track. If this becomes too much of an issue for the
purists, the reference can be moved to the Informative References section, but it is more
appropriate as a normative reference.