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

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Wed, 9 Jul 2008 11:11:11 -0400

Bernard:
 
Section 4.4 lists the requirement for channel binding as "The tunnel
method MUST be capable of supporting EAP channel bindings described
above.". I think this is the intent of the requirement. Section 4.1.1
language of "MUST support" might be too strong. Are you ok with changing
Section 4.1.1 to be consistent with Section 4.4?
 
I think this will allow WG to work on channel binding separately and if
deemed important, not requiring us to modify the tunnel method.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
	Sent: Thursday, June 26, 2008 3:50 AM
	To: [email-masked]
	Subject: [Emu] Requirements for Channel Binding in the Tunnel
Method Requirements document

	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

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 9 Jul 2008 14:08:20 -0700

Yes, changing the language to be consistent with Section 4.4 would be good.
I would also remove the reference to RFC 4962 Section 3, and substitute one
to RFC 4017 instead (since channel bindings are explicitly discussed there
and indicated as optional). 

From: Hao Zhou (hzhou) [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2008 8:11 AM
To: Bernard Aboba; [email-masked]
Subject: RE: [Emu] Requirements for Channel Binding in the Tunnel Method
Requirements document

Bernard:

Section 4.4 lists the requirement for channel binding as "The tunnel method
MUST be capable of supporting EAP channel bindings described above.". I
think this is the intent of the requirement. Section 4.1.1 language of "MUST
support" might be too strong. Are you ok with changing Section 4.1.1 to be
consistent with Section 4.4?

 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernard Aboba
Sent: Thursday, June 26, 2008 3:50 AM
To: [email-masked]
Subject: [Emu] Requirements for Channel Binding in the Tunnel Method
Requirements document

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

   either by the peer or the server, typically only the server has the

   knowledge to determine the correctness of the values, as opposed to

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 

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

   It is possible for problems to arise in situations where the EAP

   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,

   authentication server certificate will not be identical to the

   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.

   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