> The discussion here is (a) if we can get *some* generic authorization > passed via methods used for Channel Bindings, and (b) is that a good idea. > > I think that the answer to (a) is "yes", and (b) is "some say yes, > some say no".
Existing RFCs are clear that Channel Bindings have a specific purpose and are not a generic authorization mechanism. For example, RFC 3748 Section 7.15 states: " In order to address this vulnerability, EAP methods may support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS- Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162]. Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. Where discrepancies are found, these SHOULD be logged; additional actions MAY also be taken, such as denying access. " Given the above (and similar material in RFC 5247), it would seem (surprise!) that channel bindings relate to properties of the channel. Despite the confusion introduced by Section 1 of the Channel Bindings document, the parameters actually discussed in the Channel Bindings document generally appear consistent with existing work. I say "generally" because the document does appear to need an update or two. For example, Section 7.3.2 of the Channel Bindings document introduces the Mesh-Key-Distributor-Domain-Id. My understanding is that this parameter has been removed from 11s, so this section is now out of date.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
