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
|