Re: Last call comments: draft-williams-on-channel-binding-01.txt:EAP chann

>>>>> "Bernard" == Bernard Aboba
<bernard_abobahotmail.com> 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 mailing list
Ietfietf.org
https://w
ww1.ietf.org/mailman/listinfo/ietf