Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2
RFC 6628

[Ballot comment]
- section 2.2.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.

- Section 2, last paragraph - that's confusing - which Y and K
calculation is to be done? I think you need to be much clearer about
this.

- saying "server S does not store any plaintext passwords" is missing
2119 language. While a MUST would be most correct, perhaps a SHOULD
is right, in case someone wants to do this using an existing DB of
cleartext passwords.

- Providing a reference for "Shamir's trick" would be good.

[Ballot comment]
Both draft-harkins-ipsecme-spsk-auth and draft-kuegler-ipsecme-pace-ikev2 specify that the password will be prepared using SASLprep (RFC 4013). Why doesn't this specification also define how 'w' is prepared for input to other operations?

IANA has a question about the IANA Action requested in
draft-shin-augmented-pake-10.txt.

We understand that, upon approval of this document, there is one action
for IANA.

The current draft says, "IANA SHALL assign a value for the
Authentication Payload from the IKEv2 Authentication Method registry in
[IKEV2-IANA] with the name of "AugPAKE".

QUESTION: Do the authors intend that IANA assign a value for the
Authentication Method rather than the Authentication Payload?

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

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

the following authentication method will be added as follows:

Value: [TBD]
Authentication Method: AugPAKE
Reference: [RFC-to-be]

IANA understands that this is the only action required upon approval of
this document.

(1.a) I (Paul Hoffman) am the shepherd, and I have reviewed the -10
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 IPR
statements for this draft: #1282 and #1284.

(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 efficient augmented password-only authentication and key
exchange (AugPAKE) protocol where a user remembers a low-entropy
password
and its verifier is registered in the intended server".

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:  (Most Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Most Efficient Augmented Password-Only Authentication and Key Exchange
  for 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


  This document describes an efficient augmented password-only
  authentication and key exchange (AugPAKE) protocol where a user
  remembers a low-entropy password and its verifier is registered in
  the intended server.  In general, the user password is chosen from a
  small set of dictionary whose space is within the off-line dictionary
  attacks.  The AugPAKE protocol described here is secure against
  passive attacks, active attacks and off-line dictionary attacks (on
  the obtained messages with passive/active attacks), and also provides
  resistance to server compromise (in the context of augmented PAKE
  security).  In addition, this document describes how the AugPAKE
  protocol is integrated into IKEv2.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-shin-augmented-pake/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-shin-augmented-pake/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1282/
  http://datatracker.ietf.org/ipr/1284/

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

Document Shepherd: SeongHan Shin

I am the submitter of this document.

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

As far as I know, there is no review report from WG and non-WG members.

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

This document needs reviews from other members.

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

I have no concerns about this document.

The IPR disclosure of AugPAKE has been filed.

https://datatracker.ietf.org/ipr/1284/

Currently, no objection to this disclosure is raised within the WG.

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

Because of no reviews about this document, I’m not sure the WG consensus.

(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 entered into the ID Tracker.)

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? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Yes, I have verified the document by the online Idnits Tool.

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

This document splits normative and informative references.

There are no normative references to IDs.

(1.i) Has the Document Shepherd verified that the document's IANA Considerations 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 [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

I’ve verified the IANA Considerations section (section 7) and this document requests IANA action to assign values. The requested reservations are in appropriate IANA registries and these registries are clearly identified as follows:

“IANA SHALL assign values for the PV payload and the Vrfy payload in "IKEv2 Payload Types" registry [IKEV2-IANA]. Also, IANA SHALL assign a value for AugPAKE in the "IKEv2 Authentication Method" registry [IKEV2-IANA].”

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

This document does not contain sections written in a formal language.

(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

This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary whose space is within the off-line dictionary attacks. The AugPAKE protocol described here is secure against passive attacks, active attacks and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). In addition, this document describes how the AugPAKE protocol is integrated into IKEv2.

-          Working Group Summary

This is not the product of a WG.

-          Document Quality

This document specifies a PAKE (called, AugPAKE) protocol for IKEv2. AIST (National Institute of Advanced Industrial Science and Technology) have implemented the AugPAKE protocol.

IANA has a question about the IANA Actions in this document.

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

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

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

the following payload types will be added:

PV and Vrfy

with a reference to the current document.

--> IANA QUESTION: what should the "Next Payload Type" description be
for these two payload types?

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

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

the following authentication method will be added as follows:

Value: [TBD]
Authentication Method: AugPAKE
Reference: [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
Reply-To: ietf@ietf.org
Subject: Last Call:  (Most Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Most Efficient Augmented Password-Only Authentication and Key Exchange
  for 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-shin-augmented-pake/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-shin-augmented-pake/