the server obtains an acceptable identity. This case is illustrated
in Figure 7.
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| EAP-Request/SIM/Start |
| (Includes AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with fast re-auth. identity) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server does not accept |
| | The fast re-auth. |
| | Identity |
| +------------------------------+
| EAP-Request/SIM/Start |
| (AT_FULLAUTH_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 7: Three EAP-SIM Start rounds
After the last EAP-Response/SIM/Start message, the full
authentication sequence proceeds as usual. If the EAP Server
recognizes the permanent identity and is able to proceed, the server
issues the EAP-Request/SIM/Challenge message.
5. Fast Re-Authentication
5.1. General
In some environments, EAP authentication may be performed frequently.
Because the EAP-SIM full authentication procedure makes use of the
GSM SIM A3/A8 algorithms, and therefore requires 2 or 3 fresh
triplets from the Authentication Centre, the full authentication
procedure is not very well suited for frequent use. Therefore,
EAP-SIM includes a more inexpensive fast re-authentication procedure
that does not make use of the SIM A3/A8 algorithms and does not need
new triplets from the Authentication Centre. Re-authentication can
be performed in fewer roundtrips than the full authentication.
Fast re-authentication is optional to implement for both the EAP-SIM
server and peer. On each EAP authentication, either one of the
entities may also fall back on full authentication if it does not
want to use fast re-authentication.
Fast re-authentication is based on the keys derived on the preceding
full authentication. The same K_aut and K_encr keys that were used
in full authentication are used to protect EAP-SIM packets and
attributes, and the original Master Key from full authentication is
used to generate a fresh Master Session Key, as specified in Section
7.
The fast re-authentication exchange makes use of an unsigned 16-bit
counter, included in the AT_COUNTER attribute. The counter has three
goals: 1) it can be used to limit the number of successive
reauthentication exchanges without full authentication 2) it
contributes to the keying material, and 3) it protects the peer and
the server from replays. On full authentication, both the server and
the peer initialize the counter to one. The counter value of at
least one is used on the first fast re-authentication. On subsequent
fast re-authentications, the counter MUST be greater than on any of
the previous re-authentications. For example, on the second fast
re-authentication, the counter value is two or greater. The
AT_COUNTER attribute is encrypted.
Both the peer and the EAP server maintain a copy of the counter. The
EAP server sends its counter value to the peer in the fast
re-authentication request. The peer MUST verify that its counter
value is less than or equal to the value sent by the EAP server.
The server includes an encrypted server random nonce (AT_NONCE_S) in
the fast re-authentication request. The AT_MAC attribute in the
peer’s response is calculated over NONCE_S to provide a
challenge/response authentication scheme. The NONCE_S also
contributes to the new Master Session Key.
Both the peer and the server SHOULD have an upper limit for the
number of subsequent fast re-authentications allowed before a full
authentication needs to be performed. Because a 16-bit counter is
used in fast re-authentication, the theoretical maximum number of
re-authentications is reached when the counter value reaches FFFF
hexadecimal.
In order to use fast re-authentication, the peer and the EAP server
need to store the following values: Master Key, latest counter value
and the next fast re-authentication identity. K_aut, K_encr may
either be stored or derived again from MK. The server may also need
to store the permanent identity of the user.
5.2. Comparison to UMTS AKA
When analyzing the fast re-authentication exchange, it may be helpful
to compare it with the UMTS Authentication and Key Agreement (AKA)
exchange, which it resembles closely. The counter corresponds to the
UMTS AKA sequence number, NONCE_S corresponds to RAND, AT_MAC in
EAP-Request/SIM/Re-authentication corresponds to AUTN, the AT_MAC in
EAP-Response/SIM/Re-authentication corresponds to RES,
AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter
corresponds to the usage of the Anonymity Key. Also, the key
generation on fast re-authentication, with regard to random or fresh
material, is similar to UMTS AKA -- the server generates the NONCE_S
and counter values, and the peer only verifies that the counter value
is fresh.
It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER,
or AT_COUNTER_TOO_SMALL attributes is not important to the security
of the fast re-authentication exchange.
5.3. Fast Re-authentication Identity
The fast re-authentication procedure makes use of separate
re-authentication user identities. Pseudonyms and the permanent
identity are reserved for full authentication only. If a
re-authentication identity is lost and the network does not recognize
it, the EAP server can fall back on full authentication.
If the EAP server supports fast re-authentication, it MAY include the
skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of
EAP-Request/SIM/Challenge message (Section 9.3). This attribute
contains a new fast re-authentication identity for the next fast
re-authentication. The attribute also works as a capability flag
that, indicating that the server supports fast re-authentication, and
that the server wants to continue using fast re-authentication within
the current context. The peer MAY ignore this attribute, in which
case it MUST use full authentication next time. If the peer wants to
use re-authentication, it uses this fast re-authentication identity
on next authentication. Even if the peer has a fast
re-authentication identity, the peer MAY discard the fast
re-authentication identity and use a pseudonym or the permanent
identity instead, in which case full authentication MUST be
performed. If the EAP server does not include the AT_NEXT_REAUTH_ID
in the encrypted data of EAP-Request/SIM/Challenge or
EAP-Request/SIM/ Re-authentication, then the peer MUST discard its
current fast re-authentication state information and perform a full
authentication next time.
In environments where a realm portion is needed in the peer identity,
the fast re-authentication identity received in AT_NEXT_REAUTH_ID
MUST contain both a username portion and a realm portion, as per the
NAI format. The EAP Server can choose an appropriate realm part in
order to have the AAA infrastructure route subsequent fast
re-authentication related requests to the same AAA server. For
example, the realm part MAY include a portion that is specific to the
AAA server. Hence, it is sufficient to store the context required
for fast re-authentication in the AAA server that performed the full
authentication.
The peer MAY use the fast re-authentication identity in the
EAP-Response/Identity packet or, in response to the server’s
AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication
identity in the AT_IDENTITY attribute of the EAP-Response/SIM/Start
packet.
The peer MUST NOT modify the username portion of the fast
re-authentication identity, but the peer MAY modify the realm portion
or replace it with another realm portion. The peer might need to
modify the realm in order to influence the AAA routing, for example,
to make sure that the correct server is reached. It should be noted
that sharing the same fast re-authentication key among several
servers may have security risks, so changing the realm portion of the
NAI in order to change the EAP server is not desirable.
Even if the peer uses a fast re-authentication identity, the server
may want to fall back on full authentication, for example because the
server does not recognize the fast re-authentication identity or does
not want to use fast re-authentication. In this case, the server
starts the full authentication procedure by issuing an
EAP-Request/SIM/Start packet. This packet always starts a full
authentication sequence if it does not include the AT_ANY_ID_REQ
attribute. If the server was not able to recover the peer’s identity
from the fast re-authentication identity, the server includes either
the AT_FULLAUTH_ID_REQ or the AT_PERMANENT_ID_REQ attribute in this
EAP request.
5.4. Fast Re-authentication Procedure
Figure 8 illustrates the fast re-authentication procedure. In this
example, the optional protected success indication is not used.
Encrypted attributes are denoted with ’*’. The peer uses its
re-authentication identity in the EAP-Response/Identity packet. As
discussed above, an alternative way to communicate the
re-authentication identity to the server is for the peer to use the
AT_IDENTITY attribute in the EAP-Response/SIM/Start message. This
latter case is not illustrated in the figure below, and it is only
possible when the server requests that the peer send its identity by
including the AT_ANY_ID_REQ attribute in the EAP-Request/SIM/Start
packet.
If the server recognizes the identity as a valid fast
re-authentication identity, and if the server agrees to use fast
re-authentication, then the server sends the EAP-Request/SIM/
Re-authentication packet to the peer. This packet MUST include the
encrypted AT_COUNTER attribute, with a fresh counter value, the
encrypted AT_NONCE_S attribute that contains a random number chosen
by the server, the AT_ENCR_DATA and the AT_IV attributes used for
encryption, and the AT_MAC attribute that contains a message
authentication code over the packet. The packet MAY also include an
encrypted AT_NEXT_REAUTH_ID attribute that contains the next fast
re-authentication identity.
Fast re-authentication identities are one-time identities. If the
peer does not receive a new fast re-authentication identity, it MUST
use either the permanent identity or a pseudonym identity on the next
authentication to initiate full authentication.
The peer verifies that AT_MAC is correct, and that the counter value
is fresh (greater than any previously used value). The peer MAY save
the next fast re-authentication identity from the encrypted
AT_NEXT_REAUTH_ID for next time. If all checks are successful, the
peer responds with the EAP-Response/SIM/Re-authentication packet,
including the AT_COUNTER attribute with the same counter value and
AT_MAC attribute.
The server verifies the AT_MAC attribute and also verifies that the
counter value is the same that it used in the EAP-Request/SIM/
Re-authentication packet. If these checks are successful, the
re-authentication has succeeded and the server sends the EAP-Success
packet to the peer.
If protected success indications (Section 6.2) were used, the
EAP-Success packet would be preceded by an EAP-SIM notification
round.
Peer Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a fast re-authentication identity) |
|------------------------------------------------------>|
| |
| +--------------------------------+
| | Server recognizes the identity |
| | and agrees to use fast |
| | re-authentication |
| +--------------------------------+
| |
: :
: :
: :
: :
| EAP-Request/SIM/Re-authentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
| *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
|<------------------------------------------------------|
| |
+-----------------------------------------------+ |
| Peer verifies AT_MAC and the freshness of | |
| the counter. Peer MAY store the new fast re- | |
| authentication identity for next re-auth. | |
+-----------------------------------------------+ |
| |
| EAP-Response/SIM/Re-authentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, |
| AT_MAC) |
|------------------------------------------------------>|
| +--------------------------------+
| | Server verifies AT_MAC and |
| | the counter |
| +--------------------------------+
| |
| EAP-Success |
|<------------------------------------------------------|
| |
Figure 8: Fast Re-authentication
5.5. Fast Re-authentication Procedure when Counter Is Too Small
If the peer does not accept the counter value of EAP-Request/SIM/
Re-authentication, it indicates the counter synchronization problem
by including the encrypted AT_COUNTER_TOO_SMALL in EAP-Response/SIM/
Re-authentication. The server responds with EAP-Request/SIM/Start to
initiate a normal full authentication procedure. This is illustrated
in Figure 9. Encrypted attributes are denoted with ’*’.
Peer Authenticator
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY) |
| (Includes a fast re-authentication identity) |
|------------------------------------------------------>|
| |
| EAP-Request/SIM/Re-authentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
| *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
|<------------------------------------------------------|
+-----------------------------------------------+ |
| AT_MAC is valid but the counter is not fresh. | |