An Extension for EAP-Only Authentication in IKEv2
RFC 5998
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Lars Eggert No Objection
Contains several unused references.
(Jari Arkko; former steering group member) Yes
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; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
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?
(Alexey Melnikov; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Harrington; former steering group member) (was Discuss) No Objection
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? ;-)
(Gonzalo Camarillo; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection