> -----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
