An Extension for EAP-Only Authentication in IKEv2
draft-ietf-ipsecme-eap-mutual-05

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?

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? ;-)

Contains several unused references.