[Emu] Comments on the eap-tunnel-method-00 draft
I have gathered these comments over time and therefore some of them are not fully fleshed out. If you have any questions I will try and reconstruct my ideas at the time. Jim Version Negotiation - terminate the conversation - w or w/o a fail? Edge case - what if peer only supports a higher version than the server supports? NAK? EAP Server Name Checking - On what basis does the client accept or not accept the EAP server name?You are suggesting that it is signed by a CA controlling the intended domain, but what does this mean? Are you suggesting that the CA should have a DNS subject alt name in it for the domain in question? If no embedded EAP methods run, then no crypto check and thus no version # checking is done. Also no checking done if only one inner EAP method is used as this only sends the Result TLV and not the Crypto-Binding TLV 'serially in a sequence' is redundant - section 3.3.1 Not only does it not allow initiating multiple EAP methods in parallel, it requires that they not be running in parallel. This is a more strict condition Para #3 - can the peer return an error and treat the failure of a specific EAP method as a total failure for the overall process - or at least recommend that it should be an overall failure? Confused messages in 3.3.1 and 3.3.3 about sending intermediate results and final results at the same time. Specifically 3.3.1 says MUST NOT for one inner EAP method, but text is not reflected in section 3.3.3 Conflict between 3.3.3 and security considerations (7.5) about sending a different value in the Result TLV and the clear result in the event of not doing a Request-Action TLV from the client. Is the server required to use the client suggested result in the event it does not perform the request action - could it use a different failure message or a success message? Does it matter? Section 3.4 - Need to address the following issues: 1. what if both certificates and an inner EAP method are run - what is the Peer-Id then? 2. What if multiple inner EAP methods are run - which Peer-Id is used then? 3. What if client and machine EAP methods are run - which one to use then? (Internal what are the ids used for?) Section 3.6 - item #2 - it should be noted that not all failure indications would be transmitted. The failure/success of the last EAP method may not be sent as it gets wrapped into the Result TLV message Section 3.6.2 - (internal) - if you get a TLV rules violation - does the TLV itself need to be acknowledged? Section 3.7 - Can I assume that the identifier value is monotonically increasing and does not wrap? Section 3.7 - it might be useful to tell me how to error for a message too big or response time too long in dealing with fragmentation - are both just final errors? Or should it potentially be treated as a TLS error? Section 3.2 - possible clarification. If all TLVs in a message are marked optional and none are understood by the peer, then an EMPTY response message must still be sent to the server. Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding TLV - not what it says in section 3.3 Section 4.2.3 - NAK TLV should not be accompanied by other TLVs. Not sure I understand why. If I send an EAP plus a vendor w/ mandatory set, should not I get back a NAK on the vendor plus a result for the EAP? I might be happy to not do the vendor, but want to distinguish between you cannot do this vs you choose not to do this. Section 4.2.10 - How can I know if the server does or does not process the channel binding TLV? This may be part of my policy as a peer depending on circumstances. Section 4.2.8 - Currently says that version should be 1 while the version defined in the intro sections is 2 - would be correct if we change the EAP method. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09
I have read emu-chbind-09. I have no major issue on the document. Especially I like the detailed background and general information about channel binding in Sections 3 and 4, great work. I have several comments. I hope they are minor. [1] As far as I understand, the method-based channel binding is not applicable to ERP. For completeness of the specification it may be good to add some text to clarify this. [2] While the document mentions transporting channel bindings within the lower layer's secure association protocol for a future alternative, it is also possible to extend EAP itself to transport channel bindings for another future alternative as well. I am just wondering why the latter alternative is not mentioned in the document. [3] Probably this was discussed in the WG, but I want to understand the motivation for the namespace in Channel Binding Encoding because it seems to be a hard requirement if the peer has to know what namespace (or protocol) is being used between an EAP authenticator and EAP server. Also, in some case, the channel binding operation may be performed with a standalone authenticator since, due to EAP's mode independence property, the peer does not know whether the authenticator it is talking to is a pass-through authenticator or a stand-alone one. What namespace should be used with a standalone authenticator? [4] The following comments are related to EAP Lower Layers Registry table: - "PANA (no pre-authentication)" is mentioned but without a reference. I suggest adding a reference to RFC 5191 for this entry. - Since there is also PANA pre-authentication (RFC 5873), I suggest adding an entry "PANA (pre-authentication) [RFC 5873]". - The entry for IEEE 802.11s does not make sense since IEEE 802.11s does not support EAP authentication AFAIK. Please check, and remove it if not needed. - IEEE 802.16m supports EAP. I suggest adding IEEE 802.16m. - IEEE 802.21a (which is under Sponsor Ballot in IEEE SA and the work is almost done) also supports EAP. I suggest adding IEEE 802.21a. (There may be some other EAP lower layers which I miss to mention.) [5] References [RFC4006] and [80211U-D4.01] are not used. Best Regards, Yoshihiro Ohba (2011/10/14 6:15), Joe Salowey wrote: > THe working group last call for draft-ietf-emu-chbind-09 ends October 21, > 2011. So far we have received few comments on the list. Please review > the document and post your comments to the list. Comments indicating that > you have read the document and not found any issues are also useful. > > Thanks, > > Joe > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
