issue 325 - channel bindings

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: jsaloweycisco.com
<mailto:jsaloweycisco.com>
>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

>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.

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.

>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.

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."


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

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
>> 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.
>
>
> 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.

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."

>> 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.
>
>
> 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.

I fully agree.

> 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.

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?

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

--Jari


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

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."


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

Ok.

Bernard Aboba wrote:

> 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."
>
>
>
>

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

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


On Mon, Mar 06, 2006 at 04:01:51AM -0800, Bernard Aboba
wrote:
> 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."
> 
> 
>
____________________________________________________________
_____
> To unsubscribe or modify your subscription options,
please visit:
> http:/
/lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.
frascone.com/pipermail/eap
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap