use the permanent identity. On fast re-authentication (discussed in
Section 5), the server MAY include a new, encrypted fast re-
authentication identity in the EAP-Request/AKA-Reauthentication
message.
On receipt of the EAP-Request/AKA-Challenge, the peer MAY decrypt the
encrypted data in AT_ENCR_DATA; and if a pseudonym username is
included, the peer may use the obtained pseudonym username on the
next full authentication. If a fast re-authentication identity is
included, then the peer MAY save it together with other fast re-
authentication state information, as discussed in Section 5, for the
next fast re-authentication.
If the peer does not receive a new pseudonym username in the
EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym
username instead of the permanent username on next full
authentication. The username portions of fast re-authentication
identities are one-time usernames, which the peer MUST NOT re-use.
When the peer uses a fast re-authentication identity in an EAP
exchange, the peer MUST discard the fast re-authentication identity
and not re-use it in another EAP authentication exchange, even if the
authentication exchange was not completed.
4.1.1.9. Usage of the Pseudonym by the Peer
When the optional identity privacy support is used on full
authentication, the peer MAY use a pseudonym username received as
part of a previous full authentication sequence as the username
portion of the NAI. The peer MUST NOT modify the pseudonym username
received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer
MAY need to decorate the username in some environments by appending
or prepending the username with a string that indicates supplementary
AAA routing information.
When using a pseudonym username in an environment where a realm
portion is used, the peer concatenates the received pseudonym
username with the "@" character and an NAI realm portion. The
selection of the NAI realm is discussed above. The peer can select
the realm portion similarly, regardless of whether it uses the
permanent username or a pseudonym username.
4.1.1.10. Usage of the Fast Re-Authentication Identity by the Peer
On fast re-authentication, the peer uses the fast re-authentication
identity received as part of the previous authentication sequence. A
new fast re-authentication identity may be delivered as part of both
full authentication and fast re-authentication. The peer MUST NOT
modify the username part of the fast re-authentication identity
received in AT_NEXT_REAUTH_ID, except in cases when username
decoration is required. Even in these cases, the "root" fast
re-authentication username must not be modified, but it may be
appended or prepended with another string.
4.1.2. Communicating the Peer Identity to the Server
4.1.2.1. General
The peer identity MAY be communicated to the server with the
EAP-Response/Identity message. This message MAY contain the
permanent identity, a pseudonym identity, or a fast re-authentication
identity. If the peer uses the permanent identity or a pseudonym
identity, which the server is able to map to the permanent identity,
then the authentication proceeds as discussed in the overview of
Section 3. If the peer uses a fast re-authentication identity, and
if the fast re-authentication identity matches with a valid fast
re-authentication identity maintained by the server, then a fast
re-authentication exchange is performed, as described in Section 5.
The peer identity can also be transmitted from the peer to the server
using EAP-AKA messages instead of EAP-Response/Identity. In this
case, the server includes an identity requesting attribute
(AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the
EAP-Request/AKA-Identity message; and the peer includes the
AT_IDENTITY attribute, which contains the peer’s identity, in the
EAP-Response/AKA-Identity message. The AT_ANY_ID_REQ attribute is a
general identity requesting attribute, which the server uses if it
does not specify which kind of an identity the peer should return in
AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to
request either the permanent identity or a pseudonym identity. The
server uses the AT_PERMANENT_ID_REQ attribute to request that the
peer send its permanent identity. The EAP-Request/AKA-Challenge,
EAP-Response/AKA-Challenge, or the packets used on fast re-
authentication may optionally include the AT_CHECKCODE attribute,
which enables the protocol peers to ensure the integrity of the
AKA-Identity packets. AT_CHECKCODE is specified in Section 10.13.
The identity format in the AT_IDENTITY attribute is the same as in
the EAP-Response/Identity packet (except that identity decoration is
not allowed). The AT_IDENTITY attribute contains a permanent
identity, a pseudonym identity, or a fast re-authentication identity.
Please note that only the EAP-AKA peer and the EAP-AKA server process
the AT_IDENTITY attribute and entities that pass through; EAP packets
do not process this attribute. Hence, the authenticator and other
intermediate AAA elements (such as possible AAA proxy servers) will
continue to refer to the peer with the original identity from the
EAP-Response/Identity packet unless the identity authenticated in the
AT_IDENTITY attribute is communicated to them in another way within
the AAA protocol.
4.1.2.2. Relying on EAP-Response/Identity Discouraged
The EAP-Response/Identity packet is not method specific; therefore,
in many implementations it may be handled by an EAP Framework. This
introduces an additional layer of processing between the EAP peer and
EAP server. The extra layer of processing may cache identity
responses or add decorations to the identity. A modification of the
identity response will cause the EAP peer and EAP server to use
different identities in the key derivation, which will cause the
protocol to fail.
For this reason, it is RECOMMENDED that the EAP peer and server use
the method-specific identity attributes in EAP-AKA, and the server is
strongly discouraged from relying upon the EAP-Response/Identity.
In particular, if the EAP server receives a decorated identity in
EAP-Response/Identity, then the EAP server MUST use the
identity-requesting attributes to request the peer to send an
unmodified and undecorated copy of the identity in AT_IDENTITY.
4.1.3. Choice of Identity for the EAP-Response/Identity
If EAP-AKA peer is started upon receiving an EAP-Request/Identity
message, then the peer MAY use an EAP-AKA identity in the EAP-
Response/Identity packet. In this case, the peer performs the
following steps.
If the peer has maintained fast re-authentication state information
and if the peer wants to use fast re-authentication, then the peer
transmits the fast re-authentication identity in
EAP-Response/Identity.
Else, if the peer has a pseudonym username available, then the peer
transmits the pseudonym identity in EAP-Response/Identity.
In other cases, the peer transmits the permanent identity in
EAP-Response/Identity.
4.1.4. Server Operation in the Beginning of EAP-AKA Exchange
As discussed in Section 4.1.2.2, the server SHOULD NOT rely on an
identity string received in EAP-Response/Identity. Therefore, the
RECOMMENDED way to start an EAP-AKA exchange is to ignore any
received identity strings. The server SHOULD begin the EAP-AKA
exchange by issuing the EAP-Request/AKA-Identity packet with an
identity-requesting attribute to indicate that the server wants the
peer to include an identity in the AT_IDENTITY attribute of the EAP-
Response/AKA-Identity message. Three methods to request an identity
from the peer are discussed below.
If the server chooses to not ignore the contents of
EAP-Response/Identity, then the server may already receive an EAP-AKA
identity in this packet. However, if the EAP server has not received
any EAP-AKA peer identity (permanent identity, pseudonym identity, or
fast re-authentication identity) from the peer when sending the first
EAP-AKA request, or if the EAP server has received an
EAP-Response/Identity packet but the contents do not appear to be a
valid permanent identity, pseudonym identity, or a re-authentication
identity, then the server MUST request an identity from the peer
using one of the methods below.
The server sends the EAP-Request/AKA-Identity message with the
AT_PERMANENT_ID_REQ attribute to indicate that the server wants the
peer to include the permanent identity in the AT_IDENTITY attribute
of the EAP-Response/AKA-Identity message. This is done in the
following cases:
o The server does not support fast re-authentication or identity
privacy.
o The server decided to process a received identity, and the server
recognizes the received identity as a pseudonym identity, but the
server is not able to map the pseudonym identity to a permanent
identity.
The server issues the EAP-Request/AKA-Identity packet with the
AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the
peer to include a full authentication identity (pseudonym identity or
permanent identity) in the AT_IDENTITY attribute of the
EAP-Response/AKA-Identity message. This is done in the following
cases:
o The server does not support fast re-authentication and the server
supports identity privacy
o The server decided to process a received identity, and the server
recognizes the received identity as a re-authentication identity
but the server is not able to map the re-authentication identity
to a permanent identity
The server issues the EAP-Request/AKA-Identity packet with the
AT_ANY_ID_REQ attribute to indicate that the server wants the peer to
include an identity in the AT_IDENTITY attribute of the
EAP-Response/AKA-Identity message, and the server does not indicate
any preferred type for the identity. This is done in other cases,
such as when the server ignores a received EAP-Response/Identity,
when the server does not have any identity, or when the server does
not recognize the format of a received identity.
4.1.5. Processing of EAP-Request/AKA-Identity by the Peer
Upon receipt of an EAP-Request/AKA-Identity message, the peer MUST
perform the following steps.
If the EAP-Request/AKA-Identity includes AT_PERMANENT_ID_REQ, and if
the peer does not have a pseudonym available, then the peer MUST
respond with EAP-Response/AKA-Identity and include the permanent
identity in AT_IDENTITY. If the peer has a pseudonym available, then
the peer MAY refuse to send the permanent identity; hence, in this
case the peer MUST either respond with EAP-Response/AKA-Identity and
include the permanent identity in AT_IDENTITY or respond with
EAP-Response/AKA-Client-Error packet with code "unable to process
packet".
If the EAP-Request/AKA-Identity includes AT_FULL_AUTH_ID_REQ, and if
the peer has a pseudonym available, then the peer SHOULD respond with
EAP-Response/AKA-Identity and include the pseudonym identity in
AT_IDENTITY. If the peer does not have a pseudonym when it receives
this message, then the peer MUST respond with EAP-Response/
AKA-Identity and include the permanent identity in AT_IDENTITY. The
Peer MUST NOT use a fast re-authentication identity in the
AT_IDENTITY attribute.
If the EAP-Request/AKA-Identity includes AT_ANY_ID_REQ, and if the
peer has maintained fast re-authentication state information and
wants to use fast re-authentication, then the peer responds with
EAP-Response/AKA-Identity and includes the fast re-authentication
identity in AT_IDENTITY. Else, if the peer has a pseudonym identity
available, then the peer responds with EAP-Response/AKA-Identity and
includes the pseudonym identity in AT_IDENTITY. Else, the peer
responds with EAP-Response/AKA-Identity and includes the permanent
identity in AT_IDENTITY.
An EAP-AKA exchange may include several EAP/AKA-Identity rounds. The
server may issue a second EAP-Request/AKA-Identity, if it was not
able to recognize the identity the peer used in the previous
AT_IDENTITY attribute. At most three EAP/AKA-Identity rounds can be
used, so the peer MUST NOT respond to more than three
EAP-Request/AKA-Identity messages within an EAP exchange. The peer
MUST verify that the sequence of EAP-Request/AKA-Identity packets the
peer receives comply with the sequencing rules defined in this
document. That is, AT_ANY_ID_REQ can only be used in the first
EAP-Request/AKA-Identity; in other words, AT_ANY_ID_REQ MUST NOT be
used in the second or third EAP-Request/AKA-Identity.
AT_FULLAUTH_ID_REQ MUST NOT be used if the previous
EAP-Request/AKA-Identity included AT_PERMANENT_ID_REQ. The peer
operation, in cases when it receives an unexpected attribute or an
unexpected message, is specified in Section 6.3.1.
4.1.6. Attacks against Identity Privacy
The section above specifies two possible ways the peer can operate
upon receipt of AT_PERMANENT_ID_REQ because a received
AT_PERMANENT_ID_REQ does not necessarily originate from the valid
network. However, an active attacker may transmit an
EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute
to the peer, in an effort to find out the true identity of the user.
If the peer does not want to reveal its permanent identity, then the
peer sends the EAP-Response/AKA-Client-Error packet with the error
code "unable to process packet", and the authentication exchange
terminates.
Basically, there are two different policies that the peer can employ
with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes
that the network is able to maintain pseudonyms robustly. Therefore,
if a conservative peer has a pseudonym username, the peer responds
with EAP-Response/AKA-Client-Error to the EAP packet with
AT_PERMANENT_ID_REQ, because the peer believes that the valid network
is able to map the pseudonym identity to the peer’s permanent
identity. (Alternatively, the conservative peer may accept
AT_PERMANENT_ID_REQ in certain circumstances, for example if the
pseudonym was received a long time ago.) The benefit of this policy
is that it protects the peer against active attacks on anonymity. On
the other hand, a "liberal" peer always accepts the
AT_PERMANENT_ID_REQ and responds with the permanent identity. The
benefit of this policy is that it works even if the valid network
sometimes loses pseudonyms and is not able to map them to the
permanent identity.
4.1.7. Processing of AT_IDENTITY by the Server
When the server receives an EAP-Response/AKA-Identity message with
the AT_IDENTITY (in response to the server’s identity requesting
attribute), the server MUST operate as follows.
If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does
not contain a valid permanent identity, then the server sends an
EAP-Request/AKA-Notification packet with AT_NOTIFICATION code
"General failure" (16384) to terminate the EAP exchange. If the
server recognizes the permanent identity and is able to continue,
then the server proceeds with full authentication by sending
EAP-Request/AKA-Challenge.
If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a
valid permanent identity or a pseudonym identity that the server can
map to a valid permanent identity, then the server proceeds with full
authentication by sending EAP-Request/AKA-Challenge. If AT_IDENTITY
contains a pseudonym identity that the server is not able to map to a
valid permanent identity, or an identity that the server is not able
to recognize or classify, then the server sends EAP-Request/
AKA-Identity with AT_PERMANENT_ID_REQ.
If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a
valid permanent identity or a pseudonym identity that the server can
map to a valid permanent identity, then the server proceeds with full
authentication by sending EAP-Request/ AKA-Challenge.
If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
fast re-authentication identity and the server agrees on using
re-authentication, then the server proceeds with fast
re-authentication by sending EAP-Request/AKA-Reauthentication
(Section 5).
If the server used AT_ANY_ID_REQ, and if the peer sent an EAP-
Response/AKA-Identity with AT_IDENTITY that contains an identity that
the server recognizes as a fast re-authentication identity, but the
server is not able to map the identity to a permanent identity, then
the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ.
If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
fast re-authentication identity, which the server is able to map to a
permanent identity, and if the server does not want to use fast
re-authentication, then the server proceeds with full authentication
by sending EAP-Request/AKA-Challenge.
If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
identity that the server recognizes as a pseudonym identity but the
server is not able to map the pseudonym identity to a permanent
identity, then the server sends EAP-Request/AKA-Identity with
AT_PERMANENT_ID_REQ.
If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
identity that the server is not able to recognize or classify, then
the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ.
4.2. Message Sequence Examples (Informative)
This section contains non-normative message sequence examples to
illustrate how the peer identity can be communicated to the server.
4.2.1. Usage of AT_ANY_ID_REQ
Obtaining the peer identity with EAP-AKA attributes is illustrated in
Figure 5 below.
Peer Authenticator
| |
| +------------------------------+
| | Server does not have any |
| | Subscriber identity available|
| | When starting EAP-AKA |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_ANY_ID_REQ) |
|<------------------------------------------------------|
| |
| EAP-Response/AKA-Identity |
| (AT_IDENTITY) |
|------------------------------------------------------>|
| |
Figure 5: Usage of AT_ANY_ID_REQ
4.2.2. Fall Back on Full Authentication
Figure 6 illustrates the case when the server does not recognize the
fast re-authentication identity the peer used in AT_IDENTITY.
Peer Authenticator
| |
| +------------------------------+
| | Server does not have any |
| | Subscriber identity available|
| | When starting EAP-AKA |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_ANY_ID_REQ) |
|<------------------------------------------------------|
| |
| EAP-Response/AKA-Identity |
| (AT_IDENTITY containing a fast re-auth. identity) |
|------------------------------------------------------>|
| +------------------------------+
| | Server does not recognize |
| | The fast re-auth. |
| | Identity |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_FULLAUTH_ID_REQ) |
|<------------------------------------------------------|
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with a full-auth. Identity) |
|------------------------------------------------------>|
| |
Figure 6: Fall back on full authentication
If the server recognizes the fast re-authentication identity, but
still wants to fall back on full authentication, the server may issue
the EAP-Request/AKA-Challenge packet. In this case, the full
authentication procedure proceeds as usual.
4.2.3. Requesting the Permanent Identity 1
Figure 7 illustrates the case when the EAP server fails to decode a
pseudonym identity included in the EAP-Response/Identity packet.
Peer Authenticator
| EAP-Request/Identity |
|<------------------------------------------------------|
| EAP-Response/Identity |
| (Includes a pseudonym) |
|------------------------------------------------------>|
| +------------------------------+
| | Server fails to decode the |
| | Pseudonym. |
| +------------------------------+
| EAP-Request/AKA-Identity |