Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
On Mar 1, 2013, at 7:15 AM, Sam Hartman hartmans-i...@mit.edu wrote: Jim == Jim Schaad i...@augustcellars.com writes: There doesn't seem to be a way for a server to request channel binding. If that's true we should probably add the following: Since a server cannot indicate a desire for channel binding, clients that Jim have channel binding data to send SHOULD include channel-binding TLV in a request-action TLV if mutual authentication (section 3.11) succeeded. Jim If this is true - then I agree it is a flaw. Jim I think that one could send a channel-binding TLV with no data Jim to request that a client send channel binding data back. This Jim should not cause any significant problems. If that's permitted then it should be explicitly documented. I think that if this is permitted, everyone who implements channel binding needs to be required to support this. Jim One could then have Channel-binding server-peer - no data Jim Channel-binding peer-server - here is my data Channel-binding Jim server-peer - here is my data Again, let's document this if it is permitted. It's clear the spec is unclear if you and I read if differently. [Joe] THis is a reasonable request. We'll need to make sure there is no ambiguity in the use of the empty message. Should this be covered in RFC 6677? Jim However I believe that the client can initiate this by just Jim sending the channel binding TLV in the clear and not in a Jim request if the client wants to initiate it. My reading is that you cannot send a channel binding outside of a request. This needs clarification as well if we're reading it differently. [Joe] I'm not sure what you are asking here. What is meant be sending the CB TLV in the clear and not in a request? do you mean a request-action TLV? ___ 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
Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
Joseph == Joseph Salowey (jsalowey) jsalo...@cisco.com writes: [Joe] THis is a reasonable request. We'll need to make sure there is no ambiguity in the use of the empty message. Should this be covered in RFC 6677? RFC 6677 doesn't talk about how you decide you're going to do channel binding. I had mostly assumed you'd throw it in with some other message I guess, although once you consider crypto binding that gets more complex because you want CB after crypto binding some of the time. Note that I'm not requesting any specific behavior. I'm simply requesting that you document either that a server cannot request CB (must start with client) or document how a server requests cb. The message defined in RFC 6677 always has a code, so an empty message is clearly not a 6677 message. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method
-Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Monday, March 04, 2013 6:19 PM To: Joseph Salowey (jsalowey) Cc: Sam Hartman; Jim Schaad; emu@ietf.org Subject: Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method Joseph == Joseph Salowey (jsalowey) jsalo...@cisco.com writes: [Joe] THis is a reasonable request. We'll need to make sure there is no ambiguity in the use of the empty message. Should this be covered in RFC 6677? RFC 6677 doesn't talk about how you decide you're going to do channel binding. I had mostly assumed you'd throw it in with some other message I guess, although once you consider crypto binding that gets more complex because you want CB after crypto binding some of the time. Note that I'm not requesting any specific behavior. I'm simply requesting that you document either that a server cannot request CB (must start with client) or document how a server requests cb. The message defined in RFC 6677 always has a code, so an empty message is clearly not a 6677 message. I agree - this is behavior that is described in this document and not in RFC 6677 - this is a how do you do it not a what is included type question. Jim ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Comments on draft-ietf-emu-eap-tunnel-method-05 - Set #2
I have been doing my best not to send this message but it has finally slipped out. I keep wondering if we need to do something much more explicit in terms of both identifying and purposing the certificates that are being used for this method. Question #1 - Do we expect that the client certificates would only be used for this purpose and not for general purpose TLS client authentication? I would be shocked if this was not true for the server certificates. If so does this mean that we should define an EKU for the purpose of doing EAP Tunnel Method (allow it to be used for all of the previous and future versions thus being generic)? Question #2 - Do we want to try and solve the question Sam has raised about naming of entities in certificates. This would mean defining a new OtherName extension to PKIX for the purpose of placing NAIs into certificates. This would allow for an NAI of the form @realm to be placed in a server certificate to define that it is the EAP server for the realm. This does assume that there will not be two different servers which are disjoint servicing the same realm but that would be a very unusual case. Jim ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
