Jim: Thanks for reviewing the draft in detail and comments provided. Please see my response inline below.
On 10/17/11 6:08 PM, "Jim Schaad" <i...@augustcellars.com> wrote: > 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? > [HZ] It depends. Server might want to proceed with other EAP type negotiation by proposing a different EAP type, or terminate the conversation with an EAP-Failure. I will clarify that in the next rev. > 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? > [HZ] It's up to client's policy, especially if the server cert is issued by a public CA. Client needs not only verify that the server cert presented is a valid cert signed by the trusted CA, but also the server name presented in the cert is matching the domain it tried to authenticate with. A FQDN in the CN or SAN would be a way to do it. > If no embedded EAP methods run, then no crypto check and thus no version # > checking is done. [HZ] That's true. >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 > [HZ] That's not true. Crypto-binding would still be exchanged with Result TLV. Actually using of the Result TLV in lieu of IM-Result TLV is for legacy reason in EAP-FAST, which could be removed in next rev since we are designing a new EAP method. > 'serially in a sequence' is redundant - section 3.3.1 > [HZ] Ok. The text is trying to distinguish from running multiple EAP methods in parallel. > 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 > [HZ] For simplicity, otherwise implementation would need to trace when the 1st method finishes and applies the key from the authentication to the crypto-binding. Supporting them in complete sequence makes it simpler and securer, as 2nd method might not be safe to run if the crypto-binging after 1st method fails. > 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? > [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send up some Fatal Error TLV and Result TLV to indicate the end. > 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 > [HZ] I think we can change to always send IM result after each inner EAP method, if only one inner method, then Result TLV could be sent as well. See explanation above. > 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? > [HZ] Server is supposed to send the suggested Result code in Request-Action TLV if it refuse to do the action, this way peer will get notify about the final result and in-sync with the clear text EAP-Success/Failure packet. Probably doesn't matter what the server sends, client would set the final result base on its policy. > 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? [HZ] Good question. There were some discussions on this. The new draft rev will propose to use the first authenticated peer identity. The WG can discuss more on this. > 2. What if multiple inner EAP methods are run - which Peer-Id is used then? [HZ] Same as above. > 3. What if client and machine EAP methods are run - which one to use then? > (Internal what are the ids used for?) > [HZ] Again, good question. Same as above. > 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 > [HZ] Should be fixed with the change on IM result TLV. > Section 3.6.2 - (internal) - if you get a TLV rules violation - does the TLV > itself need to be acknowledged? > [HZ] Probably no need to, as it is fatal and other side probably already terminated the tunnel. > Section 3.7 - Can I assume that the identifier value is monotonically > increasing and does not wrap? > [HZ] Yes. We shouldn't exceed the maximum number (256) for Identifier in a single EAP authentication, at least I hope not. > 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? > [HZ] Most likely it will be TLS error if one side is having trouble to receive or assemble the whole message. Additional error code could be defined to convey this. > 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. > [HZ] yes. I will add that. > Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding TLV - > not what it says in section 3.3 > [HZ] It says " A Result TLV indicating failure", as it doesn't matter anymore, the whole EAP authentication will fail. Section 3.3 is talking about a successful Result TLV. > 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.> > [HZ] Correct, I am not sure there is value sending back the other TLVs, as the authentication should be failed if the mandatory to implement is not supported. > 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. > [HZ] Currently, the Channel-binding TLV is an optional TLV, doesn't require acknowledgement, and is designed to be only one way, for client to send some channel binding data to the server for verification purpose. There is no feedback provided. The indication of whether the server supports channel-binding and/or validated the channel-binding could be conveyed in other TLVs to be added, if the WG agrees to be valuable. > 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. > [HZ] It's the version number of the Crypto-binding TLV, not the EAP version number. The theory is that we could enhance the crypto-binging TLV format in the future if desired. > > > > _______________________________________________ > 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
