Rereading the updated chbind draft, it has already defined the mechanism for two way communication and tunnel EAP draft just defined a TLV container to carry the Channel binding data defined in Section 5.3, so we should be ok. No change is needed on the tunnel EAP draft on this, other maybe called out Section 5.3.
On 10/19/11 8:22 PM, "Sam Hartman" <hartmans-i...@mit.edu> wrote: >>>>>> "Jim" == Jim Schaad <i...@augustcellars.com> writes: >>>> 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. >>> > > Jim>Sam - do you see this as being an issue for abfab? > > > It's an issue for EMU actually. > See Section 5.3 of draft-ietf-emu-chbind. > Channel binding must be two-way and must follow the semantics of that > section. > > And yes, draft-ietf-abfab-gss-eap depends on those semantics. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
