Subject: [eap] issue: channel bindings in keying framework doc

From: Jari Arkko <[email-masked]>
Date: Mon, 18 Jul 2005 14:10:30 +0300

Submitter name: Jari Arkko

Submitter email address: [email-masked] <mailto:[email-masked]>
Date first submitted: 18/7/2005
Document: KEYING-07
Comment type: T
Priority: S
Section: 1.3 and 6.7
Rationale/Explanation of issue:

I reviewed -07's text about channel bindings. Please find below
some suggested edits that take into account some of the discussion
about channel bindings in recent months.

>1.3 ...
>
>   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 MUST treat
>      Channel Bindings as opaque octets.

s/EAP methods MUST treat Channel Bindings as opaque octets/EAP methods
that transport Channel Bindings 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.
>
>6.7.  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 protocol).
>
>   Where EAP is used in pass-through mode, the EAP peer typically does
>   not verify the identity of the pass-through authenticator, it only
>   verifies that the pass-through authenticator is trusted by the EAP
>   server. This creates a potential security vulnerability, described in
>   [RFC3748] Section 7.15.
>
>   [RFC3579] Section 4.3.7 describes how an EAP pass-through
>   authenticator acting as a AAA client can be detected if it attempts
>   to impersonate another authenticator (such by sending incorrect 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 AAA server while communicating misleading
>   information to the EAP peer via a lower layer protocol.
>
>   For example, it is possible for a compromised authenticator to
>   utilize another authenticator's Called-Station-Id or NAS-Identifier
>   in communicating with the EAP peer via a lower layer protocol, or for
>   a pass-through authenticator acting as a AAA client to provide an
>   incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
>   server via the AAA protocol.
>
>   As noted in [RFC3748] Section 7.15, this vulnerability can be
>   addressed by use of 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.  For example, see
>   [ServiceIdent].

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

The main difference between these approaches is that in the EAP-based
case an upgrade to an EAP method that supports Channel
Binding data transport is needed, impacting both the peer and the
server. In the AAA-based case the peer and the server are impacted
as well, but not at the EAP layer. However, a modification
of the authenticator is needed in the AAA-based case.

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Jul 2005 09:12:18 -0700 (PDT)

> of the authenticator is needed in the AAA-based case.

How about this?

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.  For example,
see [ServiceIdent].

It is also possible to achieve Channel Bindings without transporting
data over EAP.  For example, see [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 its
AAA-Key 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.

The main difference between these approaches is that Channel
Binding support within an EAP method may require upgrading or
changing the EAP method, impacting both the peer and the
server.   Where Channel Bindings are implemented
in AAA,  the peer, authenticator and the backend server need to be
upgraded, but the EAP method need not be modified.