The Extensible Authentication Protocol (EAP) [RFC3748] includes two
facilities related to channel binding. The first, called channel
binding, is used to bind the lower-layer channel created between the
peer and the authenticator to the authentication performed using EAP.
I think you need to be careful about the precise meaning of "bind" and
"lower layer channel" here.
Properties of the lower layer channel such as ciphersuite negotiation are
determined during the Secure Association Exchange. During the SAP other
parameters advertised or negotiated between the peer and authenticator can
be cryptographically bound to the transient session keys used between peer
and authenticator. For example, within IEEE 802.11i, the peer and
authenticator MAC address, ciphersuite
and capabilities are securely confirmed during the 4-way handshake.
In contrast, Channel Bindings as defined in RFC 3748 occur during the EAP
exchange. Its purpose is to confirm the consistency of channel properties
advertised by the authenticator to the peer and EAP server. However,
negotiation of the lower layer channel properties occurs during the SAP.
Specific details of this facility have not been specified, but it is
likely that this channel would use endpoint channel bindings carried
in the EAP method exchange.
Secure Association Protocols are specified in considerable detail within
IEEE 802.11i, IEEE 802.16e and IKEv2. Also, both RFC 3748 and the EAP Key
Management Framework discuss Channel Bindings. So saying it is "unspecified"
doesn't seem accurate.
The endpoint channel bindings would be defined for the specific lower
layer.
EAP Channel Bindings can be supported by an EAP method today without any
modification to lower layer specifications, so I don't think this is
correct.
EAP also has a facility called cryptographic binding, which is another
instance of channel binding.
Cryptographic binding as defined in RFC 3748 is used to demonstrate that the
endpoints of the EAP exchange participated in all portions of that exchange.
This does not relate to lower layer channel properties, per se.
Cryptographic binding refers to binding the channel created by a
tunneling EAP method to an inner authentication performed within that
method.
This is correct.
Cryptographic binding will likely use unique channel bindings.
Cryptographic binding doesn't ensure that the authenticator provides the
same information to both the peer and server, so that it doesn't address the
Channel Binding problem.
Do these changes make sense to people? Am I telling any lies or
conflating two architectures in a bad way?
In general, the changes are potentially confusing, but I do think that it
would be worthwhile to continue to work on improving the text.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf