>>>>> "Bernard" == Bernard Aboba <bernard_aboba@xxxxxxxxxxx> writes:
>> 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.
Bernard> I think you need to be careful about the precise meaning
Bernard> of "bind" and "lower layer channel" here.
I'm using them consistently with the rest of the document.
Bernard> Properties of the lower layer channel such as ciphersuite
Bernard> negotiation are determined during the Secure Association
Bernard> Exchange. During the SAP other parameters advertised or
Bernard> negotiated between the peer and authenticator can be
Bernard> cryptographically bound to the transient session keys
Bernard> used between peer and authenticator. For example, within
Bernard> IEEE 802.11i, the peer and authenticator MAC address,
Bernard> ciphersuite and capabilities are securely confirmed
Bernard> during the 4-way handshake.
This is a true statement.
Bernard> In contrast, Channel Bindings as defined in RFC 3748
Bernard> occur during the EAP exchange. Its purpose is to confirm
Bernard> the consistency of channel properties advertised by the
Bernard> authenticator to the peer and EAP server. However,
Bernard> negotiation of the lower layer channel properties occurs
Bernard> during the SAP.
Understood and I believe that to be consistent with my text.
>> 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.
Bernard> Secure Association Protocols are specified in
Bernard> considerable detail within IEEE 802.11i, IEEE 802.16e and
Bernard> IKEv2. Also, both RFC 3748 and the EAP Key Management
Bernard> Framework discuss Channel Bindings. So saying it is
Bernard> "unspecified" doesn't seem accurate.
No one has defined the format of channel bindings and with the
possible exception of 802.11r I don't know of any lower layer that has
clearly defined what identity should be bound for that layer.
>> The endpoint channel bindings would be defined for the specific
>> lower layer.
Bernard> EAP Channel Bindings can be supported by an EAP method
Bernard> today without any modification to lower layer
Bernard> specifications, so I don't think this is correct.
How do I know what the lower layer identity is unless the lower layer
spec tells me
>> EAP also has a facility called cryptographic binding, which is
>> another instance of channel binding.
Bernard> Cryptographic binding as defined in RFC 3748 is used to
Bernard> demonstrate that the endpoints of the EAP exchange
Bernard> participated in all portions of that exchange. This does
Bernard> not relate to lower layer channel properties, per se.
I did not claim that cryptographic binding was related to lower layer
channel properties in EAP's sense of lower layer.
>> Cryptographic binding refers to binding the channel created by
>> a tunneling EAP method to an inner authentication performed
>> within that method.
Bernard> This is correct.
>> Cryptographic binding will likely use unique channel bindings.
Bernard> Cryptographic binding doesn't ensure that the
Bernard> authenticator provides the same information to both the
Bernard> peer and server, so that it doesn't address the Channel
Bernard> Binding problem.
This is a true statement; as best I can tell it is unrelated to
anything I've said.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf