An Extension for EAP-Only Authentication in IKEv2
RFC 5998

Received changes through RFC Editor sync (changed abstract to 'IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards.

This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. [STANDARDS-TRACK]')

[Ballot comment]
I'm glad to see this extension/relaxation move forward. It is needed.
Thanks for writing this draft and bringing it up to the approval stage.

[Ballot comment]
Section 4

  The following EAP methods are believed to be secure when used with
  the current extension.  In addition, there are likely other safe
  methods which have not been listed here.

I found this text less than helpful.

"believed to be secure" by whom? It surely makes a diffuerence whether
we are talking about my 3 year old grandson or my 18 year old dog.

"there are likely other safe methods which have not been listed here"
Well, thanks! How is that helpful?

[Ballot discuss]
I am no expert, but I found this document very readable. Thanks.

It looks to me that this document is updating the IKEv2 specification.
As the Abstract says...
  IKEv2 specifies that EAP authentication must be used together with
  public key signature based responder authentication.
But this document seems to change that rule. So that would make it an
update to RFC 4306 wouldn't it?

[Ballot comment]
1) I found it odd to have channel binding in the table in section 4, when there had been no discussion of channel bindings. I actually notated the text as "why discuss this here?" I found the discussion of the importance of channel bindings in section 6.2, which made it clear why this was being included in the table. I recommend moving the discussion of channel bindings (the 3-paragraph short summary from 6.2) prior to the table (or move the table back)

2) I found the text odd in 6.2 that says AAA proxies MUST be trusted ... and avoided. I assume there is someplace in the AAA standard that says that proxies MUST be trusted; it would be nice to specify where that is stated. and then it would be nice to explain WHY they should be avoided.

3) section 6.4 says "(The EAP Identity request/response pair is omitted, as usual in IKEv2.)" Does this mean the pair is omitted in IKEv2 documents by convention, or omitted in protocol exchanges? if this means protocol exchanges, can you cite where this is defined?

4) section 6.4 says ""In the context of the extension described here, this guidance applies both to the authentication of the client by the gateway and vice versa." I find this unclear. I find "In the context of the extensions described here" rather abstract. The guidance appears to be that one should use the EAP authenticated identity, but it is unclear to me when this should be used. The paragraph talsk about routing AAA messages and selecting authentication and EAP types, but it seems to be me it cannot be used when routing AAA messages and to select authentication, since you wouldn't have an authenicated EAP identity yet. Could this paragraph, or at least applicability of the guidance, be restated?

5) in section 6, "this is somewhat unfortunate" seems to be an opinion that doesn't seem helpful to nayboidy implementing this standard. Do we need it here?

7) 6.5 put a discussion about responder indentity in the middle of a discussion about initiator identity.  The third paragraph seems much more natural directly after paragraph 1.

8) B1. what ar ethe pro and cons of B1? of B.2? of B.3?

9) g^xy might be well-known to IKEv2 experts; should I just assume it is an abbreviation for galaxy? ;-)

[Ballot discuss]
1) A number of terms are used without first expansion. for example, SK_pi, SK_pr, the terms in the flow diagram of section 3 (SAi1, KEi, Ni, etc.) I realize these are probably well-known to IKEv2 implementers, but not necessarily to others. I recommend, at a minimum, a comma-separated list of these terms and where their definitions can be found.

2) section 6.3 identifies a vulnerability, but provides no recommendations for how to mitigate the threat. If this vulnerability cannot be mitigated, then I question whether this should be approved as a standard.

3) section 6.3 talks about "(in message #3)" - where is message #3 defined? also messages 1,2, 3, and 4 in section 3.

IANA comments:

Upon approval of this document, IANA will make the following assignment
in the "IKEv2 Notify Message Types - Status Types" registry at
http://www.iana.org/assignments/ikev2-parameters

Value NOTIFY MESSAGES - STATUS TYPES Reference
----- ------------------------------ ---------
TBD EAP_ONLY_AUTHENTICATION [RFC-ipsecme-eap-mutual-02]

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

The document shepherd is Paul Hoffman, co-chair of the ipsecme WG. I have reviewed it 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 has had a fair amount of review within the ipsecme WG in its many incarnations. I do not have any concerns about these reviews.

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

I have no such concerns. The document lies fully within the ipsecme WG's area of expertise.

(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 such concerns. There have been no IPR disclosures.

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

The WG consensus was quiet, but there were enough people who read the document and no disagreement. At least one developer has put experimental support for the protocol in their implementation and said that the document could move forwards.

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

(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, I have personally verified that. (There are a few dangling references that are no longer called out in the text, but those can be fixed after IETF LC.) No formal review criteria are applicable.

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

There is one normative reference to a non-RFC, and that is in IESG review.

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

The has an IANA consideration that is appropriate.

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

This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures.

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?

Nothing worth noting: it got an adequate amount of review.

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?

One developer said they had implemented this experimentally and hand no problem. There are other developers who have expressed interest in implementing it in the future.