An Extension for EAP-Only Authentication in IKEv2
RFC 5998

Note: This ballot was opened for revision 05 and is now closed.

(Jari Arkko) Yes

Comment (2010-06-17 for -)
No email
send info
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.

(Sean Turner) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

Comment (2010-06-14 for -)
No email
send info
Contains several unused references.

(Adrian Farrel) (was Discuss) No Objection

Comment (2010-06-17)
No email
send info
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?

(David Harrington) (was Discuss) No Objection

Comment (2010-06-15)
No email
send info
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? ;-)

(Russ Housley) No Objection

(Alexey Melnikov) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection