Skip to main content

An Extension for EAP-Only Authentication in IKEv2
RFC 5998

Yes

(Sean Turner)

No Objection

(Alexey Melnikov)
(Dan Romascanu)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Tim Polk)

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

Lars Eggert No Objection

Comment (2010-06-14)
Contains several unused references.

(Jari Arkko; former steering group member) Yes

Yes (2010-06-17)
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

Yes ()

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2010-06-17)
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

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Harrington; former steering group member) (was Discuss) No Objection

No Objection (2010-06-15)
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

No Objection ()

                            

(Peter Saint-Andre; former steering group member) No Objection

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Stewart Bryant; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) No Objection

No Objection ()