Subject: [Emu] Requirements for Channel Binding in the Tunnel Method Requirements document

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Jun 2008 00:50:29 -0700

Section 4.1.1 of the Tunnel Method Requirements document includes the following statement:

   In addition, the tunnel method MUST support EAP channel bindings to
   enable a system based on EAP to meet the additional requirements in
   Section 3 of RFC 4962.
While I have no problem with including support for channel bindings within the EMU tunnel method,
I do not believe that any requirement for EAP Channel Bindings can be inferred from Section 3 of RFC 4962. 
Here is what Section 3 says: 
         The context will include the peer and NAS identities in more
         than one form.  One (or more) name form is needed to identify
         these parties in the authentication exchange and the AAA
         protocol.  Another name form may be needed to identify these
         parties within the lower layer that will employ the session
         key.
Notice that neither this paragraph nor the ones surrounding it mention exported EAP keying material
specifically.  This omission was intentional -- the intent was to enable the requirement to be met by
subsequent cryptographic binding operations operating within lower layers.  As an example, 
IEEE 802.11r's PMK-R0 and PMK-R1 cryptographically bind the PMK/MSK to channel properties,
satisfying this requirement. 

Part of the reason that EAP channel bindings were not mandatory to implement is that they were (and remain)
undeployed, so that their practicality remains unproven.  For this reason, despite considerable
IESG pressure, RFC 4017 included EAP channel bindings only as an optional feature within 
Section 2.4, rather than promoting it to required or even recommended to implement. 

Between the publication of RFC 4017 and 4962, many aspects of EAP, including new methods,
RFC 3748 implementations, etc. moved ahead, but progress in the channel binding area
remained slow, so that the case for requiring EAP channel binding did not grow stronger.

As proof that EAP channel binding is NOT required by RFC 4962 Section 3, RFC 5247 
which was chartered to demonstrate how RFC 4962 requirements can met by
EAP/Secure Association/AAA systems does not mention EAP channel bindings at all in 
Section 5.4, which discussed how the RFC 4962 key binding requirements from Section 3 
can be met.  Rather, RFC 5247 Section 2.3 which discussed authenticator identification, mentions both
EAP channel binding and lower layer bindings in points (f) through (k), albeit without
normative language. 

Given the extensive discussion of RFC 4017 and 4962 on the IETF mailing list and various
other mailing lists, including the EAP WG list, it is therefore somewhat disappointing to see
something which could only garner IETF consensus as an optional capability promoted to 
mandatory, purely due to IESG re-interpretation of a BCP after publication. 

Given that the EMU WG has as a work item for development of an Internet Draft on EAP channel
binding, my advice is for the WG, through its analysis of the problem and the potential solutions,
to develop its own consensus as to the value and practicality of channel bindings, rather than 
allowing an opinion to be imposed upon it from the IESG.  

As a first step toward that, a concise statement of the problem is very important. 
Section 4.4 of the Tunnel Method Requirements document includes the following statement
of the Channel Binding problem:
   The so-called "lying NAS" problem is a well-documented problem with
   the current Extensible Authentication Protocol (EAP) architecture
   [RFC3748] when used with pass-through authenticators.  Here, a
   Network Access Server (NAS), or pass-through authenticator, may
   authenticate to the backend AAA infrastructure using one set of
   credentials, while representing contrary information to EAP peers.
The issue is not just whether the information presented to
the peer and server are contradictory, but also whether the information is correct. 
To make this clear, RFC 5247 Section 5.3.3 included additional text beyond
what was present in RFC 3748 Section 7.15:

   While the verification [of channel bindings] 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.  

The use of the term "credentials" in the short problem description is somewhat odd, since in 
AAA protocols, the credentials used for mutual authentication between the AAA client and server 
do not relate to channel binding parameters such as the NAS-Identifier.  For example, a AAA client 
can use a certificate containing a subjectAltName field of "aaaclient.example.com" to authenticate to the AAA server, 
whereas the enclosed NAS-Identifier attribute could contain a the R0KH-ID from IEEE 802.11r.
Such an Access-Request would be completely valid, and RFC 5247 Section 2.5 notes some of
the issues that can arise:

   It is possible for problems to arise in situations where the EAP
   server identifies itself differently to the EAP peer and
   authenticator.  For example, it is possible that the Server-Id
   exported by EAP methods will not be identical to the Fully Qualified
   Domain Name (FQDN) of the backend authentication server.  Where
   certificate-based authentication is used within RADIUS or Diameter,
   it is possible that the subjectAltName used in the backend
   authentication server certificate will not be identical to the
   Server-Id or backend authentication server FQDN.  This is not
   normally an issue in EAP, as the authenticator will be unaware of the
   identities used between the EAP peer and server.  However, this can
   be an issue for key caching, if the authenticator is expected to
   locate a backend authentication server corresponding to a Server-Id
   provided by an EAP peer.

   Where the backend authentication server FQDN differs from the
   subjectAltName in the backend authentication server certificate, it
   is possible that the AAA client will not be able to determine whether
   it is talking to the correct backend authentication server.  Where
   the Server-Id and backend server FQDN differ, it is possible that the
   combination of the key scope (Peer-Id(s), Server- Id(s)) and EAP
   conversation identifier (Session-Id) will not be sufficient to
   determine where the key resides.  For example, the authenticator can
   identify backend servers by their IP address (as occurs in RADIUS),
   or using a Fully Qualified Domain Name (as in Diameter).  If the
   Server-Id does not correspond to the IP address or FQDN of a known
   backend authentication server, then it may not be possible to locate
   which backend authentication server possesses the key.

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu