The text of Issue 404 is enclosed below. The suggested
resolution is based
on the following assumption:
"The purpose of the Peer-Id and Server-Id is to
identify the entities that
were involved in the creation of EAP keying material. Within
a tunnel method
the
EAP keying material could be derived solely from the outer
authentication
(as in EAP-TTLSv0), or it could be derived from a
combination of the outer
and inner exchanges.
Where the EAP keying material is derived solely from the
outer
exchange, the Peer-Id and Server-Id is determined based on
the
identities authenticated in the outer exchange. If the EAP
keying
material is derived from both the outer and inner exchanges,
then
the Peer-Id and Server-Id are determined based on the
identities
authenticated in both exchanges."
It has been asked how this relates to RFC 4718 Section 3.5,
which states:
"3.5. Identity for Policy Lookups When Using EAP
When the initiator authentication uses EAP, it is
possible that the
contents of the IDi payload is used only for AAA routing
purposes and
selecting which EAP method to use. This value may be
different from
the identity authenticated by the EAP method (see [EAP],
Sections 5.1
and 7.3).
It is important that policy lookups and access control
decisions use
the actual authenticated identity. Often the EAP server
is
implemented in a separate AAA server that communicates
with the IKEv2
responder using, e.g., RADIUS [RADEAP]. In this case,
the
authenticated identity has to be sent from the AAA server
to the
IKEv2 responder.
(References: Pasi Eronen's mail "RE:
Reauthentication in IKEv2",
2004-10-28. "Policy lookups" thread, Oct/Nov
2004. RFC 3748,
Section 7.3.)"
The question is whether the "authenticated
identity" referred to here is the
Peer-Id or not, and if it is the Peer-Id, whether this
creates any issues
for use of tunneled methods such as EAP-TTLSv0 within
IKEv2.
There are three user identities involved in an EAP/AAA
conversation:
1. The EAP-Response/Identity (or in the case of IKEv2, IDi).
This identity
is typically not modified by AAA proxies along the
authentication path, so
that original decorations if present, remain. Example:
juniper.net!pfunk bt.com
2. The User-Name. The EAP-Response/Identity is placed in
the User-Name
attribute by the NAS, but may be processed by AAA proxies in
order to remove
decoration, so that by the time it arrives at the AAA server
it is different
from the EAP-Response/Identity. Example: pfunkjuniper.net.
3. The Peer-Id.
Note that identities #1 and #2 are present in *all* EAP
methods, regardless
of whether they generate keys. Identity #3 is only present
in
key-generating methods (at least according to the suggested
resolution of
this issue).
I believe that RFC 4718 Section 3.5 above is actually
talking about the
User-Name attribute, not the Peer-Id. Since the User-Name
attribute (or
CUI) can be included in an Access-Accept, no new
functionality is required
within the AAA protocol to satisfy the requirement.
However, EAP methods are not shown to export the User-Name
within the
figures, so perhaps this should be added.
------------------------------------------------------------
-------------------------
Issue 404: Peer-Id & Server-Id in Tunneled Methods
Submitter name: Paul Funk
Submitter email address: pfunkjuniper.net
Date Submitted: April 7, 2007
Reference: http://lists.frascone.com/pipermail/eap/msg04709.html
Document: KEYING-18
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
Review of the EAP-TTLSv0 specification has raised some
questions
about how the Peer-Id is determined for tunneled methods:
1. What if multiple identities are being authenticated?
EAP-TTLSv0 can handle both mutual authentication in phase I
(via certificates) as well as one or more inner methods.
Are multiple Peer-Ids returned in this case, or is there
only
one (or none)?
2. What if Phase I used only server authentication and the
inner method
doesn't export a Peer-Id (e.g. EAP-MD5). Does the tunneled
method return
the null Peer-Id in this case?
3. Do Peer-Ids have a type?
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
Here is some revised text on the Peer-Id and Server-Id:
For Section 1.4:
Peer-Id
If an EAP method that generates keys authenticates one
or more
method-specific peer identities, those identities are
exported by
the method as the Peer-Id(s). It is possible for more
than one
Peer-Id to be exported by an EAP method. Not all EAP
methods
provide a method-specific peer identity; where this is
not
defined, the Peer-Id is the null string. In EAP
methods that do
not support key generation, the Peer-Id MUST be the
null string.
Where an EAP method that derives keys does not provide
a Peer-Id,
the EAP server will not authenticate the identity of
the EAP peer
with which it derived keying material.
Server-Id
If an EAP method that generates keys authenticates one
or more
method-specific server identities, those identities
are exported
by the method as the Server-Id(s). It is possible for
more than
one Server-Id to be exported by an EAP method. Not
all EAP
methods provide a method-specific server identity;
where this is
not defined, the Server-Id is the null string. If the
EAP method
not generate keying material, the Server-Id MUST be
the null
string. Where an EAP method that derives keys does
not provide a
Server-Id, the EAP peer will not authenticate the
identity of the
EAP server with which it derived EAP keying material.
For Sections 2.4 and 2.5:
2.4. Peer Identification
As described in [RFC3748] Section 7.3, the peer identity
provided in
the EAP-Response/Identity can be different from the peer
identities
authenticated by the EAP method. For example, the
identity provided
in the EAP-Response/Identity can be a privacy identifier
as described
in "The Network Access Identifier" [RFC4282]
Section 2. As noted in
[RFC4284], it is also possible to utilize a Network
Access Identifier
(NAI) for the purposes of source routing; an NAI utilized
for source
routing is said to be "decorated" as described
in [RFC4282] Section
2.7.
When EAP peer provides the Network Access Identity (NAI)
within the
EAP-Response/Identity, as described in [RFC3579], the
authenticator
copies the NAI included in the EAP-Response/Identity into
the User-
Name attribute included within the Access-Request. As
the Access-
Request is forwarded toward the backend authentication
server, AAA
proxies remove decoration from the NAI included in the
User-Name
Attribute; the NAI included within the
EAP-Response/Identity
encapsulated in the Access-Request remains unchanged. As
a result,
when the Access-Request arrives at the backend
authentication server,
the EAP-Response/Identity can differ from the User-Name
Attribute
(which can have some or all of the decoration removed).
In the
absence of a Peer-Id, the backend authentication server
SHOULD use
the contents of the User-Name Attribute, rather than the
EAP-
Response/Identity as the peer identity.
It is possible for more than one Peer-Id to be exported
by an EAP
method. For example, a peer certificate can contain more
than one
peer identity; in a tunnel method peer identities can be
authenticated both within an outer and inner exchange and
these
identities could be different in type and contents. For
example, an
outer exchange could provide a Peer-Id in the form of an
RDN, whereas
an inner exchange could identify the peer via its NAI or
MAC address.
Where EAP keying material is determined solely from the
outer
exchange, only the outer Peer-Id(s) are exported; where
the EAP
keying material is determined from both the inner and
outer
exchanges, then both the inner and outer Peer-Id(s) are
exported by
the tunnel method.
2.5. Server Identification
It is possible for more than one Server-Id to be exported
by an EAP
method. For example, a server certificate can contain
more than one
server identity; in a tunnel method server identities
could be
authenticated both within an outer and inner exchange and
these
identities could be different in type and contents. For
example, an
outer exchange could provide a Server-Id in the form of
an IP
address, whereas an inner exchange could identify the
server via its
FQDN or hostname. Where EAP keying material is
determined solely
from the outer exchange, only the outer Server-Id(s) are
exported by
the EAP method; where the EAP keying material is
determined from both
the inner and outer exchanges, then both the inner and
outer Server-
Id(s) are exported by the EAP method.
As shown in Figure 3, an authenticator can be configured
to
communicate with multiple EAP servers; the EAP server
that an
authenticator communicates with can vary according to
configuration
and network and server availability. While the EAP peer
can assume
that all EAP servers within a realm have access to the
credentials
necessary to validate an authentication attempt, it
cannot assume
that all EAP servers share persistent state.
Authenticators can be configured with different primary
or secondary
EAP servers, in order to balance the load. Also, the
authenticator
can dynamically determine the EAP server to which
requests will be
sent; in event of a communication failure, the
authenticator can fail
over to another EAP server. For example, in Figure 3,
Authenticator2
can be initially configured with EAP server1 as its
primary backend
authentication server, and EAP server2 as the backup, but
if EAP
server1 becomes unavailable, EAP server2 can become the
primary
server.
In general, the EAP peer cannot direct an authentication
attempt to a
particular EAP server within a realm; this decision is
made by AAA
clients. Nor can the peer determine which EAP server it
will be
communicating with, prior to the start of the EAP method
conversation. The Server-Id is not included in the EAP-
Request/Identity, and since the EAP server may be
determined
dynamically, it typically is not possible for the
authenticator to
advertise the Server-Id during the discovery phase. Some
EAP methods
do not export the Server-Id so that is is possible that
the EAP peer
will not learn which server it was conversing with after
the EAP
conversation completes successfully.
As a result, an EAP peer, on connecting to a new
authenticator or
reconnecting to the same authenticator, can find itself
communicating
with a different EAP server. Fast reconnect, defined in
[RFC3748]
Section 7.2, can fail if the EAP server that the peer
communicates
with is not the same one with which it initially
established a
security association. For example, an EAP peer
attempting an EAP-TLS
session resume can find that the new EAP-TLS server will
not have
access to the TLS Master Key identified by the TLS
Session-Id, and
therefore the session resumption attempt will fail,
requiring
completion of a full EAP-TLS exchange.
EAP methods that export the Server-Id MUST authenticate
the server.
However, not all EAP methods supporting mutual
authentication provide
a non-null Server-Id; some methods only enable the EAP
peer to verify
that the EAP server possesses a long-term secret, but do
not provide
the identity of the EAP server. In this case the EAP
peer will know
that an authenticator has been authorized by an EAP
server, but will
not confirm the identity of the EAP server. Where the
EAP method
does not provide a Server-Id, the peer cannot identify
the EAP server
with which it generated keying material. This can make
it difficult
for the EAP peer to identity the location of a key
possessed by that
EAP server.
As noted in [I-D.simon-emu-rfc2716bis] Section 5.2, EAP
methods
supporting authentication using server certificates can
determine the
Server-Id from the subject or subjectAltName fields in
the server
certificate. Validating the EAP server identity can help
the EAP
peer to decide whether a specific EAP server is
authorized. In some
cases, such as where the certificate extensions defined
in [RFC4334]
are included in the server certificate, it can even be
possible for
the peer to verify some Channel Binding parameters from
the server
certificate.
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.
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.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|