![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
Dan Harkins stated: “ I don't think what you're talking about falls into the definition of
"channel binding", at least not the one I have, and I wouldn't be surprised
if others (like maybe people on the IESG) agree. And I agree
with Dave, and Glen, that this isn't authentication either.” RFC 3748 and RFC 5247 define Channel Bindings as well as
describing their use within the EAP architecture. For example, RFC 5247 Section
1.4 defines discusses potential uses of Channel Bindings by EAP methods: “ Channel Binding
Channel binding is the process by which lower-layer parameters are
verified for consistency between the EAP peer and server. In
order to avoid introducing media dependencies, EAP methods that
transport channel binding parameters MUST treat this data as opaque octets.” Given that Channel Bindings are to be treated as opaque
octets by the EAP method, and that they are Intended for use in encoding lower layer parameters, it’s
hard to see how Channel Bindings could be construed as a general authorization mechanism. |