Dan: Thanks for the review comments. Sorry for not responding right away. The current plan is that we will publish a new revision today with the name change and etc, and Joe will start an issue list including the comments you made, as it will require some WG discussion, and then we will make another revision once we have consensus on them.
On 10/19/11 3:55 PM, "Dan Harkins" <dhark...@lounge.org> wrote: > > Hi Hao, > > About 6 weeks ago I sent in some detailed comments, notably > the request for a new TLV to pass a PKCS#10 to the server to go > along with the existing TLV that sends a PKCS#7 to the peer, and > for a server unauthenticated provisioning mode, and never heard > from the editors of the tunnel method draft. > > Do you have any response to those comments? > > regards, > > Dan. > > On Wed, October 19, 2011 12:31 pm, Hao Zhou wrote: >> 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 >> > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
