Section 4 defines two channel binding options - Binding channel information into the EAP method key derivation - Exchanging channel information between peer and authenticator for validation
These options are not mutually exclusive. For example a method could exchange data that is bound into the key derivation. This would give the method the option of continuing if it could not fully validate the parameters. This is important in cases where a peer or authenticator may not have access to certain lower layer parameters that are expected in the derivation. This could be due to the lack of a driver interface or the presence of a proxy between the authenticator and EAP server. Having the ability to signal what channel bindings are supported may be critical for having any of the solutions work in real existing deployments. Are the requirements for information in channel bindings the same across all deployments of a method on a lower layer? In some cases is the binding information uninteresting to the verifier. Should the verifier have to retrieve it anyway or should it just accept it? Would the exchange of parameters be useful even if the binding is done outside of EAP? I think the options in channel binding are between a strict policy and a flexible policy. In a strict policy, channel binding verification is done such that any variation in channel binding information will cause failure. In a flexible policy information is communicated between peer and server that allows them to recover from differences in channel binding information. It real deployments, given the varying state of drivers and back end architecture, it seems that a strict policy will not be deployable. Flexible policy adds some complexity, but it allows for the capability for deployments to enable channel binding functionality without breaking deployment. The policy would be lenient to begin with to provide information on if peers and authenticators are agreeing on the binding information and then can be tightened down as things become consistent. Although this is covered in section 10.1, I think it would be good to point out the difference in this section. I don't really find the difference between key derivation and exchanging parameters as useful as the difference between the ability to implement a flexible policy vs. enforcing a strict policy. Should we modify the section to focus on the differing policy approaches and add their effect on incremental deployment? Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
