> -----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? > > > 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. > > >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. > > '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. > > > 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? > > > 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. > > > 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? > > 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. > > 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? > > 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
