>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.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
