eap Mailing List: issue 325 - channel bindings

[Jari Arkko (jari.arkko]

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: jsalowey [at] cisco.com <mailto:jsalowey [at] cisco.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?