implemented by the peer and allowed in the peer’s security policy,
then the peer MUST send the EAP-Response/SIM/Client-Error packet
(Section 9.7) to the server with the error code "unsupported
version". If a suitable version is included, then the peer includes
the AT_SELECTED_VERSION attribute, containing the selected version in
the EAP-Response/SIM/Start packet. The peer MUST only indicate a
version that is included in the AT_VERSION_LIST. If several versions
are acceptable, then the peer SHOULD choose the version that occurs
first in the version list.
The version number list of AT_VERSION_LIST and the selected version
of AT_SELECTED_VERSION are included in the key derivation procedure
(Section 7). If an attacker modifies either one of these attributes,
then the peer and the server derive different keying material.
Because K_aut keys are different, the server and peer calculate
different AT_MAC values. Hence, the peer detects that AT_MAC,
included in EAP-Request/SIM/Challenge, is incorrect and sends the
EAP-Response/SIM/Client-Error packet. The authentication procedure
terminates.
4.2. Identity Management
4.2.1. Format, Generation and Usage of Peer Identities
4.2.1.1. General
In the beginning of EAP authentication, the Authenticator or the EAP
server usually issues the EAP-Request/Identity packet to the peer.
The peer responds with the EAP-Response/Identity, which contains the
user’s identity. The formats of these packets are specified in
[RFC3748].
GSM subscribers are identified with the International Mobile
Subscriber Identity (IMSI) [GSM-03.03]. The IMSI is a string of not
more than 15 digits. It is composed of a three digit Mobile Country
Code (MCC), a two or three digit Mobile Network Code (MNC), and a
Mobile Subscriber Identification Number (MSIN) of no more than 10
digits. MCC and MNC uniquely identify the GSM operator and help
identify the AuC from which the authentication vectors need to be
retrieved for this subscriber.
Internet AAA protocols identify users with the Network Access
Identifier (NAI) [RFC4282]. When used in a roaming environment, the
NAI is composed of a username and a realm, separated with "@"
(username@realm). The username portion identifies the subscriber
within the realm.
This section specifies the peer identity format used in EAP-SIM. In
this document, the term "identity" or "peer identity" refers to the
whole identity string that is used to identify the peer. The peer
identity may include a realm portion. "Username" refers to the
portion of the peer identity that identifies the user, i.e., the
username does not include the realm portion.
4.2.1.2. Identity Privacy Support
EAP-SIM includes optional identity privacy (anonymity) support that
can be used to hide the cleartext permanent identity and thereby make
the subscriber’s EAP exchanges untraceable to eavesdroppers. Because
the permanent identity never changes, revealing it would help
observers to track the user. The permanent identity is usually based
on the IMSI, which may further help the tracking, because the same
identifier may be used in other contexts as well. Identity privacy
is based on temporary identities, or pseudonyms, which are equivalent
to but separate from the Temporary Mobile Subscriber Identities
(TMSI) that are used on cellular networks. Please see Section 12.2
for security considerations regarding identity privacy.
4.2.1.3. Username Types in EAP-SIM identities
There are three types of usernames in EAP-SIM peer identities:
(1) Permanent usernames. For example,
1123456789098765@myoperator.com might be a valid permanent identity.
In this example, 1123456789098765 is the permanent username.
(2) Pseudonym usernames. For example, 3s7ah6n9q@myoperator.com might
be a valid pseudonym identity. In this example, 3s7ah6n9q is the
pseudonym username.
(3) Fast re-authentication usernames. For example,
53953754@myoperator.com might be a valid fast re-authentication
identity. In this case, 53953754 is the fast re-authentication
username. Unlike permanent usernames and pseudonym usernames, fast
re-authentication usernames are one-time identifiers, which are not
re-used across EAP exchanges.
The first two types of identities are used only on full
authentication and the last one only on fast re-authentication. When
the optional identity privacy support is not used, the non-pseudonym
permanent identity is used on full authentication. The fast
re-authentication exchange is specified in Section 5.
4.2.1.4. Username Decoration
In some environments, the peer may need to decorate the identity by
prepending or appending the username with a string, in order to
indicate supplementary AAA routing information in addition to the NAI
realm. (The usage of an NAI realm portion is not considered
decoration.) Username decoration is out of the scope of this
document. However, it should be noted that username decoration might
prevent the server from recognizing a valid username. Hence,
although the peer MAY use username decoration in the identities that
the peer includes in EAP-Response/Identity, and although the EAP
server MAY accept a decorated peer username in this message, the peer
or the EAP server MUST NOT decorate any other peer identities that
are used in various EAP-SIM attributes. Only the identity used in
the EAP-Response/Identity may be decorated.
4.2.1.5. NAI Realm Portion
The peer MAY include a realm portion in the peer identity, as per the
NAI format. The use of a realm portion is not mandatory.
If a realm is used, the realm MAY be chosen by the subscriber’s home
operator and it MAY be a configurable parameter in the EAP-SIM peer
implementation. In this case, the peer is typically configured with
the NAI realm of the home operator. Operators MAY reserve a specific
realm name for EAP-SIM users. This convention makes it easy to
recognize that the NAI identifies a GSM subscriber. Such a reserved
NAI realm may be a useful hint as to the first authentication method
to use during method negotiation. When the peer is using a pseudonym
username instead of the permanent username, the peer selects the
realm name portion similarly as it select the realm portion when
using the permanent username.
If no configured realm name is available, the peer MAY derive the
realm name from the MCC and MNC portions of the IMSI. A RECOMMENDED
way to derive the realm from the IMSI using the realm 3gppnetwork.org
is specified in [3GPP-TS-23.003].
Some old implementations derive the realm name from the IMSI by
concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits
of IMSI, and ".owlan.org". For example, if the IMSI is
123456789098765, and the MNC is three digits long, then the derived
realm name is "mnc456.mcc123.owlan.org". As there are no DNS servers
running at owlan.org, these realm names can only be used with
manually configured AAA routing. New implementations SHOULD use the
mechanism specified in [3GPP-TS-23.003] instead of owlan.org.
The IMSI is a string of digits without any explicit structure, so the
peer may not be able to determine the length of the MNC portion. If
the peer is not able to determine whether the MNC is two or three
digits long, the peer MAY use a 3-digit MNC. If the correct length
of the MNC is two, then the MNC used in the realm name includes the
first digit of the MSIN. Hence, when configuring AAA networks for
operators that have 2-digit MNCs, the network SHOULD also be prepared
for realm names with incorrect, 3-digit MNCs.
4.2.1.6. Format of the Permanent Username
The non-pseudonym permanent username SHOULD be derived from the IMSI.
In this case, the permanent username MUST be of the format "1" |
IMSI, where the character "|" denotes concatenation. In other words,
the first character of the username is the digit one (ASCII value 31
hexadecimal), followed by the IMSI. The IMSI is encoded as an ASCII
string that consists of not more than 15 decimal digits (ASCII values
between 30 and 39 hexadecimal), one character per IMSI digit, in the
order specified in [GSM-03.03]. For example, a permanent username
derived from the IMSI 295023820005424 would be encoded as the ASCII
string "1295023820005424" (byte values in hexadecimal notation: 31 32
39 35 30 32 33 38 32 30 30 30 35 34 32 34).
The EAP server MAY use the leading "1" as a hint to try EAP-SIM as
the first authentication method during method negotiation, rather
than, for example EAP/AKA. The EAP-SIM server MAY propose EAP-SIM,
even if the leading character was not "1".
Alternatively, an implementation MAY choose a permanent username that
is not based on the IMSI. In this case, the selection of the
username, its format, and its processing is out of the scope of this
document. In this case, the peer implementation MUST NOT prepend any
leading characters to the username.
4.2.1.7. Generating Pseudonyms and Fast Re-authentication Identities by
the Server
Pseudonym usernames and fast re-authentication identities are
generated by the EAP server. The EAP server produces pseudonym
usernames and fast re-authentication identities in an
implementation-dependent manner. Only the EAP server needs to be
able to map the pseudonym username to the permanent identity, or to
recognize a fast re-authentication identity.
EAP-SIM includes no provisions to ensure that the same EAP server
that generated a pseudonym username will be used on the
authentication exchange when the pseudonym username is used. It is
recommended that the EAP servers implement some centralized mechanism
to allow all EAP servers of the home operator to map pseudonyms
generated by other severs to the permanent identity. If no such
mechanism is available, then the EAP server failing to understand a
pseudonym issued by another server can request the that peer send the
permanent identity.
When issuing a fast re-authentication identity, the EAP server may
include a realm name in the identity to make the fast
re-authentication request be forwarded to the same EAP server.
When generating fast re-authentication identities, the server SHOULD
choose a fresh, new fast re-authentication identity that is different
from the previous ones that were used after the same full
authentication exchange. A full authentication exchange and the
associated fast re-authentication exchanges are referred to here as
the same "full authentication context". The fast re-authentication
identity SHOULD include a random component. This random component
works as a full authentication context identifier. A
context-specific fast re-authentication identity can help the server
to detect whether its fast re-authentication state information
matches that of its peer (in other words, whether the state
information is from the same full authentication exchange). The
random component also makes the fast re-authentication identities
unpredictable, so an attacker cannot initiate a fast
re-authentication exchange to get the server’s EAP-Request/SIM/
Re-authentication packet.
Transmitting pseudonyms and fast re-authentication identities from
the server to the peer is discussed in Section 4.2.1.8. The
pseudonym is transmitted as a username, without an NAI realm, and the
fast re-authentication identity is transmitted as a complete NAI,
including a realm portion if a realm is required. The realm is
included in the fast re-authentication identity to allow the server
to include a server-specific realm.
Regardless of the construction method, the pseudonym username MUST
conform to the grammar specified for the username portion of an NAI.
The fast re-authentication identity also MUST conform to the NAI
grammar. The EAP servers that the subscribers of an operator can use
MUST ensure that the pseudonym usernames and the username portions
used in fast re-authentication identities they generate are unique.
In any case, it is necessary that permanent usernames, pseudonym
usernames, and fast re-authentication usernames are separate and
recognizable from each other. It is also desirable that EAP-SIM and
EAP-AKA [EAP-AKA] usernames be distinguishable from each other as an
aid for the server on which method to offer.
In general, it is the task of the EAP server and the policies of its
administrator to ensure sufficient separation of the usernames.
Pseudonym usernames and fast re-authentication usernames are both
produced and used by the EAP server. The EAP server MUST compose
pseudonym usernames and fast re-authentication usernames so that it
can determine if an NAI username is an EAP-SIM pseudonym username or
an EAP-SIM fast re-authentication username. For instance, when the
usernames have been derived from the IMSI, the server could use
different leading characters in the pseudonym usernames and fast
re-authentication usernames (e.g., the pseudonym could begin with a
leading "3" character). When mapping a fast re-authentication
identity to a permanent identity, the server SHOULD only examine the
username portion of the fast re-authentication identity and ignore
the realm portion of the identity.
Because the peer may fail to save a pseudonym username sent in an
EAP-Request/SIM/Challenge, for example due to malfunction, the EAP
server SHOULD maintain at least the most recently used pseudonym
username in addition to the most recently issued pseudonym username.
If the authentication exchange is not completed successfully, then
the server SHOULD NOT overwrite the pseudonym username that was
issued during the most recent successful authentication exchange.
4.2.1.8. Transmitting Pseudonyms and Fast Re-authentication Identities
to the Peer
The server transmits pseudonym usernames and fast re-authentication
identities to the peer in cipher, using the AT_ENCR_DATA attribute.
The EAP-Request/SIM/Challenge message MAY include an encrypted
pseudonym username and/or an encrypted fast re-authentication
identity in the value field of the AT_ENCR_DATA attribute. Because
identity privacy support and fast re-authentication are optional
implementations, the peer MAY ignore the AT_ENCR_DATA attribute and
always 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/SIM/Re-authentication message.
On receipt of the EAP-Request/SIM/Challenge, the peer MAY decrypt the
encrypted data in AT_ENCR_DATA. If the authentication exchange is
successful, and the encrypted data includes a pseudonym username,
then 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 authentication exchange does
not complete successfully, the peer MUST ignore the received
pseudonym username and the fast re-authentication identity.
If the peer does not receive a new pseudonym username in the
EAP-Request/SIM/Challenge message, the peer MAY use an old pseudonym
username instead of the permanent username on the 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.2.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.2.1.10. Usage of the Fast Re-authentication Identity by the Peer
On fast re-authentication, the peer uses the fast re-authentication
identity that was received as part of the previous authentication
sequence. A new 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.2.2. Communicating the Peer Identity to the Server
4.2.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, and if the
server agrees to use fast re-authentication, 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-SIM messages instead of the 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/SIM/Start message, and the peer includes the AT_IDENTITY
attribute, which contains the peer’s identity, in the
EAP-Response/SIM/Start 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 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 the EAP-SIM peer and the EAP-SIM server only process
the AT_IDENTITY attribute; entities that only 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.2.2.2. Relying on EAP-Response/Identity Discouraged
The EAP-Response/Identity packet is not method-specific, so 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-SIM, 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 that the peer send an
unmodified and undecorated copy of the identity in AT_IDENTITY.
4.2.3. Choice of Identity for the EAP-Response/Identity
If EAP-SIM peer is started upon receiving an EAP-Request/Identity
message, then the peer MAY use an EAP-SIM 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 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.2.4. Server Operation in the Beginning of EAP-SIM Exchange
As discussed in Section 4.2.2.2, the server SHOULD NOT rely on an
identity string received in EAP-Response/Identity. Therefore, the
RECOMMENDED way to start an EAP-SIM exchange is to ignore any
received identity strings. The server SHOULD begin the EAP-SIM
exchange by issuing the EAP-Request/SIM/Start 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/SIM/Start message. Three methods to request an identity
from the peer are discussed below.
If the server chooses not to ignore the contents of EAP-
Response/Identity, then the server may have already received an EAP-
SIM identity in this packet. However, if the EAP server has not
received any EAP-SIM peer identity (permanent identity, pseudonym
identity, or fast re-authentication identity) from the peer when
sending the first EAP-SIM 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/SIM/Start 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/SIM/Start 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/SIM/Start 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/SIM/Start 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/SIM/Start 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/SIM/Start 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, the
server does not have any identity, or the server does not recognize
the format of a received identity.
4.2.5. Processing of EAP-Request/SIM/Start by the Peer
Upon receipt of an EAP-Request/SIM/Start message, the peer MUST
perform the following steps.
If the EAP-Request/SIM/Start does not include an identity request
attribute, then the peer responds with EAP-Response/SIM/Start without
AT_IDENTITY. The peer includes the AT_SELECTED_VERSION and
AT_NONCE_MT attributes, because the exchange is a full authentication
exchange.
If the EAP-Request/SIM/Start includes AT_PERMANENT_ID_REQ, and if the
peer does not have a pseudonym available, then the peer MUST respond
with EAP-Response/SIM/Start 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/SIM/Start and include the
permanent identity in AT_IDENTITY or respond with EAP-Response/SIM/