| (AT_PERMANENT_ID_REQ) |
|<------------------------------------------------------|
| |
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with permanent identity) |
|------------------------------------------------------>|
| |
Figure 7: Requesting the permanent identity 1
If the server recognizes the permanent identity, then the
authentication sequence proceeds as usual with the EAP Server issuing
the EAP-Request/AKA-Challenge message.
4.2.4. Requesting the Permanent Identity 2
Figure 8 illustrates the case when the EAP server fails to decode the
pseudonym included in the AT_IDENTITY attribute.
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 with a pseudonym identity) |
|------------------------------------------------------>|
| +------------------------------+
| | Server fails to decode the |
| | Pseudonym in AT_IDENTITY |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_PERMANENT_ID_REQ) |
|<------------------------------------------------------|
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with permanent identity) |
|------------------------------------------------------>|
| |
Figure 8: Requesting the permanent identity 2
4.2.5. Three EAP/AKA-Identity Round Trips
Figure 9 illustrates the case with three EAP/AKA-Identity round
trips.
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 with fast re-auth. identity) |
|------------------------------------------------------>|
| +------------------------------+
| | Server does not accept |
| | The fast re-authentication |
| | Identity |
| +------------------------------+
| |
: :
: :
: :
: :
| EAP-Request/AKA-Identity |
| (AT_FULLAUTH_ID_REQ) |
|<------------------------------------------------------|
|EAP-Response/AKA-Identity |
|(AT_IDENTITY with a pseudonym identity) |
|------------------------------------------------------>|
| +------------------------------+
| | Server fails to decode the |
| | Pseudonym in AT_IDENTITY |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_PERMANENT_ID_REQ) |
|<------------------------------------------------------|
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with permanent identity) |
|------------------------------------------------------>|
| |
Figure 9: Three EAP-AKA Start rounds
After the last EAP-Response/AKA-Identity message, the full
authentication sequence proceeds as usual.
5. Fast Re-Authentication
5.1. General
In some environments, EAP authentication may be performed frequently.
Because the EAP-AKA full authentication procedure uses the AKA
algorithms, and therefore requires fresh authentication vectors from
the Authentication Centre, the full authentication procedure may
result in many network operations when used very frequently.
Therefore, EAP-AKA includes a more inexpensive fast re-authentication
procedure that does not make use of the AKA algorithms and does not
need new vectors from the Authentication Centre.
Fast re-authentication is optional to implement for both the EAP-AKA
server and peer. On each EAP authentication, either one of the
entities may fall back on full authentication if is 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 used in full
authentication are used to protect EAP-AKA 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 fast re-authentications. For example, on the second
fast re-authentication, counter value is two or greater, etc. 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
and 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 AKA
When analyzing the fast re-authentication exchange, it may be helpful
to compare it with the 3rd generation Authentication and Key
Agreement (AKA) exchange used on full authentication. The counter
corresponds to the AKA sequence number, NONCE_S corresponds to RAND,
the AT_MAC in EAP-Request/AKA-Reauthentication corresponds to AUTN,
the AT_MAC in EAP-Response/AKA-Reauthentication 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 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 fast
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/-
AKA-Challenge message. This attribute contains a new
re-authentication identity for the next fast re-authentication. The
attribute also works as a capability flag that indicates 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 will use full
authentication next time. If the peer wants to use fast
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 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/AKA-Challenge or EAP-Request/AKA-Reauthentication, 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/
AKA-Identity 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. If the server was able
to decode the fast re-authentication identity to the permanent
identity, the server issues the EAP-Request/AKA-Challenge packet to
initiate full authentication. If the server was not able to recover
the peer’s identity from the fast re-authentication identity, the
server starts the full authentication procedure by issuing an
EAP-Request/AKA-Identity packet. This packet always starts a full
authentication sequence if it does not include the AT_ANY_ID_REQ
attribute.
5.4. Fast Re-Authentication Procedure
Figure 10 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 fast
re-authentication identity in the EAP-Response/Identity packet. As
discussed above, an alternative way to communicate the fast
re-authentication identity to the server is for the peer to use the
AT_IDENTITY attribute in the EAP-Response/AKA-Identity 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/AKA-Identity
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/AKA-
Reauthentication 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/AKA-Reauthentication packet,
including the AT_COUNTER attribute with the same counter value and
the 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/AKA-Reauthentication packet. If these checks are
successful, the fast 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-AKA notification
round.
Peer Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a fast re-authentication identity) |
|------------------------------------------------------>|
| +--------------------------------+
| | Server recognizes the identity |
| | and agrees on using fast |
| | re-authentication |
| +--------------------------------+
| EAP-Request/AKA-Reauthentication |
| (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 re- | |
| authentication identity for next re-auth. | |
+-----------------------------------------------+ |
| |
| EAP-Response/AKA-Reauthentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, |