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. <Not fully sure that I really care about this case as long I can assume that if the mandatory bit is set then I would always fail the overall EAP conversation.> 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