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
