> -----Original Message----- > From: Sam Hartman [mailto:[email protected]] > Sent: Monday, March 04, 2013 6:19 PM > To: Joseph Salowey (jsalowey) > Cc: Sam Hartman; Jim Schaad; <[email protected]> > Subject: Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method > > >>>>> "Joseph" == Joseph Salowey (jsalowey) <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/emu
