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

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 07 Apr 2007 15:14:30 -0700

>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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Apr 2007 18:07:40 -0500

So then the stuff to bind to exists but no spec says "the EAP channel
bindings for this kind of L2 association is XYZ" and we all have a good
idea of what that text should read like, right?

On Mon, Apr 09, 2007 at 03:52:31PM -0700, Bernard Aboba wrote:
> 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.
>  
> [BA] As outlined in RFC 3748 and the EAP Key Management Framework, channel binding matching is designed to be a mechanical process, which implies that they are communicated in the form of AAA attributes. 
>  
> For example, the following AAA attributes can be sent from the NAS to the AAA server for IEEE 802: 
>  
> Called-Station-Id:  Authenticator Port MAC address or AP BSSID (potentially with the SSID)
> Calling-Station-Id:  Supplcant MAC address
> NAS-Identifier:  Authenticator identifier (IEEE 802.11r R1KH-ID)
> 
> >How do I know what the lower layer identity is unless the lower layer
> >spec tells me
>  
> Lower layer specifications already define the source MAC addresses (e.g. IEEE 802), and in some cases, authenticator identities (IEEE 802.11r).   So no additional lower layer standards are required.