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 PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Bernard Aboba
Sent: Thursday, June 26, 2008 3:50 AM
To: emu@ietf.org
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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
