Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)
RFC 6631

[Ballot comment]

- I found the overall description of PACE hard to follow, it'd be
better if you gave the MODP method for mapping s in the overview so
that someone who just knows standard D-H can see why this is a ZKPP.

- "free of patents" is not possible, and not really appropriate as a
claim in an RFC

- section 5.1 could badly do with some examples if that's possible.
I'd expect interop problems in any case, but more without that. Those
might be shared with the other scheme drafts.

- [I-D.kivinen-ipsecme-secure-password-framework] is now an RFC

- s2, point 1: don't just say that a value encrypted with the
password (ENONCE) is sent to the responder, since that'd in general
be vulnerable to off-line dictionary attacks. Maybe say that ENONCE
is ok to send because it is specially constructed so as not to expose
anything about the password.

- "MUST be presisted to stable memory" might be too onerous, I'd say
a SHOULD would be better there in case someone has to use an existing
DB of shared secrets.

- The LongTermSecret scheme seems to be independent of PACE so I
wondered why its here and not in a document of its own.

- 4.1 seems to call for a table of mappings from authenticated
ciphers to the unauthenticated equivalents, otherwise interop is not
likely. I think you need to provide those mappings (or at least some)
and ideally ask IANA to create a registry for others (it'd be needed
if this got onto the standards track later).

[Ballot comment]
Section 5.1 states:

  The input password string SHOULD be processed according to the rules
  of the [RFC4013] profile of [RFC3454].

Why or when would an implementation violate the SHOULD? That is, why is this not a MUST? Also, please be aware there there is work underway to obsolete RFC 3454 and RFC 4013, primarily because stringprep is limited to Unicode 3.2; see draft-melnikov-precis-saslprepbis. This is just a heads-up, and I'm not necessarily suggesting that you change the text to something like "use RFC 4013 or equivalent". However, when your experiment is done and you put this on the standards track, you'll probably be asked to update the internationalization to use saslprepbis (if the PRECIS WG finishes before your experiment does!).

IANA understands that, upon approval of this document, there are two
actions that IANA must complete.

First, in the IKEv2 Secure Password Methods subregistry of the Internet
Key Exchange Version 2 (IKEv2) Parameters registry located at:

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

a new method will be added as follows:

Value: [ tbd ]
Description: Password Authenticated Connection Establishment
Reference: [ RFC-to-be ]

IANA notes that this method has not yet been added.

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

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

two new status types will be added as follows:

Value: [ tbd ]
Notify Message Type - Status Type: PSK_PERSIST
Reference: [ RFC-to-be ]

Value: [ tbd ]
Notify Message Type - Status Type: PSK_CONFIRM
Reference: [ RFC-to-be ]

IANA notes that these status types have not yet been added to the registry.

PROTO writeup for draft-kuegler-ipsecme-pace-ikev2-08.txt

(1.a) I (Paul Hoffman) am the shepherd, and I have reviewed the -08
version of
the draft. I believe that it is ready for forwarding to the IESG. Note that
this is an individual submission, not the product of the IPsecME WG.

(1.b) The document was reviewed in the IPsecME WG, although it is not a WG
draft. There were multiple requests for reviews, and there were a fair
number
of comments on various versions of the draft

(1.c) I do not believe that more reviews will necessarily help the draft.

(1.d) I do not have any special concerns about this draft. There are no IPR
statements for this draft.

(1.e) There was informal consensus in the IPsecME WG that multiple proposals
for a PAKE, including this one, should be standardized.

(1.f) I do not believe anyone has threatened an appeal. There are some
individuals who expressed extreme discontent with the idea that there
would be
more than one PAKE published, but the WG could not agree on just one PAKE.

(1.g) There were no nits that would prevent the document from being
published
as an RFC.

(1.h) The document's split between normative and informative references is
appropriate, and there are no normative downward references.

(1.i) The IANA considerations is appropriate.

(1.j) There is no formal languages used in the document.

Technical Summary
This document describes a password-based key exchange for IKEv2 that
can be
used in the framework described in RFC 6467. The document describes its
exchange as "an adaptation of PACE (Password Authenticated Connection
Establishment) to the setting of IKEv2".

Working Group Summary
This document is an individual submission.

Document Quality
The document has been well-reviewed, with significant changes made
since the
initial submission. It includes references to academic papers that
cover the
algorithm described in the 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
Reply-To: ietf@ietf.org
Subject: Last Call:  (Password Authenticated Connection Establishment with IKEv2) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Password Authenticated Connection Establishment with IKEv2'
  as an Experimental 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 2012-02-14. 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


  IKEv2 does not allow secure peer authentication when using short
  credential strings, i.e. passwords.  Several proposals have been made
  to integrate password-authentication protocols into IKE.  This
  document provides an adaptation of PACE (Password Authenticated
  Connection Establishment) to the setting of IKEv2 and demonstrates
  the advantages of this integration.




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

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kuegler-ipsecme-pace-ikev2/


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

IANA understands that, upon approval of this document, there are six
actions that IANA must complete.

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

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

the following notification type will be added:

Value NOTIFY MESSAGES - ERROR TYPES Reference
------- -------------------------------- -----------
TBD PACE_SUPPORTED [RFC-to-be]

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

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

the following payload type will be added:

Value Next Payload Type Notation Reference
------ --------------------------- ---------- -----------
TBD Encrypted Nonce ENONCE [RFC-to-be]

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

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

the following payload type will be added:

Value Next Payload Type Notation Reference
------ --------------------------- ---------- -----------
TBD Ephemeral Public Key PKE [RFC-to-be]

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

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

the following authentication method will be added:

Value Authentication Method Reference
------- ----------------------------------------------- ------------
TBD Password Authenticated Connection Establishment [RFC-to-be]

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

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

the following exchange type will be added:

Value Exchange Type Reference
------- ------------------------ -------------
TBD IKE_PACE [RFC-to-be]

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

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

the following exchange type will be added:

Value Exchange Type Reference
------- ------------------------ -------------
TBD IKE_PACE_AUTH [RFC-to-be]

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

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

Yaron Sheffer, a co-author, is Shepherd for this document. He has reviewed this
version and believe it is ready for publication.

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

The document is an individual submission, and not a product of any working
group. It was previously presented to the IPsecME working group, and had a
limited amount of review.

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

The document is within the core focus area of the IPsecME WG. I am not aware of
any particular additional community that needs to review it.

  (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 WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The shepherd believes this is a problem worth solving (or he wouldn't have
coauthored it...). The following IPR statement has been submitted:
http://datatracker.ietf.org/ipr/1324/

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

This is an individual submission. In fact, (WG co-chair hat here) we asked the
WG several times, and there was not enough interest in solving this problem, in
particular because there were several competing proposed solutions.
(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
        separate
email messages to the Responsible Area Director. (It
        should be in a
separate email because this questionnaire is
        entered into the ID
Tracker.)

No "extreme discontent", but this is as expected with an individual submission.
There are alternative proposed solutions to the same problem being published
concurrently with this one.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        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?

I have verified ID nits. There are a few minor nits referring to since-published
drafts, which we will correct in the next revision. There are no formal criteria
to be met.

  (1.h) Has the document split its references into normative and
        informative? 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]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

References are split. As mentioned, a few references will change (I-D to RFC) in
the next revision.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? 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 suggest 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?

There are various extensions defined for the IKEv2 protocol (exchange types,
notifications etc.), and the IANA considerations are appropriate. No new
registries are defined.

  (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 are no such sections.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? 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.

IKEv2 does not allow secure peer authentication when using short credential
strings, i.e. passwords (other than with EAP in certain modes).  Several
proposals have been made to integrate password-authentication protocols into
IKE.  This document provides an adaptation of PACE (Password Authenticated
Connection Establishment) to the setting of IKEv2 and demonstrates the
advantages of this integration. PACE is a novel mutual authentication protocol,
based on a modified Diffie-Hellman exchange, and has strong and formally proven
security properties.

    Working Group Summary

        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

This document is not a product of any working group.

    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?

We are not aware of implementations of this protocol.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Password Authenticated Connection Establishment with IKEv2) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Password Authenticated Connection Establishment with IKEv2'
  as an Experimental 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-04-23. 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.

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

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kuegler-ipsecme-pace-ikev2/