Subject: [eap] Proposed Resolution to Issue 352: Channel Binding Issue

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 04 Jun 2006 18:31:15 -0700

The text of Issue 352 is enclosed below.  In looking through the document, I 
believe it is best that discussion of Channel Bindings be concentrated in 
Section 5.11.

The proposed resolution is as follows:

In Section 1.4, change the Channel Binding entry from:

"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 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.  See Section 5.11 for further discussion."

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.
      See Section 5.11 for further discussion."

Replace Section 5.11 with the following:

"5.11.  Channel Binding

   It is possible for a compromised or poorly implemented EAP
   authenticator to communicate incorrect information to the EAP peer
   and/or server.  This may enable an authenticator to impersonate
   another authenticator or communicate incorrect information via out-
   of-band mechanisms (such as via AAA or the lower layer).

   Where EAP is used in pass-through mode, the EAP peer does not verify
   the identity of the pass-through authenticator.  Within the Secure
   Association Protocol, the EAP peer and authenticator only demonstrate
   mutual possession of the transported EAP keying material.  This
   creates a potential security vulnerability, described in [RFC3748]
   Section 7.15.

   As described in the previous section, it is possible for a proxy to
   detect a AAA client attempting to impersonate another authenticator
   (such by sending incorrect Called-Station-Id [RFC2865], NAS-
   Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
   [RFC3162] attributes via the AAA protocol).  However, it is possible
   for a pass-through authenticator acting as a AAA client to provide
   correct information to the backend authentication server while
   communicating misleading information to the EAP peer via the lower
   layer.

   For example, a compromised authenticator can utilize another
   authenticator's Called-Station-Id or NAS-Identifier in communicating
   with the EAP peer via the lower layer.  Also, a pass-through
   authenticator acting as a AAA client can provide an incorrect peer
   Calling-Station-Id [RFC2865][RFC3580] to the backend authentication
   server via the AAA protocol.

   As noted in [RFC3748] Section 7.15, this vulnerability can be
   addressed by EAP methods that support a protected exchange of channel
   properties such as endpoint identifiers, including (but not limited
   to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id
   [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
   [RFC2865], and NAS-IPv6-Address [RFC3162].

   Using such a protected exchange, it is possible to match the channel
   properties provided by the authenticator via out-of-band mechanisms
   against those exchanged within the EAP method.  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. For further discussion, see
   [I-D.arkko-eap-service-identity-auth].

   It is also possible to achieve Channel Bindings without transporting
   data over EAP.  For example, see [I-D.draft-ohba-eap-channel-binding].
   In this approach the EAP method includes Channel Bindings in the
   calculation of exported EAP keying material, making it impossible for
   the peer and authenticator to complete the Secure Association Protocol
   if there is a mismatch in the Channel Bindings.  However, this approach
   can only be applied where EAP methods generating key material are used
   along with lower layers that utilize the keying material.  For example,
   this mechanism would not enable verification of Channel Bindings on
   wired IEEE 802 networks which do not support data frame protection."

----------------------------------------------------------------------------------------------------------
Issue 352: Channel Binding Issue
Submitter name: Yoshihiro Ohba
Submitter email address: [email-masked]
Date Submitted: April 25, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04216.html
Document: Keying-12
Comment type: T
Priority: 1
Section: 5.11
Rationale/Explanation of issue:

Reference [I-D.draft-ohba-eap-aaakey-binding] should be obsoleted by
its successor, i.e., [I-D.draft-ohba-eap-channel-binding] which
provides more generic, complete and extensible way of channel binding.
Note that pre-configuration of the parameter set on AS is an important
property to achieve Channel Binding in 3-party key management.

Change:

"  It is also possible to achieve Channel Bindings without transporting
   data over EAP.  For example, see [I-D.draft-ohba-eap-aaakey-binding].
   In this approach the authenticator informs the backend server about
   the Channel Binding parameters using AAA, and the backend server
   calculates transported keying material based on this parameter set,
   making it impossible for the peer and authenticator to complete the
   Secure Association Protocol if there was a mismatch in the
   parameters."

to:

"  It is also possible to achieve Channel Bindings without
   transporting data over EAP.  For example, see
   [I-D.draft-ohba-eap-channel-binding].  In this approach the backend
   server calculates transported keying material based on the
   parameter set pre-configured for the authenticator, making it
   impossible for the peer and authenticator to complete the Secure
   Association Protocol if there was a mismatch in the parameters."

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

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 06 Jun 2006 16:01:54 -0400

I have one comment.

>    wired IEEE 802 networks which do not support data frame protection."

The last sentence is correct when 802.1X is used as EAP transport over
wired IEEE 802 networks, but not correct when PANA is used where it is
still possible to enable verification of Channel Bindings with this
scheme by protected PANA-Bind exchange as I mentioned to Joe.

I would suggest revising the last two sentences something like:

"
  However, this approach can only be applied where EAP methods
  generating key material are used
  along with lower layers that utilize the keying material for data frame frame 
  protection.  For example, this mechanism would not enable verification of Channel
  Bindings on wired IEEE 802 networks using IEEE 802.1X.
"

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 06 Jun 2006 16:18:30 -0400

>   Bindings on wired IEEE 802 networks using IEEE 802.1X.

Sorry for self-responding, but the penultimate sentence does not need
to be changed.  My suggestion is for the last sentence only.

Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Jun 2006 13:36:45 -0700

>to be changed.  My suggestion is for the last sentence only.

Here is the new paragraph:

"It is also possible to achieve Channel Bindings without transporting
data over EAP.  For example, see [I-D.draft-ohba-eap-channel-binding].
In this approach the EAP method includes Channel Bindings in the
calculation of exported EAP keying material, making it impossible for
the peer and authenticator to complete the Secure Association Protocol
if there is a mismatch in the Channel Bindings.
However, this approach can only be applied where EAP methods
generating key material are used
along with lower layers that utilize the keying material for data frame 
frame
protection.  For example, this mechanism would not enable verification of
Channel Bindings on wired IEEE 802 networks using IEEE 802.1X."

Is this what you intended?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 06 Jun 2006 18:01:36 -0400

> Is this what you intended?

Not exactly.  In the PANA usage for wired IEEE 802 networks the keying
material is not for data frame protection, but just for protecting
PANA messaging.

So here is my intended text:

"
It is also possible to achieve Channel Bindings without transporting
data over EAP.  For example, see [I-D.draft-ohba-eap-channel-binding].
In this approach the EAP method includes Channel Bindings in the
calculation of exported EAP keying material, making it impossible for
the peer and authenticator to complete the Secure Association Protocol
if there is a mismatch in the Channel Bindings.  However, this
approach can only be applied where EAP methods generating key material
are used along with lower layers that utilize the keying material.
For example, this mechanism would not enable verification of Channel
Bindings on wired IEEE 802 networks using IEEE 802.1X.
"

Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 06 Jun 2006 19:26:21 -0700

Got it.