Client-Error packet with the code "unable to process packet".
If the EAP-Request/SIM/Start includes AT_FULL_AUTH_ID_REQ, and if the
peer has a pseudonym available, then the peer SHOULD respond with
EAP-Response/SIM/Start 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/SIM/Start
and include the permanent identity in AT_IDENTITY. The Peer MUST NOT
use a re-authentication identity in the AT_IDENTITY attribute.
If the EAP-Request/SIM/Start includes AT_ANY_ID_REQ, and if the peer
has maintained fast re-authentication state information and the peer
wants to use fast re-authentication, then the peer responds with
EAP-Response/SIM/Start 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/SIM/Start and
includes the pseudonym identity in AT_IDENTITY. Else, the peer
responds with EAP-Response/SIM/Start and includes the permanent
identity in AT_IDENTITY.
An EAP-SIM exchange may include several EAP/SIM/Start rounds. The
server may issue a second EAP-Request/SIM/Start if it was not able to
recognize the identity that the peer used in the previous AT_IDENTITY
attribute. At most, three EAP/SIM/Start rounds can be used, so the
peer MUST NOT respond to more than three EAP-Request/SIM/Start
messages within an EAP exchange. The peer MUST verify that the
sequence of EAP-Request/SIM/Start packets that 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/SIM/Start; in
other words, AT_ANY_ID_REQ MUST NOT be used in the second or third
EAP-Request/SIM/Start. AT_FULLAUTH_ID_REQ MUST NOT be used if the
previous EAP-Request/SIM/Start 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.2.6. Attacks Against Identity Privacy
The section above specifies two possible ways the peer can operate
upon receipt of AT_PERMANENT_ID_REQ. This is because a received
AT_PERMANENT_ID_REQ does not necessarily originate from the valid
network, but an active attacker may transmit an EAP-Request/SIM/
Start 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/SIM/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/SIM/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.2.7. Processing of AT_IDENTITY by the Server
When the server receives an EAP-Response/SIM/Start 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
EAP-Request/SIM/Notification with AT_NOTIFICATION code "General
failure" (16384), and the EAP exchange terminates. If the server
recognizes the permanent identity and is able to continue, then the
server proceeds with full authentication by sending EAP-Request/SIM/
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/SIM/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/SIM/Start
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/SIM/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/SIM/Re-authentication
(Section 5).
If the server used AT_ANY_ID_REQ, and if the peer sent an
EAP-Response/SIM/Start with only AT_IDENTITY (indicating
re-authentication), but the server is not able to map the identity to
a permanent identity, then the server sends EAP-Request/SIM/Start
with AT_FULLAUTH_ID_REQ.
If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
fast re-authentication identity that 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 sends EAP-Request/SIM/Start
without any identity requesting attributes.
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/SIM/Start 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/SIM/Start with AT_FULLAUTH_ID_REQ.
4.3. 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.3.1. Full Authentication
This case for full authentication is illustrated below in Figure 2.
In this case, AT_IDENTITY contains either the permanent identity or a
pseudonym identity. The same sequence is also used in case the
server uses the AT_FULLAUTH_ID_REQ in EAP-Request/SIM/Start.
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
Figure 2: Requesting any identity, full authentication
If the peer uses its full authentication identity and the AT_IDENTITY
attribute contains a valid permanent identity or a valid pseudonym
identity that the EAP server is able to map to the permanent
identity, then the full authentication sequence proceeds as usual
with the EAP Server issuing the EAP-Request/SIM/Challenge message.
4.3.2. Fast Re-authentication
The case when the server uses the AT_ANY_ID_REQ and the peer wants to
perform fast re-authentication is illustrated below in Figure 3.
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY containing a fast re-auth. identity) |
|------------------------------------------------------>|
| |
Figure 3: Requesting any identity, fast re-authentication
On fast re-authentication, if the AT_IDENTITY attribute contains a
valid fast re-authentication identity and the server agrees on using
fast re-authentication, then the server proceeds with the fast
re-authentication sequence and issues the EAP-Request/SIM/
Re-authentication packet, as specified in Section 5.
4.3.3. Fall Back to Full Authentication
Figure 4 illustrates cases in which the server does not recognize the
fast re-authentication identity the peer used in AT_IDENTITY, and
issues a second EAP-Request/SIM/Start message.
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY containing a fast re-auth. identity) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server does not recognize |
| | The fast re-auth. |
| | Identity |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with a full-auth. identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
Figure 4: Fall back to full authentication
4.3.4. Requesting the Permanent Identity 1
Figure 5 illustrates the case in which the EAP server fails to map
the pseudonym identity included in the EAP-Response/Identity packet
to a valid permanent identity.
Peer Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a pseudonym) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server fails to map the |
| | Pseudonym to a permanent id. |
| +------------------------------+
| EAP-Request/SIM/Start |
| (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with permanent identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
Figure 5: Requesting the permanent identity
If the server recognizes the permanent identity, then the
authentication sequence proceeds as usual with the EAP Server issuing
the EAP-Request/SIM/Challenge message.
4.3.5. Requesting the Permanent Identity 2
Figure 6 illustrates the case in which the EAP server fails to map
the pseudonym included in the AT_IDENTITY attribute to a valid
permanent identity.
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
|EAP-Response/SIM/Start |
|(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| +-------------------------------+
| | Server fails to map the |
| | Pseudonym in AT_IDENTITY |
| | to a valid permanent identity |
| +-------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with permanent identity, |
| AT_NONCE_MT, AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
Figure 6: Requesting a permanent identity (two EAP-SIM Start rounds)
4.3.6. Three EAP-SIM/Start Roundtrips
In the worst case, there are three EAP/SIM/Start round trips before