Subject: [eap] issue 325 - channel bindings

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Mar 2006 11:15:48 +0200

Text proposal. In 3.1, change

Channel Bindings

   Channel Bindings include lower layer parameters that are verified for
   consistency between the EAP peer and server.  In order to avoid
   introducing media dependencies, EAP methods that transport Channel
   Binding data MUST treat this data as opaque octets.  Typically the
   EAP method imports Channel Bindings from the lower layer on the peer,
   and transmits them securely to the EAP server, which exports them to
   the lower layer.  However, transport may occur from EAP server to
   peer, or may be bi-directional.  On the side of the exchange (peer or
   server) where Channel Bindings are verified, the lower layer passes
   the result of the verification (TRUE or FALSE) up to the EAP method.

to

Channel Bindings

   Channel Bindings include lower layer parameters that are verified for
   consistency between the EAP peer and server.  In order to avoid
   introducing media dependencies, EAP methods that transport Channel
   Binding data MUST treat this data as opaque octets.  Typically the
   EAP method imports Channel Bindings from the lower layer on the peer,
   and transmits them securely to the EAP server, which exports them to
   the lower layer.  However, transport may occur from EAP server to
   peer, or may be bi-directional.  On the side of the exchange (peer or
   server) where Channel Bindings are verified, the lower layer passes
   the result of the verification (TRUE or FALSE) up to the EAP method.
   It is also possible that the verification is performed entirely
   within the EAP layer. In this case, the EAP layer exports only the
   result to the lower layer. Given that EAP treats the data as opaque
   octets, verification at the EAP layer can only be performed as
   an exact match.

And change in 1.4 this

   The successful completion of an EAP method that supports key
   derivation results in the export of keying material on the EAP peer
   and server.  Even though the EAP peer or server may import Channel-
   Bindings that may include the identity of the EAP authenticator,
   this information is treated as opaque octets.  As a result, within
   EAP the only relevant identities are the Peer-ID and Server-ID.
   Channel Bindings are only interpreted by the lower layer.

to

   The successful completion of an EAP method that supports key
   derivation results in the export of keying material on the EAP peer
   and server.  Even though the EAP peer or server may import Channel-
   Bindings that may include the identity of the EAP authenticator,
   this information is treated as opaque octets.  As a result, within
   EAP the only relevant identities are the Peer-ID and Server-ID.

--Jari

>*ssue 325: Channel Bindings*
>Submitter name: Joe Salowey
>Submitter email address: [email-masked] <mailto:[email-masked]>
>Date Submitted: December 1, 2005
>Reference: 
>Document: Keying-08
>Comment type: T
>Priority: 1 
>Section: 1.3, 1.4
>Rationale/Explanation of issue: 
>
>Section 1.3
>
> 
>
>There are two styles of channel bindings that may be supported by EAP
>methods. The text in this section describes exportable channel bindings.
>There is also the approach where the bindings are non exportable.  In
>this case the method does a binary comparison of the channel bindings or
>hash of the channel bindings and fails if the result does not match.  I
>can see the possibility of a method supporting both styles.  Should we
>include both?
>
> 
>
>Section 1.4
> 
>Exportable channel binding are references in this section,
>non-exportable ones are not.  If we make changes to this affect above
>then we should change it here as well. 
>
> 
>
>[Bernard Aboba] Can you provide 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: "Bernard Aboba" <[email-masked]>
Date: Mon, 06 Mar 2006 03:26:14 -0800

>EAP method imports Channel Bindings from the lower layer on the peer,  and 
>transmits them securely to the EAP server, which exports them to

As noted earlier by Yoshi, while channel binding comparisons
can be done on either the peer or server, only the server can verify that
the values are actually *correct*.  A peer cannot do this because it does
not have knowledge of the infrastructure.  Therefore while the channel
bindings can be passed in both directions, it seems that it is only
possible to address the "impersonation" problem if they are passed in the
direction of peer to server.  This is probably worth noting.

>octets, verification at the EAP layer can only be performed as

I'm not sure how this is supposed to work. The channel bindings which are
passed to the backend authentication server depend on what attributes the
NAS sends.  For example, it is not mandatory for a NAS to send
Called-Station-ID or Calling-Station-ID to the backend authentication
server.  An 802.11r implementation might send a
"Mobility-Domain-ID" attribute, while an 802.11i implementation
woudl not.  Similarly, the Channel Bindings sent up by the lower layer may
vary according to the implementation.

Given this, some policy is typically required in order to determine which
of the attributes MUST match, which can be ignored, what actions
are taken, etc.

Requiring an "exact match" would imply that exactly the same attributes
are sent by the NAS as are sent up by the particular driver
implementation, in the same format.  This would be very brittle;
unless the EAP peer, server and authenticator implementations are provided
by the same vendor, this seems unlikely to work reliably.

>Channel Bindings are only interpreted by the lower layer.

Maybe this should be "only interpreted by the lower layer or AAA layer."

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Mar 2006 13:38:13 +0200

Bernard Aboba wrote:

>> Channel Bindings
>>
>> Channel Bindings include lower layer parameters that are verified 
>> for   consistency between the EAP peer and server.  In order to avoid
>> EAP method imports Channel Bindings from the lower layer on the 
>> peer,  and transmits them securely to the EAP server, which exports 
>> them to
>> peer, or may be bi-directional.  On the side of the exchange (peer 
>> or  server) where Channel Bindings are verified, the lower layer passes

Right. Add "While the verification can be done eithe rby the peer
or the server, typically only the server would have knowledge to
determine the correctness of the values, as opposed to merely
verifying their equality."

> of the attributes MUST match, which can be ignored, what actions

I fully agree.

> by the same vendor, this seems unlikely to work reliably.

Yes. We are not claiming that the approach is a good one, just that
its possible and that it has some issues (such as requiring exact match).
Do we want more text about the brittleness, or do you want to delete
the change altogether?

> Maybe this should be "only interpreted by the lower layer or AAA layer."
Ok.

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 06 Mar 2006 04:01:51 -0800

How about this?

"Channel Bindings include lower layer parameters that
are verified for consistency between the EAP peer and server.
In order to avoid introducing media dependencies, EAP
methods that transport Channel Binding data MUST treat this
data as opaque octets.

Typically the EAP method imports Channel Bindings from the
lower layer on the peer, and transmits them securely to the
EAP server, which exports them to the lower layer or AAA layer.  However,
transport may occur from EAP server to peer, or may be
bi-directional.  On the side of the exchange (peer or server)
where Channel Bindings are verified, the lower layer or AAA layer passes
the result of the verification (TRUE or FALSE) up to the
EAP method.

While the verification can be done either by the peer
or the server, typically only the server has the knowledge to
determine the correctness of the values, as opposed to merely
verifying their equality."

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Mar 2006 14:08:52 +0200

Ok.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 6 Mar 2006 11:45:53 -0500

It may be too late to make comment on this, but if we agree on only
the server has the knowledge of the Channel Binding values, I really
don't see any value on carrying Channel Bindings over EAP methods
compared to the other method of using the Channel Bindings for key
derivation.  Please correct if my view is wrong.

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 6 Mar 2006 20:43:30 -0800

> derivation.  Please correct if my view is wrong.
Yes, i miss the value in just the server and peer checking for consitency
in values. Unless the server can check the values against a pre-configured
database, channel bindings is of little use. Or if there is some use,
someone should explain what it is.

-mohan