Jim: Please see inline.
-----Original Message----- From: Jim Schaad [mailto:i...@augustcellars.com] Sent: Wed 10/19/2011 7:54 PM To: Hao Zhou (hzhou); draft-ietf-emu-eap-tunnel-met...@tools.ietf.org; Sam Hartman Cc: emu@ietf.org Subject: RE: [Emu] Comments on the eap-tunnel-method-00 draft > -----Original Message----- > From: Hao Zhou [mailto:hz...@cisco.com] > Sent: Wednesday, October 19, 2011 12:31 PM > To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org > Cc: emu@ietf.org > Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft > > 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. Yes - but in this case I would expect a NAK from the client - possibly proposing other methods. Is this correct? [HZ] Yes, a NAK with other proposed EAP method if available. Will clarify in 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. Ok - this would be in violation of the last paragraph in section 3.1 which says that the version numbers MUST be done. [HZ] Good point. Seems like we need to crypto-binding every time if we want to protect the version number, EAP type, and outer TLVs. Will discuss and fix in next rev. > > >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. Please tell me where it says this is done. All I can see is that one CAN send intermediate-result, result and crypto-binding TLVs in the same message. (Unless of course only one is sent in which case the Intermediate-Reuslt TLV MUST NOT be sent). However these is nothing that says that the Crypto-binding TLV would be sent after the first and only EAP method - or indeed after a sequence of EAP methods. [HZ] It is described in Section 4.2.8, "The Crypto-Binding TLV MUST be included with the Intermediate-Result TLV to perform Cryptographic Binding after each successful EAP method in a sequence of EAP methods. The Crypto-Binding TLV can be issued at other times as well." We will clarify to make it clear that it MUST be done after each successful EAP method even if it's only one in the sequence. > > '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. Do you ever expect a version to allow multiple EAP sequences to be run at the same time? If not then just the statement that they MUST be executed serially is probably sufficient. [HZ] Ok. > > > 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. Ok - either I don't see the text or my comment is not sufficiently clear. Consider: Client is running EAP-BLAH and returns inside of the EAP-BLAH method a failure. If the client wants an overall failure rather than leaving it up to the server, does it send both the Result TLV failure and the EAP-Message w/ the failure - or just the result TLV failure or is this not reasonable for the client? [HZ] I would send both the EAP message failure and Result TLV failure, this way the server would have the indication that not only the EAP method failed, but also peer wants to fail the whole EAP. More information client sends to the server is probably better. > > > 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. Based on my reading I would not have thought that the server was to send a SECOND (and yes different) Result TLV in this case. [HZ] You are right. The current spec says server just send clear text EAP-Success and Failure if it ignores the Request-Action. To answer your original question, it's better that server use the one suggested by the client, as the client's state machine would be in the state of expecting the same clear text EAP success or failure. I don't know how many implementations actually reject the clear text EAP success or failure if it doesn't match the protected result, but it's safer for them to be in sync. Of course, EAP-Failure probably doesn't matter as the physical link might be severed afterward. > > > 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. What are you referring to for same as above? [HZ] Question 1 and 2 in this section. basically, they are the same question, multiple identities authenticated, what to use for Peer-ID. > > 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. > But this would be a limitation on the EAP method rather than on TLS. [HZ] It's actually an implementation or device limitation. EAP is not designed to carry large bulk of data, so I hope we don't run into too large fragmentation issues. > > 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. > Sam - do you see this as being an issue for abfab? [HZ] I have addressed this in another email thread. Will clarify it's bidirectional as defined in ChBind draft section 5.3. > > 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. Ok - I just misread this. Jim > > > > > > > > _______________________________________________ > > 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
