10.18. AT_NOTIFICATION
The format of the AT_NOTIFICATION attribute is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_NOTIFICATION| Length = 1 |S|P| Notification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute contains a two-byte notification
code. The first and second bit (S and P) of the notification code
are interpreted as described in Section 6.
The notification code values listed below have been reserved. The
descriptions below illustrate the semantics of the notifications.
The peer implementation MAY use different wordings when presenting
the notifications to the user. The "requested service" depends on
the environment where EAP-SIM is applied.
0 - General failure after authentication. (Implies failure, used
after successful authentication.)
16384 - General failure. (Implies failure, used before
authentication.)
32768 - Success. User has been successfully authenticated. (Does
not imply failure, used after successful authentication). The usage
of this code is discussed in Section 6.2.
1026 - User has been temporarily denied access to the requested
service. (Implies failure, used after successful authentication.)
1031 - User has not subscribed to the requested service. (Implies
failure, used after successful authentication.)
10.19. AT_CLIENT_ERROR_CODE
The format of the AT_CLIENT_ERROR_CODE attribute is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_CLIENT_ERR..| Length = 1 | Client Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute contains a two-byte client error
code. The following error code values have been reserved.
0 "unable to process packet": a general error code
1 "unsupported version": the peer does not support any of
the versions listed in AT_VERSION_LIST
2 "insufficient number of challenges": the peer’s policy
requires more triplets than the server included in AT_RAND
3 "RANDs are not fresh": the peer believes that the RAND
challenges included in AT_RAND were not fresh
11. IANA Considerations
IANA has assigned the EAP type number 18 for this protocol.
EAP-SIM shares most of the protocol design, such as attributes and
message Subtypes, with EAP-AKA [EAP-AKA]. EAP-SIM protocol numbers
should be administered in the same IANA registry as EAP-AKA. The
initial values are listed in [EAP-AKA] for both protocols, so this
document does not require any new registries or parameter allocation.
As a common registry is used for EAP-SIM and EAP-AKA, the protocol
number allocation policy for both protocols is specified in
[EAP-AKA].
12. Security Considerations
The EAP specification [RFC3748] describes the security
vulnerabilities of EAP, which does not include its own security
mechanisms. This section discusses the claimed security properties
of EAP-SIM, as well as vulnerabilities and security recommendations.
12.1. A3 and A8 Algorithms
The GSM A3 and A8 algorithms are used in EAP-SIM. [GSM-03.20]
specifies the general GSM authentication procedure and the external
interface (inputs and outputs) of the A3 and A8 algorithms. The
operation of these functions falls completely within the domain of an
individual operator, and therefore, the functions are specified by
each operator rather than being fully standardised. The GSM-MILENAGE
algorithm, specified publicly in [3GPP-TS-55.205], is an example
algorithm set for A3 and A8 algorithms.
The security of the A3 and A8 algorithms is important to the security
of EAP-SIM. Some A3/A8 algorithms have been compromised; see [GSM-
Cloning] for discussion about the security of COMP-128 version 1.
Note that several revised versions of the COMP-128 A3/A8 algorithm
have been devised after the publication of these weaknesses and that
the publicly specified GSM-MILENAGE algorithm is not vulnerable to
any known attacks.
12.2. Identity Protection
EAP-SIM includes optional identity privacy support that protects the
privacy of the subscriber identity against passive eavesdropping.
This document only specifies a mechanism to deliver pseudonyms from
the server to the peer as part of an EAP-SIM exchange. Hence, a peer
that has not yet performed any EAP-SIM exchanges does not typically
have a pseudonym available. If the peer does not have a pseudonym
available, then the privacy mechanism cannot be used, but the
permanent identity will have to be sent in the clear. The terminal
SHOULD store the pseudonym in a non-volatile memory so that it can be
maintained across reboots. An active attacker that impersonates the
network may use the AT_PERMANENT_ID_REQ attribute to attempt to learn
the subscriber’s permanent identity. However, as discussed in
Section 4.2.2, the terminal can refuse to send the cleartext
permanent identity if it believes that the network should be able to
recognize the pseudonym.
If the peer and server cannot guarantee that the pseudonym will be
maintained reliably, and identity privacy is required, then
additional protection from an external security mechanism (such as
Protected Extensible Authentication Protocol (PEAP) [PEAP]) may be
used. If an external security mechanism is in use, the identity
privacy features of EAP-SIM may not be useful. The security
considerations of using an external security mechanism with EAP-SIM
are beyond the scope of this document.
12.3. Mutual Authentication and Triplet Exposure
EAP-SIM provides mutual authentication. The peer believes that the
network is authentic because the network can calculate a correct
AT_MAC value in the EAP-Request/SIM/Challenge packet. To calculate
AT_MAC it is sufficient to know the RAND and Kc values from the GSM
triplets (RAND, SRES, Kc) used in the authentication. Because the
network selects the RAND challenges and the triplets, an attacker
that knows n (2 or 3) GSM triplets for the subscriber is able to
impersonate a valid network to the peer. (Some peers MAY employ an
implementation-specific counter-measure against impersonating a valid
network by re-using a previously used RAND; see below.) In other
words, the security of EAP-SIM is based on the secrecy of Kc keys,
which are considered secret intermediate results in the EAP-SIM
cryptographic calculations.
Given physical access to the SIM card, it is easy to obtain any
number of GSM triplets.
Another way to obtain triplets is to mount an attack on the peer
platform via a virus or other malicious piece of software. The peer
SHOULD be protected against triplet querying attacks by malicious
software. Care should be taken not to expose Kc keys to attackers
when they are stored or handled by the peer, or transmitted between
subsystems of the peer. Steps should be taken to limit the
transport, storage, and handling of these values outside a protected
environment within the peer. However, the virus protection of the
peer and the security capabilities of the peer’s operating system are
outside the scope of this document.
The EAP-SIM server typically obtains the triplets from the Home
Location Register (HLR). An attacker might try to obtain triplets by
attacking against the network used between the EAP-SIM server and the
HLR. Care should be taken not to expose Kc keys to attackers when
they are stored or handled by the EAP-SIM server, or transmitted
between the EAP server and the HLR. Steps should be taken to limit
the transport, storage, and handling of these values outside a
protected environment. However, the protection of the communications
between the EAP-SIM server and the HLR is outside the scope of this
document.
If the same SIM credentials are also used for GSM traffic, the
triplets could be revealed in the GSM network; see Section 12.8.
In GSM, the network is allowed to re-use the RAND challenge in
consecutive authentication exchanges. This is not allowed in
EAP-SIM. The EAP-SIM server is mandated to use fresh triplets (RAND
challenges) in consecutive authentication exchanges, as specified in
Section 3. EAP-SIM does not mandate any means for the peer to check
if the RANDs are fresh, so the security of the scheme leans on the
secrecy of the triplets. However, the peer MAY employ
implementation-specific mechanisms to remember some of the previously
used RANDs, and the peer MAY check the freshness of the server’s
RANDs. The operation in cases when the peer detects that the RANDs
are not fresh is specified in Section 6.3.1.
Preventing the re-use of authentication vectors has been taken into
account in the design of the UMTS Authentication and Key Agreement
(AKA), which is used in EAP-AKA [EAP-AKA]. In cases when the triplet
re-use properties of EAP-SIM are not considered sufficient, it is
advised to use EAP-AKA.
Note that EAP-SIM mutual authentication is done with the EAP server.
In general, EAP methods do not authenticate the identity or services
provided by the EAP authenticator (if distinct from the EAP server)
unless they provide the so-called channel bindings property. The
vulnerabilities related to this have been discussed in [RFC3748],
[EAP-Keying], [Service-Identity].
EAP-SIM does not provide the channel bindings property, so it only
authenticates the EAP server. However, ongoing work such as
[Service-Identity] may provide such support as an extension to
popular EAP methods such as EAP-TLS, EAP-SIM, or EAP-AKA.
12.4. Flooding the Authentication Centre
The EAP-SIM server typically obtains authentication vectors from the
Authentication Centre (AuC). EAP-SIM introduces a new usage for the
AuC. The protocols between the EAP-SIM server and the AuC are out of
the scope of this document. However, it should be noted that a
malicious EAP-SIM peer may generate a lot of protocol requests to
mount a denial of service attack. The EAP-SIM server implementation
SHOULD take this into account and SHOULD take steps to limit the
traffic that it generates towards the AuC, preventing the attacker
from flooding the AuC and from extending the denial of service attack
from EAP-SIM to other users of the AuC.
12.5. Key Derivation
EAP-SIM supports key derivation. The key hierarchy is specified in
Section 7. EAP-SIM combines several GSM triplets in order to
generate stronger keying material and stronger AT_MAC values. The
actual strength of the resulting keys depends, among other things, on
operator-specific parameters including authentication algorithms, the
strength of the Ki key, and the quality of the RAND challenges. For
example, some SIM cards generate Kc keys with 10 bits set to zero.
Such restrictions may prevent the concatenation technique from
yielding strong session keys. Because the strength of the Ki key is
128 bits, the ultimate strength of any derived secret key material is
never more than 128 bits.
It should also be noted that a security policy that allows n=2 to be
used may compromise the security of a future policy that requires
three triplets, because adversaries may be able to exploit the
messages exchanged when the weaker policy is applied.
There is no known way to obtain complete GSM triplets by mounting an
attack against EAP-SIM. A passive eavesdropper can learn n*RAND and
AT_MAC and may be able to link this information to the subscriber
identity. An active attacker that impersonates a GSM subscriber can
easily obtain n*RAND and AT_MAC values from the EAP server for any
given subscriber identity. However, calculating the Kc and SRES
values from AT_MAC would require the attacker to reverse the keyed
message authentication code function HMAC-SHA1-128.
As EAP-SIM does not expose any values calculated from an individual
GSM Kc keys, it is not possible to mount a brute force attack on only
one of the Kc keys in EAP-SIM. Therefore, when considering brute
force attacks on the values exposed in EAP-SIM, the effective length
of EAP-SIM session keys is not compromised by the fact that they are
combined from several shorter keys, i.e., the effective length of 128
bits may be achieved. For additional considerations, see Section
12.8.
12.6. Cryptographic Separation of Keys and Session Independence
The EAP Transient Keys used to protect EAP-SIM packets (K_encr,
K_aut), the Master Session Key, and the Extended Master Session Key
are cryptographically separate in EAP-SIM. An attacker cannot derive
any non-trivial information about any of these keys based on the
other keys. An attacker also cannot calculate the pre-shared secret
(Ki) from the GSM Kc keys, from EAP-SIM K_encr, from EAP-SIM K_aut,
from the Master Session Key, or from the Extended Master Session Key.
Each EAP-SIM exchange generates fresh keying material, and the keying
material exported from the method upon separate EAP-SIM exchanges is
cryptographically separate. The EAP-SIM peer contributes to the
keying material with the NONCE_MT parameter, which must be chosen
freshly for each full authentication exchange. The EAP server is
mandated to choose the RAND challenges freshly for each full
authentication exchange. If either the server or the peer chooses
its random value (NONCE_MT or RAND challenges) freshly, even if the
other entity re-used its value from a previous exchange, then the EAP
Transient Keys, the Master Session Key, and the Extended Master
Session Key will be different and cryptographically separate from the
corresponding values derived upon the previous full authentication
exchange.
On fast re-authentication, freshness of the Master Session Key and
the Extended Master Session Key is provided with a counter
(AT_COUNTER). The same EAP Transient Keys (K_encr, K_aut) that were
used in the full authentication exchange are used to protect the EAP
negotiation. However, replay and integrity protection across all the
fast re-authentication exchanges that use the same EAP Transient Keys
is provided with AT_COUNTER.
[RFC3748] defines session independence as the "demonstration that
passive attacks (such as capture of the EAP conversation) or active
attacks (including compromise of the MSK or EMSK) do not enable
compromise of subsequent or prior MSKs or EMSKs". Because the MSKs
and EMSKs are separate between EAP exchanges, EAP-SIM supports this
security claim.
It should be noted that [Patel-2003], which predates [RFC3748], uses
a slightly different meaning for session independence. The EAP-SIM
protocol does not allow the peer to ensure that different Kc key
values would be used in different exchanges. Only the server is able
to ensure that fresh RANDs, and therefore, fresh Kc keys are used.
Hence, the peer cannot guarantee EAP-SIM sessions to be independent
with regard to the internal Kc values. However, in EAP-SIM, the Kc
keys are considered to be secret intermediate results, which are not
exported outside the method. See Section 12.3 for more information
about RAND re-use.
12.7. Dictionary Attacks
Because EAP-SIM is not a password protocol, it is not vulnerable to
dictionary attacks. (The pre-shared symmetric secret stored on the
SIM card is not a passphrase, nor is it derived from a passphrase.)
12.8. Credentials Re-use
EAP-SIM cannot prevent attacks over the GSM or GPRS radio networks.
If the same SIM credentials are also used in GSM or GPRS, it is
possible to mount attacks over the cellular interface.
A passive attacker can eavesdrop GSM or GPRS traffic and obtain RAND,
SRES pairs. He can then use a brute force attack or other
cryptanalysis techniques to obtain the 64-bit Kc keys used to encrypt
the GSM or GPRS data. This makes it possible to attack each 64-bit
key separately.
An active attacker can mount a "rogue GSM/GPRS base station attack",
replaying previously seen RAND challenges to obtain SRES values. He
can then use a brute force attack to obtain the Kc keys. If
successful, the attacker can impersonate a valid network or decrypt
previously seen traffic, because EAP-SIM does not provide perfect
forward secrecy (PFS).
Due to several weaknesses in the GSM encryption algorithms, the
effective key strength of the Kc keys is much less than the expected
64 bits (no more than 40 bits if the A5/1 GSM encryption algorithm is
used; as documented in [Barkan-2003], an active attacker can force
the peer to use the weaker A5/2 algorithm that can be broken in less
than a second).
Because the A5 encryption algorithm is not used in EAP-SIM, and
because EAP-SIM does not expose any values calculated from individual
Kc keys, it should be noted that these attacks are not possible if
the SIM credentials used in EAP-SIM are not shared in GSM/GPRS.
At the time this document was written, the 3rd Generation Partnership
Project (3GPP) has started to work on fixes to these A5
vulnerabilities. One of the solution proposals discussed in 3GPP is
integrity-protected A5 version negotiation, which would require the
base station to prove knowledge of the Kc key before the terminal
sends any values calculated from the Kc to the network. Another
proposal is so-called special RANDs, where some bits of the RAND
challenge would be used for cryptographic separation by indicating
the allowed use of the triplet, such as the allowed A5 algorithm in
GSM or the fact that the triplet is intended for EAP-SIM. This is
currently a work in progress, and the mechanisms have not been
selected yet.
12.9. Integrity and Replay Protection, and Confidentiality
AT_MAC, AT_IV, AT_ENCR_DATA, and AT_COUNTER attributes are used to
provide integrity, replay and confidentiality protection for EAP-SIM
requests and responses. Integrity protection with AT_MAC includes
the EAP header. These attributes cannot be used during the
EAP/SIM/Start roundtrip. However, the protocol values (user identity
string, NONCE_MT, and version negotiation parameters) are
(implicitly) protected by later EAP-SIM messages by including them in
key derivation.
Integrity protection (AT_MAC) is based on a keyed message
authentication code. Confidentiality (AT_ENCR_DATA and AT_IV) is
based on a block cipher.
Confidentiality protection is applied only to a part of the protocol
fields. The table of attributes in Section 10.1 summarizes which
fields are confidentiality-protected. It should be noted that the
error and notification code attributes AT_CLIENT_ERROR_CODE and
AT_NOTIFICATION are not confidential, but they are transmitted in the
clear. Identity protection is discussed in Section 12.2.
On full authentication, replay protection of the EAP exchange is
provided by the RAND values from the underlying GSM authentication
scheme and the use of the NONCE_MT value. Protection against replays
of EAP-SIM messages is also based on the fact that messages that can
include AT_MAC can only be sent once with a certain EAP-SIM Subtype,
and on the fact that a different K_aut key will be used for
calculating AT_MAC in each full authentication exchange.
On fast re-authentication, a counter included in AT_COUNTER and a
server random nonce is used to provide replay protection. The
AT_COUNTER attribute is also included in EAP-SIM notifications if it
is used after successful authentication in order to provide replay
protection between re-authentication exchanges.
Because EAP-SIM is not a tunneling method, EAP-Request/Notification,
EAP-Response/Notification, EAP-Success, or EAP-Failure packets are
not confidential, integrity-protected, or replay-protected in
EAP-SIM. On physically insecure networks, this may enable an
attacker to send false notifications to the peer and to mount denial
of service attacks by spoofing these packets. As discussed in
Section 6.3, the peer will only accept EAP-Success after the peer
successfully authenticates the server. Hence, the attacker cannot
force the peer to believe successful mutual authentication has
occurred until the peer successfully authenticates the server or
after the peer fails to authenticate the server.
The security considerations of EAP-SIM result indications are covered
in Section 12.11
An eavesdropper will see the EAP-Request/Notification,
EAP-Response/Notification, EAP-Success, and EAP-Failure packets sent
in the clear. With EAP-SIM, confidential information MUST NOT be
transmitted in EAP Notification packets.
12.10. Negotiation Attacks
EAP-SIM does not protect the EAP-Response/Nak packet. Because
EAP-SIM does not protect the EAP method negotiation, EAP method
downgrading attacks may be possible, especially if the user uses the
same identity with EAP-SIM and other EAP methods.
EAP-SIM includes a version negotiation procedure. In EAP-SIM the
keying material derivation includes the version list and selected
version to ensure that the protocol cannot be downgraded and that the
peer and server use the same version of EAP-SIM.
EAP-SIM does not support ciphersuite negotiation.
12.11. Protected Result Indications
EAP-SIM supports optional protected success indications and
acknowledged failure indications. If a failure occurs after
successful authentication, then the EAP-SIM failure indication is
integrity- and replay-protected.
Even if an EAP-Failure packet is lost when using EAP-SIM over an
unreliable medium, then the EAP-SIM failure indications will help
ensure that the peer and EAP server will know the other party’s
authentication decision. If protected success indications are used,
then the loss of Success packet will also be addressed by the
acknowledged, integrity- and replay-protected EAP-SIM success
indication. If the optional success indications are not used, then
the peer may end up believing that the server succeeded
authentication, when it actually failed. Since access will not be
granted in this case, protected result indications are not needed
unless the client is not able to realize it does not have access for
an extended period of time.
12.12. Man-in-the-Middle Attacks
In order to avoid man-in-the-middle attacks and session hijacking,
user data SHOULD be integrity-protected on physically insecure
networks. The EAP-SIM Master Session Key, or keys derived from it,
MAY be used as the integrity protection keys, or, if an external
security mechanism such as PEAP is used, then the link integrity
protection keys MAY be derived by the external security mechanism.
There are man-in-the-middle attacks associated with the use of any
EAP method within a tunneled protocol. For instance, an early
version of PEAP [PEAP-02] was vulnerable to this attack. This
specification does not address these attacks. If EAP-SIM is used
with a tunneling protocol, there should be cryptographic binding
provided between the protocol and EAP-SIM to prevent
man-in-the-middle attacks through rogue authenticators being able to
setup one-way authenticated tunnels. For example, newer versions of
PEAP include such cryptographic binding. The EAP-SIM Master Session
Key MAY be used to provide the cryptographic binding. However, the
mechanism by which the binding is provided depends on the tunneling
protocol and is beyond the scope of this document.
12.13. Generating Random Numbers
An EAP-SIM implementation SHOULD use a good source of randomness to
generate the random numbers required in the protocol. Please see
[RFC4086] for more information on generating random numbers for
security applications.
13. Security Claims
This section provides the security claims required by [RFC3748].
Auth. mechanism: EAP-SIM is based on the GSM SIM mechanism, which is
a challenge/response authentication and key agreement mechanism based
on a symmetric 128-bit pre-shared secret. EAP-SIM also makes use of
a peer challenge to provide mutual authentication.
Ciphersuite negotiation: No
Mutual authentication: Yes (Section 12.3)
Integrity protection: Yes (Section 12.9)
Replay protection: Yes (Section 12.9)
Confidentiality: Yes, except method-specific success and failure
indications (Section 12.2, Section 12.9)
Key derivation: Yes
Key strength: EAP-SIM supports key derivation with 128-bit effective
key strength (Section 12.5). However, as discussed in Section 11, if
the same credentials are used in GSM/GPRS and in EAP-SIM, then the