Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)
draft-kivinen-ipsecme-secure-password-framework-03

[Ballot comment]
- I don't get the point about the specific methods - do they or do
they not use the formats defined here? If not, why not? If so, the
last sentence of the 1st para of the intro is v. confusing.
Do the 3 experimental proposals actually use the values being
registered here? Only one of them (draft-shin...) seems to
reference this draft. Colour me confused.

- Is it ok for an informational doc to add to these registries?

- abstract has typos:
s/add new one/add any new ones/
s/in current connection/in the current connection/

- Intro
s/and working group/and the working group/
s/get pick/pick/
s/make implementation/make an implementation/
s/a payload formats/payload formats/
s/co-exists/co-exist/

That's getting tedious. It badly needs an editorial pass.

[Ballot comment]
This is a comment about the direction of the work in the IPSECME working group. I understand that I'm in the rough on this, we already debated it at the time of the charter being extended.

But I think we chose the wrong direction ,and the problem is only amplified because the working group could not agree on a single password method. We are creating new authentication method negotiation frameworks, and adding those as alternatives in the base IKEv2 exchange. I don't think this will improve interoperability in the long term. I would have chosen to specify small set of new symmetrically operable EAP methods and used the already existing exchanges. The chosen direction will cause IKEv2 implementations to become more complex, as many implementations need to support multiple use cases and therefore in practice support all the authentication frameworks. And if some day we decide to extend configuration support in devices with the new functionality so that shared secret configuration could take place centrally, we'll end up replicating AAA support in addition to the IKEv2 extensions defined here.

[Ballot discuss]
This is a well written document and I understand the reasons why it came to be. I do have one discuss-level issue with the description of EAP, and a comment-level opinion about this direction of the work for IPSECME.

The discuss-level issue is that Section 1 seems to be saying that EAP is asymmetric and that it is tied to AAA:

  ...
  the asymmetric nature of the EAP does not matter
  ...

  ...
  The new secure password methods are meant to be used in cases where
  such back-end AAA-infrastructure does not exists.  An example of such
  case could be authentication between two servers or routers.  These
  scenarios are usually symmetric: both peers know the shared secret,
  no back-end authentication servers are involved, and either end can
  initiate an IKEv2 connection.
  ...

EAP is indeed asymmetric, but so is IKEv2, even the extensions defined in this
draft use different content in the messages from the initiator and the responder.
There is no reason why an EAP method would have to be asymmetric; EAP-GPSK
for instance could be invoked from either end, based on which direction the IKEv2
initiation went.

Similarly, there is no requirement that AAA be used to make a remote authentication
decision. Implementations can decide to execute the EAP method locally.

I'd like to change Section 1 text a bit to make this clearer. For instance:

  ...
  the asymmetric nature of the EAP does not matter
  ...

  ...
  The new secure password methods are meant to be used for example
  with the authentication between two servers or routers.  These
  scenarios are usually symmetric: both peers know the shared secret,
  no back-end authentication servers are involved, and either end can
  initiate an IKEv2 connection. Note that such model could also be
  supported by EAP when an EAP method that can run in symmetric
  fashion is in use, and the EAP method is directly implemented on both
  peers and no AAA is in use.
  ...

Upon approval of this document, we understand that IANA must complete
the following actions:

ACTION 1:

Allocate one new IKEv2 "Notify Messages Types - Status Types" at
http://www.iana.org/assignments/ikev2-parameters

TBD SECURE_PASSWORD_METHODS

ACTION 2:

Allocate one new "IKEv2 Authentication Method" number at
http://www.iana.org/assignments/ikev2-parameters

TBD Generic Secure Password Authentication Method

ACTION 3:

Allocation one new "IKEv2 Payload Types" registration at
http://www.iana.org/assignments/ikev2-parameters

TBD Generic Secure Password Method GSPM

ACTION 4:

Create the following registry:

Registry Name: IKEv2 Secure Password Methods
Registration Procedure: Expert Review

0 Reserved
1-1024 Unassigned
1024-65535 Reserved for Private Use

Upon approval of this document, IANA understands that there are four
actions which must be completed.

First, in the IKEv2 Notify Message Types - Status Types registry in the
Internet Key Exchange Version 2 (IKEv2) Parameters registry located at:

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

a new Status Type will be registered as follows:

Value: [ tbd ]
Notify Messages - Status Types: SECURE_PASSWORD_METHODS
Reference: [ RFC-to-be ]

Second, in the IKEv2 Authentication Method registry, also in the
Internet Key Exchange Version 2 (IKEv2) Parameters registry located at:

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

a new Authentication Method will be registered as follows:

Value: [ tbd ]
Authentication Method: Secure Password Authentication Method
Reference: [ RFC-to-be ]

Third, in the IKEv2 Payload Types registry, also in the Internet Key
Exchange Version 2 (IKEv2) Parameters registry located at:

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

a new Payload Type will be registered as follows:

Value:[ tbd ]
Next Payload Type: Generic Secure Password Method
Notation: GSPM
Reference: [ RFC-to-be ]

Fourth a new registry will be created in the Internet Key Exchange
Version 2 (IKEv2) Parameters registry located at:

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

The name of the new registry will be the IKEv2 Secure Password Methods
registry.
Values 1-1024 are reserved for allocation by IANA through Expert Review.
Values 1024-65535 are for private use among mutually consenting parties.
The maintenance rule for the registry is Expert Review. There is a
single initial value for the registry.

Value Secure Password Method Reference
----- ----------------------------------------- -------------
0 Reserved [ RFC-to-be ]

IANA understands that these are the only actions required upon approval
of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC: ipsec@ietf.org
Reply-To: ietf@ietf.org
Subject: Last Call:  (Secure Password Framework for IKEv2) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Secure Password Framework for IKEv2'
  as an
Informational RFC

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 2011-08-24. 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 creates a generic way for Internet Key Exchange (IKEv2)
  to use any of the symmetric secure password authentication methods.
  There are multiple methods already specified in other documents and
  this document does not add new one.  This document specifies a common
  way so those methods can agree on which method is to be used in
  current connection.  This document also provides a common way to
  transmit secure password authentication method specific payloads
  between peers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-secure-password-framework/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-secure-password-framework/


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

    (1.a)
        Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Tero Kivinen. I think the document is ready for publication.

    (1.b)
        Has the document had adequate review both from key members of
        the interested community and others? Does the Document
        Shepherd have any concerns about the depth or breadth of the
        reviews that have been performed?

Docuemnt has been adequately reviewed. The document has been posted in
the ipsecme WG mailing list, has been reviewed there, and has been
reviewed by the authors of the 3 PAKE drafts.

    (1.c)
        Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns.

    (1.d)
        Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the interested community has discussed those issues
        and has indicated that it still wishes to advance the
        document, detail those concerns here.

This document is mostly needed to make sure the 3 related documents
are aligned to each other and to this, and to create IANA registry so
that 3 related documents can make allocations from that registry.  This
would normally have been done under in the IPSECME WG, but effort to
complete the PAKE selection and standardization waned.

    (1.e)
        How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a
        few individuals, with others being silent, or does the
        interested community as a whole understand and agree with it?

This is not the product of a WG.  This document provides common
framework for 3 related documents, and the related document authors have
agreed to use this framework in their documents.

    (1.f)
        Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarize the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is

No.

    (1.g)
        Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.

    (1.h)
        Has the document split its references into normative and
        informative?

Yes.

        Are there normative references to documents that are not ready
        for advancement or are otherwise in an unclear state? If such
        normative references exist, what is the strategy for their
        completion? Are there normative references that are downward
        references, as described in [RFC3967] (Bush, R. and T. Narten,
        "Clarifying when Standards Track Documents may Refer
        Normatively to Documents at a Lower Level," December 2004.)?
        If so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967] (Bush,
        R. and T. Narten, "Clarifying when Standards Track Documents
        may Refer Normatively to Documents at a Lower Level," December
        2004.).

All normative references are to existing RFCs.

    (1.i)
        Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?

Yes.

        If the document specifies protocol extensions, are
        reservations requested in appropriate IANA registries? Are the
        IANA registries clearly identified? If the document creates a
        new registry, does it define the proposed initial contents of
        the registry and an allocation procedure for future
        registrations? Does it suggested a reasonable name for the new
        registry? See [RFC5226]. If the document describes an Expert
        Review process has Shepherd conferred with the Responsible
        Area Director so that the IESG can appoint the needed Expert
        during the IESG Evaluation?

The document contains new registry that is expert review allocation,
and it would be best to use the same expert which handles all other
IKEv2 IANA registries, which is also the author of the this document.

    (1.j)
        Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

There is no such sections.

    (1.k)
        The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

        Technical Summary

            Relevant content can frequently be found in the abstract
            and/or introduction of the document. If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

This document creates a generic way for Internet Key
Exchange (IKEv2) to use any of the symmetric secure
password authentication methods. There are multiple
methods already specified in other documents and this
document does not add new one. This document specifies
a common way so those methods can agree on which
method is to be used in current connection. This
document also provides a common way to transmit secure
password authentication method specific payloads
between peers.

        Working Group Summary

            Was there anything in the discussion in the interested
            community that is worth noting? For example, was there
            controversy about particular points or were there
            decisions where the consensus was particularly rough? Was
            the document considered in any WG, and if so, why was it
            not adopted as a work item there?

The IPsecME working group was chartered to provide
Internet Key Exchange (IKEv2) a symmetric secure
password authentication protocol that supports using
of low-entropy shared secrets, but which is protected
against off-line dictionary attacks without requiring
the use of certificates or Extensible Authentication
Protocol (EAP). There are multiple of such methods and
working group was supposed to pick one. Unfortunately
the working group failed to get pick one protocol and
there are multiple candidates going forward as
separate documents. As each of those documents used
different method to negotiate the use of the method
and also used different payload formats it is very
hard to try to make implementation where multiple of
those systems could co-exists. This document provides
a common way for those secure password methods so they
can easily co-exist.

        Document Quality

            Are there existing implementations of the protocol? Have a
            significant number of vendors indicated their plan to
            implement the specification? Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues? If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)? In the case of a Media Type
            review, on what date was the request posted?

This document does not specify any protocol that can
be implemented as such, but provides common way for
secure password methods to do things in IKEv2. There
is already multiple secure password method documents
using the common way specified in this document.

        Personnel

            Who is the Document Shepherd for this document? Who is the
            Responsible Area Director?

Document Shepherd: Tero Kivinen
Responsible Area Director: Sean Turner
The IANA Expert for the registries in this document
is Tero Kivinen.