+-----------------------------------------------+ |
| |
| EAP-Response/SIM/Re-authentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, |
| *AT_COUNTER, AT_MAC) |
|------------------------------------------------------>|
| +----------------------------------------------+
| | Server verifies AT_MAC but detects |
| | That peer has included AT_COUNTER_TOO_SMALL |
| +----------------------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_VERSION_LIST) |
|<------------------------------------------------------|
+---------------------------------------------------------------+
| Normal full authentication follows. |
+---------------------------------------------------------------+
| |
Figure 9: Fast Re-authentication, counter is not fresh
In the figure above, the first three messages are similar to the
basic fast re-authentication case. When the peer detects that the
counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
attribute in EAP-Response/SIM/Re-authentication. This attribute
doesn’t contain any data, but it is a request for the server to
initiate full authentication. In this case, the peer MUST ignore the
contents of the server’s AT_NEXT_REAUTH_ID attribute.
On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and
verifies that AT_COUNTER contains the same counter value as in the
EAP-Request/SIM/Re-authentication packet. If not, the server
terminates the authentication exchange by sending the
EAP-Request/SIM/Notification with AT_NOTIFICATION code "General
failure" (16384). If all checks on the packet are successful, the
server transmits a new EAP-Request/SIM/Start packet and the full
authentication procedure is performed as usual. Since the server
already knows the subscriber identity, it MUST NOT include
AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_PERMANENT_ID_REQ in the
EAP-Request/SIM/Start.
It should be noted that in this case, peer identity is only
transmitted in the AT_IDENTITY attribute at the beginning of the
whole EAP exchange. The fast re-authentication identity used in this
AT_IDENTITY attribute will be used in key derivation (see Section 7).
6. EAP-SIM Notifications
6.1. General
EAP-SIM does not prohibit the use of the EAP Notifications as
specified in [RFC3748]. EAP Notifications can be used at any time in
the EAP-SIM exchange. It should be noted that EAP-SIM does not
protect EAP Notifications. EAP-SIM also specifies method-specific
EAP-SIM notifications that are protected in some cases.
The EAP server can use EAP-SIM notifications to convey notifications
and result indications (Section 6.2) to the peer.
The server MUST use notifications in cases discussed in
Section 6.3.2. When the EAP server issues an
EAP-Request/SIM/Notification packet to the peer, the peer MUST
process the notification packet. The peer MAY show a notification
message to the user and the peer MUST respond to the EAP server with
an EAP-Response/SIM/Notification packet, even if the peer did not
recognize the notification code.
An EAP-SIM full authentication exchange or a fast re-authentication
exchange MUST NOT include more than one EAP-SIM notification round.
The notification code is a 16-bit number. The most significant bit
is called the Success bit (S bit). The S bit specifies whether the
notification implies failure. The code values with the S bit set to
zero (code values 0...32767) are used on unsuccessful cases. The
receipt of a notification code from this range implies a failed EAP
exchange, so the peer can use the notification as a failure
indication. After receiving the EAP-Response/SIM/Notification for
these notification codes, the server MUST send the EAP-Failure
packet.
The receipt of a notification code with the S bit set to one (values
32768...65536) does not imply failure. Notification code "Success"
(32768) has been reserved as a general notification code to indicate
successful authentication.
The second most significant bit of the notification code is called
the Phase bit (P bit). It specifies at which phase of the EAP-SIM
exchange the notification can be used. If the P bit is set to zero,
the notification can only be used after a successful
EAP/SIM/Challenge round in full authentication or a successful
EAP/SIM/Re-authentication round in reauthentication. A
re-authentication round is considered successful only if the peer has
successfully verified AT_MAC and AT_COUNTER attributes, and does not
include the AT_COUNTER_TOO_SMALL attribute in
EAP-Response/SIM/Re-authentication.
If the P bit is set to one, the notification can only by used before
the EAP/SIM/Challenge round in full authentication, or before the
EAP/SIM/Re-authentication round in reauthentication. These
notifications can only be used to indicate various failure cases. In
other words, if the P bit is set to one, then the S bit MUST be set
to zero.
Section 9.8 and Section 9.9 specify what other attributes must be
included in the notification packets.
Some of the notification codes are authorization related and, hence,
are not usually considered part of the responsibility of an EAP
method. However, they are included as part of EAP-SIM because there
are currently no other ways to convey this information to the user in
a localizable way, and the information is potentially useful for the
user. An EAP-SIM server implementation may decide never to send
these EAP-SIM notifications.
6.2. Result Indications
As discussed in Section 6.3, the server and the peer use explicit
error messages in all error cases. If the server detects an error
after successful authentication, the server uses an EAP-SIM
notification to indicate failure to the peer. In this case, the
result indication is integrity and replay protected.
By sending an EAP-Response/SIM/Challenge packet or an
EAP-Response/SIM/Re-authentication packet (without
AT_COUNTER_TOO_SMALL), the peer indicates that it has successfully
authenticated the server and that the peer’s local policy accepts the
EAP exchange. In other words, these packets are implicit success
indications from the peer to the server.
EAP-SIM also supports optional protected success indications from the
server to the peer. If the EAP server wants to use protected success
indications, it includes the AT_RESULT_IND attribute in the
EAP-Request/SIM/Challenge or the EAP-Request/SIM/Re-authentication
packet. This attribute indicates that the EAP server would like to
use result indications in both successful and unsuccessful cases. If
the peer also wants this, the peer includes AT_RESULT_IND in
EAP-Response/SIM/Challenge or EAP-Response/SIM/Re-authentication.
The peer MUST NOT include AT_RESULT_IND if it did not receive
AT_RESULT_IND from the server. If both the peer and the server used
AT_RESULT_IND, then the EAP exchange is not complete yet, but an
EAP-SIM notification round will follow. The following EAP-SIM
notification may indicate either failure or success.
Success indications with the AT_NOTIFICATION code "Success" (32768)
can only be used if both the server and the peer indicate they want
to use them with AT_RESULT_IND. If the server did not include
AT_RESULT_IND in the EAP-Request/SIM/Challenge or
EAP-Request/SIM/Re-authentication packet, or if the peer did not
include AT_RESULT_IND in the corresponding response packet, then the
server MUST NOT use protected success indications.
Because the server uses the AT_NOTIFICATION code "Success" (32768) to
indicate that the EAP exchange has completed successfully, the EAP
exchange cannot fail when the server processes the EAP-SIM response
to this notification. Hence, the server MUST ignore the contents of
the EAP-SIM response it receives from the
EAP-Request/SIM/Notification with this code. Regardless of the
contents of the EAP-SIM response, the server MUST send EAP-Success as
the next packet.
6.3. Error Cases
This section specifies the operation of the peer and the server in
error cases. The subsections below require the EAP-SIM peer and
server to send an error packet (EAP-Response/SIM/Client-Error from
the peer or EAP-Request/SIM/Notification from the server) in error
cases. However, implementations SHOULD NOT rely upon the correct
error reporting behavior of the peer, authenticator, or the server.
It is possible for error and other messages to be lost in transit or
for a malicious participant to attempt to consume resources by not
issuing error messages. Both the peer and the EAP server SHOULD have
a mechanism to clean up state, even if an error message or
EAP-Success is not received after a timeout period.
6.3.1. Peer Operation
In general, if an EAP-SIM peer detects an error in a received EAP-SIM
packet, the EAP-SIM implementation responds with the
EAP-Response/SIM/Client-Error packet. In response to the
EAP-Response/SIM/Client-Error, the EAP server MUST issue the
EAP-Failure packet and the authentication exchange terminates.
By default, the peer uses the client error code 0, "unable to process
packet". This error code is used in the following cases:
o EAP exchange is not acceptable according to the peer’s local
policy.
o the peer is not able to parse the EAP request, i.e., the EAP
request is malformed.
o the peer encountered a malformed attribute.
o wrong attribute types or duplicate attributes have been included
in the EAP request.
o a mandatory attribute is missing.
o unrecognized, non-skippable attribute.
o unrecognized or unexpected EAP-SIM Subtype in the EAP request.
o A RAND challenge repeated in AT_RAND.
o invalid AT_MAC. The peer SHOULD log this event.
o invalid pad bytes in AT_PADDING.
o the peer does not want to process AT_PERMANENT_ID_REQ.
Separate error codes have been defined for the following error cases
in Section 10.19:
As specified in Section 4.1, when processing the AT_VERSION_LIST
attribute, which lists the EAP-SIM versions supported by the server,
if the attribute does not include a version that is implemented by
the peer and allowed in the peer’s security policy, then the peer
MUST send the EAP-Response/SIM/Client-Error packet with the error
code "unsupported version".
If the number of RAND challenges is smaller than what is required by
peer’s local policy when processing the AT_RAND attribute, the peer
MUST send the EAP-Response/SIM/Client-Error packet with the error
code "insufficient number of challenges".
If the peer believes that the RAND challenges included in AT_RAND are
not fresh e.g., because it is capable of remembering some previously
used RANDs, the peer MUST send the EAP-Response/SIM/Client-Error
packet with the error code "RANDs are not fresh".
6.3.2. Server Operation
If an EAP-SIM server detects an error in a received EAP-SIM response,
the server MUST issue the EAP-Request/SIM/Notification packet with an
AT_NOTIFICATION code that implies failure. By default, the server
uses one of the general failure codes ("General failure after
authentication" (0), or "General failure" (16384)). The choice
between these two codes depends on the phase of the EAP-SIM exchange,
see Section 6. When the server issues an EAP-
Request/SIM/Notification that implies failure, the error cases
include the following:
o the server is not able to parse the peer’s EAP response
o the server encounters a malformed attribute, a non-recognized
non-skippable attribute, or a duplicate attribute
o a mandatory attribute is missing or an invalid attribute was
included
o unrecognized or unexpected EAP-SIM Subtype in the EAP Response
o invalid AT_MAC. The server SHOULD log this event.
o invalid AT_COUNTER
6.3.3. EAP-Failure
The EAP-SIM server sends EAP-Failure in two cases:
1) In response to an EAP-Response/SIM/Client-Error packet the server
has received from the peer, or
2) Following an EAP-SIM notification round, when the AT_NOTIFICATION
code implies failure.
The EAP-SIM server MUST NOT send EAP-Failure in cases other than
these two. However, it should be noted that even though the EAP-SIM
server would not send an EAP-Failure, an authorization decision that
happens outside EAP-SIM, such as in the AAA server or in an
intermediate AAA proxy, may result in a failed exchange.
The peer MUST accept the EAP-Failure packet in case 1) and case 2),
above. The peer SHOULD silently discard the EAP-Failure packet in
other cases.
6.3.4. EAP-Success
On full authentication, the server can only send EAP-Success after
the EAP/SIM/Challenge round. The peer MUST silently discard any
EAP-Success packets if they are received before the peer has
successfully authenticated the server and sent the
EAP-Response/SIM/Challenge packet.
If the peer did not indicate that it wants to use protected success
indications with AT_RESULT_IND (as discussed in Section 6.2) on full
authentication, then the peer MUST accept EAP-Success after a
successful EAP/SIM/Challenge round.
If the peer indicated that it wants to use protected success
indications with AT_RESULT_IND (as discussed in Section 6.2), then
the peer MUST NOT accept EAP-Success after a successful
EAP/SIM/Challenge round. In this case, the peer MUST only accept
EAP-Success after receiving an EAP-SIM Notification with the
AT_NOTIFICATION code "Success" (32768).
On fast re-authentication, EAP-Success can only be sent after the
EAP/SIM/Re-authentication round. The peer MUST silently discard any
EAP-Success packets if they are received before the peer has
successfully authenticated the server and sent the
EAP-Response/SIM/Re-authentication packet.
If the peer did not indicate that it wants to use protected success
indications with AT_RESULT_IND (as discussed in Section 6.2) on fast
re-authentication, then the peer MUST accept EAP-Success after a
successful EAP/SIM/Re-authentication round.
If the peer indicated that it wants to use protected success
indications with AT_RESULT_IND (as discussed in Section 6.2), then
the peer MUST NOT accept EAP-Success after a successful EAP/SIM/Re-
authentication round. In this case, the peer MUST only accept
EAP-Success after receiving an EAP-SIM Notification with the
AT_NOTIFICATION code "Success" (32768).
If the peer receives an EAP-SIM notification (Section 6) that
indicates failure, then the peer MUST no longer accept the
EAP-Success packet, even if the server authentication was
successfully completed.
7. Key Generation
This section specifies how keying material is generated.
On EAP-SIM full authentication, a Master Key (MK) is derived from the
underlying GSM authentication values (Kc keys), the NONCE_MT, and
other relevant context as follows.
MK = SHA1(Identity|n*Kc| NONCE_MT| Version List| Selected Version)
In the formula above, the "|" character denotes concatenation.
"Identity" denotes the peer identity string without any terminating
null characters. It is the identity from the last AT_IDENTITY
attribute sent by the peer in this exchange, or, if AT_IDENTITY was
not used, it is the identity from the EAP-Response/Identity packet.
The identity string is included as-is, without any changes. As
discussed in Section 4.2.2.2, relying on EAP-Response/Identity for
conveying the EAP-SIM peer identity is discouraged, and the server
SHOULD use the EAP-SIM method-specific identity attributes.
The notation n*Kc in the formula above denotes the n Kc values
concatenated. The Kc keys are used in the same order as the RAND
challenges in AT_RAND attribute. NONCE_MT denotes the NONCE_MT value
(not the AT_NONCE_MT attribute, but only the nonce value). The
Version List includes the 2-byte-supported version numbers from
AT_VERSION_LIST, in the same order as in the attribute. The Selected
Version is the 2-byte selected version from AT_SELECTED_VERSION.
Network byte order is used, just as in the attributes. The hash
function SHA-1 is specified in [SHA-1]. If several EAP/SIM/Start
roundtrips are used in an EAP-SIM exchange, then the NONCE_MT,
Version List and Selected version from the last EAP/SIM/Start round
are used, and the previous EAP/SIM/Start rounds are ignored.
The Master Key is fed into a Pseudo-Random number Function (PRF)
which generates separate Transient EAP Keys (TEKs) for protecting
EAP-SIM packets, as well as a Master Session Key (MSK) for link layer
security, and an Extended Master Session Key (EMSK) for other
purposes. On fast re-authentication, the same TEKs MUST be used for
protecting EAP packets, but a new MSK and a new EMSK MUST be derived
from the original MK and from new values exchanged in the fast
re-authentication.
EAP-SIM requires two TEKs for its own purposes; the authentication
key K_aut is to be used with the AT_MAC attribute, and the encryption
key K_encr is to be used with the AT_ENCR_DATA attribute. The same
K_aut and K_encr keys are used in full authentication and subsequent
fast re-authentications.
Key derivation is based on the random number generation specified in
NIST Federal Information Processing Standards (FIPS) Publication
186-2 [PRF]. The pseudo-random number generator is specified in the
change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As
specified in the change notice (page 74), when Algorithm 1 is used as
a general-purpose pseudo-random number generator, the "mod q" term in
step 3.3 is omitted. The function G used in the algorithm is
constructed via the Secure Hash Standard, as specified in Appendix
3.3 of the standard. It should be noted that the function G is very
similar to SHA-1, but the message padding is different. Please refer
to [PRF] for full details. For convenience, the random number
algorithm with the correct modification is cited in Appendix B.
160-bit XKEY and XVAL values are used, so b = 160. On each full
authentication, the Master Key is used as the initial secret seed-key
XKEY. The optional user input values (XSEED_j) in step 3.1 are set
to zero.
On full authentication, the resulting 320-bit random numbers (x_0,
x_1, ..., x_m-1) are concatenated and partitioned into suitable-sized
chunks and used as keys in the following order: K_encr (128 bits),
K_aut (128 bits), Master Session Key (64 bytes), Extended Master
Session Key (64 bytes).
On fast re-authentication, the same pseudo-random number generator
can be used to generate a new Master Session Key and a new Extended
Master Session Key. The seed value XKEY’ is calculated as follows:
XKEY’ = SHA1(Identity|counter|NONCE_S| MK)
In the formula above, the Identity denotes the fast re-authentication
identity, without any terminating null characters, from the
AT_IDENTITY attribute of the EAP-Response/SIM/Start packet, or, if
EAP-Response/SIM/Start was not used on fast re-authentication, it
denotes the identity string from the EAP-Response/Identity packet.
The counter denotes the counter value from the AT_COUNTER attribute
used in the EAP-Response/SIM/Re-authentication packet. The counter
is used in network byte order. NONCE_S denotes the 16-byte NONCE_S
value from the AT_NONCE_S attribute used in the
EAP-Request/SIM/Re-authentication packet. The MK is the Master Key
derived on the preceding full authentication.
On fast re-authentication, the pseudo-random number generator is run
with the new seed value XKEY’, and the resulting 320-bit random
numbers (x_0, x_1, ..., x_m-1) are concatenated and partitioned into
two 64-byte chunks and used as the new 64-byte Master Session Key and
the new 64-byte Extended Master Session Key. Note that because
K_encr and K_aut are not derived on fast re-authentication, the
Master Session Key and the Extended Master Session key are obtained
from the beginning of the key stream (x_0, x_1, ...).
The first 32 bytes of the MSK can be used as the Pairwise Master Key
(PMK) for IEEE 802.11i.
When the RADIUS attributes specified in [RFC2548] are used to
transport keying material, then the first 32 bytes of the MSK
correspond to MS-MPPE-RECV-KEY and the second 32 bytes to
MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material
(the MSK) are used.
When generating the initial Master Key, the hash function is used as
a mixing function to combine several session keys (Kc’s) generated by
the GSM authentication procedure and the random number NONCE_MT into
a single session key. There are several reasons for this. The
current GSM session keys are, at most, 64 bits, so two or more of
them are needed to generate a longer key. By using a one-way
function to combine the keys, we are assured that, even if an
attacker managed to learn one of the EAP-SIM session keys, it
wouldn’t help him in learning the original GSM Kc’s. In addition,
since we include the random number NONCE_MT in the calculation, the
peer is able to verify that the EAP-SIM packets it receives from the
network are fresh and not replays (also see Section 11).
8. Message Format and Protocol Extensibility
8.1. Message Format
As specified in [RFC3748], EAP packets begin with the Code,
Identifiers, Length, and Type fields, which are followed by EAP-
method-specific Type-Data. The Code field in the EAP header is set
to 1 for EAP requests, and to 2 for EAP Responses. The usage of the
Length and Identifier fields in the EAP header are also specified in
[RFC3748]. In EAP-SIM, the Type field is set to 18.
In EAP-SIM, the Type-Data begins with an EAP-SIM header that consists
of a 1-octet Subtype field and a 2-octet reserved field. The Subtype
values used in EAP-SIM are defined in the IANA considerations section
of the EAP-AKA specification [EAP-AKA]. The formats of the EAP
header and the EAP-SIM header are shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The rest of the Type-Data that immediately follows the EAP-SIM header
consists of attributes that are encoded in Type, Length, Value
format. The figure below shows the generic format of an attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
Indicates the particular type of attribute. The attribute type
values are listed in the IANA considerations section of the
EAP-AKA specification [EAP-AKA].
Length
Indicates the length of this attribute in multiples of four