tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4186

 
 
 

Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)

Part 4 of 5, p. 48 to 77
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 48 
9.  Messages

   This section specifies the messages used in EAP-SIM.  It specifies
   when a message may be transmitted or accepted, which attributes are
   allowed in a message, which attributes are required in a message, and
   other message-specific details.  The general message format is
   specified in Section 8.1.

9.1.  EAP-Request/SIM/Start

   In full authentication the first SIM-specific EAP Request is
   EAP-Request/SIM/Start.  The EAP/SIM/Start roundtrip is used for two
   purposes.  In full authentication this packet is used to request the
   peer to send the AT_NONCE_MT attribute to the server.  In addition,
   as specified in Section 4.2, the Start round trip may be used by the
   server for obtaining the peer identity.  As discussed in Section 4.2,
   several Start rounds may be required to obtain a valid peer identity.

   The server MUST always include the AT_VERSION_LIST attribute.

   The server MAY include one of the following identity-requesting
   attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or
   AT_ANY_ID_REQ.  These three attributes are mutually exclusive, so the
   server MUST NOT include more than one of the attributes.

   If the server has received a response from the peer, it MUST NOT
   issue a new EAP-Request/SIM/Start packet if it has previously issued
   an EAP-Request/SIM/Start message either without any identity
   requesting attributes or with the AT_PERMANENT_ID_REQ attribute.

   If the server has received a response from the peer, it MUST NOT
   issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ or
   AT_FULLAUTH_ID_REQ attributes if it has previously issued an
   EAP-Request/SIM/Start message with the AT_FULLAUTH_ID_REQ attribute.

Top      Up      ToC       Page 49 
   If the server has received a response from the peer, it MUST NOT
   issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ
   attribute if the server has previously issued an
   EAP-Request/SIM/Start message with the AT_ANY_ID_REQ attribute.

   This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.

9.2.  EAP-Response/SIM/Start

   The peer sends EAP-Response/SIM/Start in response to a valid
   EAP-Request/SIM/Start from the server.

   If and only if the server's EAP-Request/SIM/Start includes one of the
   identity-requesting attributes, then the peer MUST include the
   AT_IDENTITY attribute.  The usage of AT_IDENTITY is defined in
   Section 4.2.

   The AT_NONCE_MT attribute MUST NOT be included if the AT_IDENTITY
   with a fast re-authentication identity is present for fast
   re-authentication.  AT_NONCE_MT MUST be included in all other cases
   (full authentication).

   The AT_SELECTED_VERSION attribute MUST NOT be included if the
   AT_IDENTITY attribute with a fast re-authentication identity is
   present for fast re-authentication.  In all other cases,
   AT_SELECTED_VERSION MUST be included (full authentication).  This
   attribute is used in version negotiation, as specified in
   Section 4.1.

   This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.

9.3.  EAP-Request/SIM/Challenge

   The server sends the EAP-Request/SIM/Challenge after receiving a
   valid EAP-Response/SIM/Start that contains AT_NONCE_MT and
   AT_SELECTED_VERSION, and after successfully obtaining the subscriber
   identity.

   The AT_RAND attribute MUST be included.

   The AT_RESULT_IND attribute MAY be included.  The usage of this
   attribute is discussed in Section 6.2.

   The AT_MAC attribute MUST be included.  For
   EAP-Request/SIM/Challenge, the MAC code is calculated over the
   following data:

   EAP packet| NONCE_MT

Top      Up      ToC       Page 50 
   The EAP packet is represented as specified in Section 8.1.  It is
   followed by the 16-byte NONCE_MT value from the peer's AT_NONCE_MT
   attribute.

   The EAP-Request/SIM/Challenge packet MAY include encrypted attributes
   for identity privacy and for communicating the next fast
   re-authentication identity.  In this case, the AT_IV and AT_ENCR_DATA
   attributes are included (Section 10.12).

   The plaintext of the AT_ENCR_DATA value field consists of nested
   attributes.  The nested attributes MAY include AT_PADDING (as
   specified in Section 10.12).  If the server supports identity privacy
   and wants to communicate a pseudonym to the peer for the next full
   authentication, then the nested encrypted attributes include the
   AT_NEXT_PSEUDONYM attribute.  If the server supports
   re-authentication and wants to communicate a fast re-authentication
   identity to the peer, then the nested encrypted attributes include
   the AT_NEXT_REAUTH_ID attribute.

   When processing this message, the peer MUST process AT_RAND before
   processing other attributes.  Only if AT_RAND is verified to be
   valid, the peer derives keys and verifies AT_MAC.  The operation in
   case an error occurs is specified in Section 6.3.1.

9.4.  EAP-Response/SIM/Challenge

   The peer sends EAP-Response/SIM/Challenge in response to a valid
   EAP-Request/SIM/Challenge.

   Sending this packet indicates that the peer has successfully
   authenticated the server and that the EAP exchange will be accepted
   by the peer's local policy.  Hence, if these conditions are not met,
   then the peer MUST NOT send EAP-Response/SIM/Challenge, but the peer
   MUST send EAP-Response/SIM/Client-Error.

   The AT_MAC attribute MUST be included.  For EAP-
   Response/SIM/Challenge, the MAC code is calculated over the following
   data:

   EAP packet| n*SRES

   The EAP packet is represented as specified in Section 8.1.  The EAP
   packet bytes are immediately followed by the two or three SRES values
   concatenated, denoted above with the notation n*SRES.  The SRES
   values are used in the same order as the corresponding RAND
   challenges in the server's AT_RAND attribute.

Top      Up      ToC       Page 51 
   The AT_RESULT_IND attribute MAY be included if it was included in
   EAP-Request/SIM/Challenge.  The usage of this attribute is discussed
   in Section 6.2.

   Later versions of this protocol MAY make use of the AT_ENCR_DATA and
   AT_IV attributes in this message to include encrypted (skippable)
   attributes.  The EAP server MUST process EAP-Response/SIM/Challenge
   messages that include these attributes even if the server did not
   implement these optional attributes.

9.5.  EAP-Request/SIM/Re-authentication

   The server sends the EAP-Request/SIM/Re-authentication message if it
   wants to use fast re-authentication, and if it has received a valid
   fast re-authentication identity in EAP-Response/Identity or
   EAP-Response/SIM/Start.

   AT_MAC MUST be included.  No message-specific data is included in the
   MAC calculation.  See Section 10.14.

   The AT_RESULT_IND attribute MAY be included.  The usage of this
   attribute is discussed in Section 6.2.

   The AT_IV and AT_ENCR_DATA attributes MUST be included.  The
   plaintext consists of the following nested encrypted attributes,
   which MUST be included: AT_COUNTER and AT_NONCE_S.  In addition, the
   nested encrypted attributes MAY include the following attributes:
   AT_NEXT_REAUTH_ID and AT_PADDING.

9.6.  EAP-Response/SIM/Re-authentication

   The client sends the EAP-Response/SIM/Re-authentication packet in
   response to a valid EAP-Request/SIM/Re-authentication.

   The AT_MAC attribute MUST be included.  For
   EAP-Response/SIM/Re-authentication, the MAC code is calculated over
   the following data:

   EAP packet| NONCE_S

   The EAP packet is represented as specified in Section 8.1.  It is
   followed by the 16-byte NONCE_S value from the server's AT_NONCE_S
   attribute.

   The AT_IV and AT_ENCR_DATA attributes MUST be included.  The nested
   encrypted attributes MUST include the AT_COUNTER attribute.  The
   AT_COUNTER_TOO_SMALL attribute MAY be included in the nested

Top      Up      ToC       Page 52 
   encrypted attributes, and it is included in cases specified in
   Section 5.  The AT_PADDING attribute MAY be included.

   The AT_RESULT_IND attribute MAY be included if it was included in
   EAP-Request/SIM/Re-authentication.  The usage of this attribute is
   discussed in Section 6.2.

   Sending this packet without AT_COUNTER_TOO_SMALL indicates that the
   peer has successfully authenticated the server and that the EAP
   exchange will be accepted by the peer's local policy.  Hence, if
   these conditions are not met, then the peer MUST NOT send
   EAP-Response/SIM/Re-authentication, but the peer MUST send
   EAP-Response/SIM/Client-Error.

9.7.  EAP-Response/SIM/Client-Error

   The peer sends EAP-Response/SIM/Client-Error in error cases, as
   specified in Section 6.3.1.

   The AT_CLIENT_ERROR_CODE attribute MUST be included.

   The AT_MAC, AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with
   this packet.

9.8.  EAP-Request/SIM/Notification

   The usage of this message is specified in Section 6.  The
   AT_NOTIFICATION attribute MUST be included.

   The AT_MAC attribute MUST be included if the P bit of the
   notification code in AT_NOTIFICATION is set to zero, and MUST NOT be
   included in cases when the P bit is set to one.  The P bit is
   discussed in Section 6.

   No message-specific data is included in the MAC calculation.  See
   Section 10.14.

   If EAP-Request/SIM/Notification is used on a fast re-authentication
   exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
   AT_COUNTER is used for replay protection.  In this case, the
   AT_ENCR_DATA and AT_IV attributes MUST be included, and the
   encapsulated plaintext attributes MUST include the AT_COUNTER
   attribute.  The counter value included in AT_COUNTER MUST be the same
   as in the EAP-Request/SIM/Re-authentication packet on the same fast
   re-authentication exchange.

Top      Up      ToC       Page 53 
9.9.  EAP-Response/SIM/Notification

   The usage of this message is specified in Section 6.  This packet is
   an acknowledgement of EAP-Request/SIM/Notification.

   The AT_MAC attribute MUST be included in cases when the P bit of the
   notification code in AT_NOTIFICATION of EAP-Request/SIM/Notification
   is set to zero, and MUST NOT be included in cases when the P bit is
   set to one.  The P bit is discussed in Section 6.

   No message-specific data is included in the MAC calculation, see
   Section 10.14.

   If EAP-Request/SIM/Notification is used on a fast re-authentication
   exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
   AT_COUNTER is used for replay protection.  In this case, the
   AT_ENCR_DATA and AT_IV attributes MUST be included, and the
   encapsulated plaintext attributes MUST include the AT_COUNTER
   attribute.  The counter value included in AT_COUNTER MUST be the same
   as in the EAP-Request/SIM/Re-authentication packet on the same fast
   re-authentication exchange.

10.  Attributes

   This section specifies the format of message attributes.  The
   attribute type numbers are specified in the IANA considerations
   section of the EAP-AKA specification [EAP-AKA].

10.1.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kinds of messages, and in what quantity.  Messages are
   denoted with numbers in parentheses as follows: (1)
   EAP-Request/SIM/Start, (2) EAP-Response/SIM/Start, (3)
   EAP-Request/SIM/Challenge, (4) EAP-Response/SIM/Challenge, (5)
   EAP-Request/SIM/Notification, (6) EAP-Response/SIM/Notification, (7)
   EAP-Response/SIM/Client-Error, (8) EAP-Request/SIM/Re-authentication,
   and (9) EAP-Response/SIM/Re-authentication.  The column denoted with
   "Encr" indicates whether the attribute is a nested attribute that
   MUST be included within AT_ENCR_DATA, and the column denoted with
   "Skip" indicates whether the attribute is a skippable attribute.

   "0" indicates that the attribute MUST NOT be included in the message,
   "1" indicates that the attribute MUST be included in the message,
   "0-1" indicates that the attribute is sometimes included in the
   message, and "0*" indicates that the attribute is not included in the
   message in cases specified in this document, but MAY be included in
   future versions of the protocol.

Top      Up      ToC       Page 54 
              Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9)  Encr Skip
        AT_VERSION_LIST  1   0   0   0   0   0   0   0   0   N     N
    AT_SELECTED_VERSION  0  0-1  0   0   0   0   0   0   0   N     N
            AT_NONCE_MT  0  0-1  0   0   0   0   0   0   0   N     N
    AT_PERMANENT_ID_REQ 0-1  0   0   0   0   0   0   0   0   N     N
          AT_ANY_ID_REQ 0-1  0   0   0   0   0   0   0   0   N     N
     AT_FULLAUTH_ID_REQ 0-1  0   0   0   0   0   0   0   0   N     N
            AT_IDENTITY  0  0-1  0   0   0   0   0   0   0   N     N
                AT_RAND  0   0   1   0   0   0   0   0   0   N     N
      AT_NEXT_PSEUDONYM  0   0  0-1  0   0   0   0   0   0   Y     Y
      AT_NEXT_REAUTH_ID  0   0  0-1  0   0   0   0  0-1  0   Y     Y
                  AT_IV  0   0  0-1  0* 0-1 0-1  0   1   1   N     Y
           AT_ENCR_DATA  0   0  0-1  0* 0-1 0-1  0   1   1   N     Y
             AT_PADDING  0   0  0-1  0* 0-1 0-1  0  0-1 0-1  Y     N
          AT_RESULT_IND  0   0  0-1 0-1  0   0   0  0-1 0-1  N     Y
                 AT_MAC  0   0   1   1  0-1 0-1  0   1   1   N     N
             AT_COUNTER  0   0   0   0  0-1 0-1  0   1   1   Y     N
   AT_COUNTER_TOO_SMALL  0   0   0   0   0   0   0   0  0-1  Y     N
             AT_NONCE_S  0   0   0   0   0   0   0   1   0   Y     N
        AT_NOTIFICATION  0   0   0   0   1   0   0   0   0   N     N
   AT_CLIENT_ERROR_CODE  0   0   0   0   0   0   1   0   0   N     N

   It should be noted that attributes AT_PERMANENT_ID_REQ,
   AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive; only
   one of them can be included at the same time.  If one of the
   attributes AT_IV and AT_ENCR_DATA is included, then both of the
   attributes MUST be included.

10.2.  AT_VERSION_LIST

   The format of the AT_VERSION_LIST 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_VERSION_L..| Length        | Actual Version List Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Supported Version 1          |  Supported Version 2          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Supported Version N           |     Padding                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This attribute is used in version negotiation, as specified in
   Section 4.1.  The attribute contains the version numbers supported by
   the EAP-SIM server.  The server MUST only include versions that it

Top      Up      ToC       Page 55 
   implements and that are allowed in its security policy.  The server
   SHOULD list the versions in the order of preference, with the most
   preferred versions listed first.  At least one version number MUST be
   included.  The version number for the protocol described in this
   document is one (0001 hexadecimal).

   The value field of this attribute begins with 2-byte Actual Version
   List Length, which specifies the length of the Version List in bytes,
   not including the Actual Version List Length attribute length.  This
   field is followed by the list of the versions supported by the
   server, which each have a length of 2 bytes.  For example, if there
   is only one supported version, then the Actual Version List Length is
   2.  Because the length of the attribute must be a multiple of 4
   bytes, the sender pads the value field with zero bytes when
   necessary.

10.3.  AT_SELECTED_VERSION

   The format of the AT_SELECTED_VERSION 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_SELECTED...| Length = 1    |    Selected Version           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This attribute is used in version negotiation, as specified in
   Section 4.1.  The value field of this attribute contains a two-byte
   version number, which indicates the EAP-SIM version that the peer
   wants to use.

10.4.  AT_NONCE_MT

   The format of the AT_NONCE_MT 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_NONCE_MT    | Length = 5    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                           NONCE_MT                            |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 56 
   The value field of the NONCE_MT attribute contains two reserved bytes
   followed by a random number freshly generated by the peer (16 bytes
   long) for this EAP-SIM authentication exchange.  The random number is
   used as a seed value for the new keying material.  The reserved bytes
   are set to zero upon sending and ignored upon reception.

   The peer MUST NOT re-use the NONCE_MT value from a previous EAP-SIM
   authentication exchange.  If an EAP-SIM exchange includes several
   EAP/SIM/Start rounds, then the peer SHOULD use the same NONCE_MT
   value in all EAP-Response/SIM/Start packets.  The peer SHOULD use a
   good source of randomness to generate NONCE_MT.  Please see [RFC4086]
   for more information about generating random numbers for security
   applications.

10.5.  AT_PERMANENT_ID_REQ

   The format of the AT_PERMANENT_ID_REQ 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_PERM..._REQ | Length = 1    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The use of the AT_PERMANENT_ID_REQ is defined in Section 4.2.  The
   value field contains only two reserved bytes, which are set to zero
   on sending and ignored on reception.

10.6.  AT_ANY_ID_REQ

   The format of the AT_ANY_ID_REQ 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_ANY_ID_REQ  | Length = 1    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The use of the AT_ANY_ID_REQ is defined in Section 4.2.  The value
   field contains only two reserved bytes, which are set to zero on
   sending and ignored on reception.

Top      Up      ToC       Page 57 
10.7.  AT_FULLAUTH_ID_REQ

   The format of the AT_FULLAUTH_ID_REQ 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_FULLAUTH_...| Length = 1    |           Reserved            |
    +---------------+---------------+-------------------------------+

   The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.2.  The
   value field contains only two reserved bytes, which are set to zero
   on sending and ignored on reception.

10.8.  AT_IDENTITY

   The format of the AT_IDENTITY 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_IDENTITY   | Length        | Actual Identity Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                       Identity (optional)                     .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The use of the AT_IDENTITY is defined in Section 4.2.  The value
   field of this attribute begins with a 2-byte actual identity length,
   which specifies the length of the identity in bytes.  This field is
   followed by the subscriber identity of the indicated actual length.
   The identity is the permanent identity, a pseudonym identity, or a
   fast re-authentication identity.  The identity format is specified in
   Section 4.2.1.  The same identity format is used in the AT_IDENTITY
   attribute and the EAP-Response/Identity packet, with the exception
   that the peer MUST NOT decorate the identity it includes in
   AT_IDENTITY.  The identity does not include any terminating null
   characters.  Because the length of the attribute must be a multiple
   of 4 bytes, the sender pads the identity with zero bytes when
   necessary.

Top      Up      ToC       Page 58 
10.9.  AT_RAND

   The format of the AT_RAND 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_RAND       | Length        |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                            n*RAND                             .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute contains two reserved bytes
   followed by n GSM RANDs, each 16 bytes long.  The value of n can be
   determined by the attribute length.  The reserved bytes are set to
   zero upon sending and ignored upon reception.

   The number of RAND challenges (n) MUST be two or three.  The peer
   MUST verify that the number of RAND challenges is sufficient
   according to the peer's policy.  The server MUST use different RAND
   values.  In other words, a RAND value can only be included once in
   AT_RAND.  When processing the AT_RAND attribute, the peer MUST check
   that the RANDs are different.

   The EAP server MUST obtain fresh RANDs for each EAP-SIM full
   authentication exchange.  More specifically, the server MUST consider
   RANDs it included in AT_RAND to be consumed if the server receives an
   EAP-Response/SIM/Challenge packet with a valid AT_MAC, or an
   EAP-Response/SIM/Client-Error with the code "insufficient number of
   challenges" or "RANDs are not fresh".  However, in other cases (if
   the server does not receive a response to its
   EAP-Request/SIM/Challenge packet, or if the server receives a
   response other than the cases listed above), the server does not need
   to consider the RANDs to be consumed, and the server MAY re-use the
   RANDs in the AT_RAND attribute of the next full authentication
   attempt.

Top      Up      ToC       Page 59 
10.10.  AT_NEXT_PSEUDONYM

   The format of the AT_NEXT_PSEUDONYM 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_NEXT_PSEU..| Length        | Actual Pseudonym Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                          Next Pseudonym                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute begins with the 2-byte actual
   pseudonym length, which specifies the length of the following
   pseudonym in bytes.  This field is followed by a pseudonym username
   that the peer can use in the next authentication.  The username MUST
   NOT include any realm portion.  The username does not include any
   terminating null characters.  Because the length of the attribute
   must be a multiple of 4 bytes, the sender pads the pseudonym with
   zero bytes when necessary.  The username encoding MUST follow the
   UTF-8 transformation format [RFC3629].  This attribute MUST always be
   encrypted by encapsulating it within the AT_ENCR_DATA attribute.

10.11.  AT_NEXT_REAUTH_ID

   The format of the AT_NEXT_REAUTH_ID 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_NEXT_REAU..| Length        | Actual Re-Auth Identity Length|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .               Next Fast Re-authentication Username            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute begins with the 2-byte actual
   re-authentication identity length which specifies the length of the
   following fast re-authentication identity in bytes.  This field is
   followed by a fast re-authentication identity that the peer can use
   in the next fast re-authentication, as described in Section 5.  In
   environments where a realm portion is required, the fast
   re-authentication identity includes both a username portion and a

Top      Up      ToC       Page 60 
   realm name portion.  The fast re-authentication identity does not
   include any terminating null characters.  Because the length of the
   attribute must be a multiple of 4 bytes, the sender pads the fast
   re-authentication identity with zero bytes when necessary.  The
   identity encoding MUST follow the UTF-8 transformation format
   [RFC3629].  This attribute MUST always be encrypted by encapsulating
   it within the AT_ENCR_DATA attribute.

10.12.  AT_IV, AT_ENCR_DATA, and AT_PADDING

   AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted
   information between the EAP-SIM peer and server.

   The value field of AT_IV contains two reserved bytes followed by a
   16-byte initialization vector required by the AT_ENCR_DATA attribute.
   The reserved bytes are set to zero when sending and ignored on
   reception.  The AT_IV attribute MUST be included if and only if the
   AT_ENCR_DATA is included.  Section 6.3 specifies the operation if a
   packet that does not meet this condition is encountered.

   The sender of the AT_IV attribute chooses the initialization vector
   at random.  The sender MUST NOT re-use the initialization vector
   value from previous EAP-SIM packets.  The sender SHOULD use a good
   source of randomness to generate the initialization vector.  Please
   see [RFC4086] for more information about generating random numbers
   for security applications.  The format of AT_IV 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_IV     | Length = 5    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                 Initialization Vector                         |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of the AT_ENCR_DATA attribute consists of two
   reserved bytes followed by cipher text bytes encrypted using the
   Advanced Encryption Standard (AES) [AES] with a 128-bit key in the
   Cipher Block Chaining (CBC) mode of operation using the
   initialization vector from the AT_IV attribute.  The reserved bytes
   are set to zero when sending and ignored on reception.  Please see
   [CBC] for a description of the CBC mode.  The format of the
   AT_ENCR_DATA attribute is shown below.

Top      Up      ToC       Page 61 
     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_ENCR_DATA  | Length        |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                    Encrypted Data                             .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The derivation of the encryption key (K_encr) is specified in Section
   7.

   The plaintext consists of nested EAP-SIM attributes.

   The encryption algorithm requires the length of the plaintext to be a
   multiple of 16 bytes.  The sender may need to include the AT_PADDING
   attribute as the last attribute within AT_ENCR_DATA.  The AT_PADDING
   attribute is not included if the total length of other nested
   attributes within the AT_ENCR_DATA attribute is a multiple of 16
   bytes.  As usual, the Length of the Padding attribute includes the
   Attribute Type and Attribute Length fields.  The length of the
   Padding attribute is 4, 8, or 12 bytes.  It is chosen so that the
   length of the value field of the AT_ENCR_DATA attribute becomes a
   multiple of 16 bytes.  The actual pad bytes in the value field are
   set to zero (00 hexadecimal) on sending.  The recipient of the
   message MUST verify that the pad bytes are set to zero.  If this
   verification fails on the peer, then it MUST send the
   EAP-Response/SIM/Client-Error packet with the error code "unable to
   process packet" to terminate the authentication exchange.  If this
   verification fails on the server, then the server sends the peer the
   EAP-Request/SIM/Notification packet with an AT_NOTIFICATION code that
   implies failure to terminate the authentication exchange.  The format
   of the AT_PADDING 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_PADDING   | Length        | Padding...                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 62 
10.13.  AT_RESULT_IND

   The format of the AT_RESULT_IND 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_RESULT_...| Length = 1    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute consists of two reserved bytes,
   which are set to zero upon sending and ignored upon reception.  This
   attribute is always sent unencrypted, so it MUST NOT be encapsulated
   within the AT_ENCR_DATA attribute.

10.14.  AT_MAC

   The AT_MAC attribute is used for EAP-SIM message authentication.
   Section 8 specifies in which messages AT_MAC MUST be included.

   The value field of the AT_MAC attribute contains two reserved bytes
   followed by a keyed message authentication code (MAC).  The MAC is
   calculated over the whole EAP packet and concatenated with optional
   message-specific data, with the exception that the value field of the
   MAC attribute is set to zero when calculating the MAC.  The EAP
   packet includes the EAP header that begins with the Code field, the
   EAP-SIM header that begins with the Subtype field, and all the
   attributes, as specified in Section 8.1.  The reserved bytes in
   AT_MAC are set to zero when sending and ignored on reception.  The
   contents of the message-specific data that may be included in the MAC
   calculation are specified separately for each EAP-SIM message in
   Section 9.

   The format of the AT_MAC 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_MAC    | Length = 5    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                           MAC                                 |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 63 
   The MAC algorithm is an HMAC-SHA1-128 [RFC2104] keyed hash value.
   (The HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value
   by truncating the output to the first 16 bytes.  Hence, the length of
   the MAC is 16 bytes.  The derivation of the authentication key
   (K_aut) used in the calculation of the MAC is specified in Section 7.

   When the AT_MAC attribute is included in an EAP-SIM message, the
   recipient MUST process the AT_MAC attribute before looking at any
   other attributes, except when processing EAP-Request/SIM/Challenge.
   The processing of EAP-Request/SIM/Challenge is specified in Section
   9.3.  If the message authentication code is invalid, then the
   recipient MUST ignore all other attributes in the message and operate
   as specified in Section 6.3.

10.15.  AT_COUNTER

   The format of the AT_COUNTER 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_COUNTER   | Length = 1    |           Counter             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of the AT_COUNTER attribute consists of a 16-bit
   unsigned integer counter value, represented in network byte order.
   This attribute MUST always be encrypted by encapsulating it within
   the AT_ENCR_DATA attribute.

10.16.  AT_COUNTER_TOO_SMALL

   The format of the AT_COUNTER_TOO_SMALL 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_COUNTER...| Length = 1    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of this attribute consists of two reserved bytes,
   which are set to zero upon sending and ignored upon reception.  This
   attribute MUST always be encrypted by encapsulating it within the
   AT_ENCR_DATA attribute.

Top      Up      ToC       Page 64 
10.17.  AT_NONCE_S

   The format of the AT_NONCE_S 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_NONCE_S    | Length = 5    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                                                               |
    |                            NONCE_S                            |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The value field of the AT_NONCE_S attribute contains two reserved
   bytes followed by a random number freshly generated by the server (16
   bytes) for this EAP-SIM fast re-authentication.  The random number is
   used as a challenge for the peer and also as a seed value for the new
   keying material.  The reserved bytes are set to zero upon sending and
   ignored upon reception.  This attribute MUST always be encrypted by
   encapsulating it within the AT_ENCR_DATA attribute.

   The server MUST NOT re-use the NONCE_S value from any previous
   EAP-SIM fast re-authentication exchange.  The server SHOULD use a
   good source of randomness to generate NONCE_S.  Please see [RFC4086]
   for more information about generating random numbers for security
   applications.

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.

Top      Up      ToC       Page 65 
   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

Top      Up      ToC       Page 66 
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

Top      Up      ToC       Page 67 
   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.

Top      Up      ToC       Page 68 
   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.

Top      Up      ToC       Page 69 
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

Top      Up      ToC       Page 70 
   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.

Top      Up      ToC       Page 71 
   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

Top      Up      ToC       Page 72 
   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

Top      Up      ToC       Page 73 
   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

Top      Up      ToC       Page 74 
   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)

Top      Up      ToC       Page 75 
   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
   key strength may be reduced considerably, basically to the same level
   as in GSM, by mounting attacks over GSM/GPRS.  For example an active
   attack using a false GSM/GPRS base station reduces the effective key
   strength to almost zero.

   Description of key hierarchy: Please see Section 7.

   Dictionary attack protection: N/A (Section 12.7)

   Fast reconnect: Yes

   Cryptographic binding: N/A

   Session independence: Yes (Section 12.6)

   Fragmentation: No

   Channel binding: No

   Indication of vulnerabilities: Vulnerabilities are discussed in
   Section 12.

14.  Acknowledgements and Contributions

14.1.  Contributors

   In addition to the editors, Nora Dabbous, Jose Puthenkulam, and
   Prasanna Satarasinghe were significant contributors to this document.

   Pasi Eronen and Jukka-Pekka Honkanen contributed Appendix A.

14.2.  Acknowledgements

   Juha Ala-Laurila, N. Asokan, Jan-Erik Ekberg, Patrik Flykt,
   Jukka-Pekka Honkanen, Antti Kuikka, Jukka Latva, Lassi Lehtinen, Jyri
   Rinnemaa, Timo Takamaki, and Raimo Vuonnala contributed many original
   ideas and concepts to this protocol.

Top      Up      ToC       Page 76 
   N. Asokan, Pasi Eronen, and Jukka-Pekka Honkanen contributed and
   helped in innumerable ways during the development of the protocol.

   Valtteri Niemi and Kaisa Nyberg contributed substantially to the
   design of the key derivation and the fast re-authentication
   procedure, and have also provided their cryptographic expertise in
   many discussions related to this protocol.

   Simon Blake-Wilson provided very helpful comments on key derivation
   and version negotiation.

   Thanks to Greg Rose for his very valuable comments to an early
   version of this specification [S3-020125], and for reviewing and
   providing very useful comments on version 12.

   Thanks to Bernard Aboba, Vladimir Alperovich, Florent Bersani,
   Jacques Caron, Gopal Dommety, Augustin Farrugia, Mark Grayson, Max de
   Groot, Prakash Iyer, Nishi Kant, Victor Lortz, Jouni Malinen, Sarvar
   Patel, Tom Porcher, Michael Richardson, Stefan Schroeder, Uma
   Shankar, Jesse Walker, and Thomas Wieland for their contributions and
   critiques.  Special thanks to Max for proposing improvements to the
   MAC calculation.

   Thanks to Glen Zorn for reviewing this document and for providing
   very useful comments on the protocol.

   Thanks to Sarvar Patel for his review of the protocol [Patel-2003].

   Thanks to Bernard Aboba for reviewing this document for RFC 3748
   compliance.

   The identity privacy support is based on the identity privacy support
   of [EAP-SRP].  The attribute format is based on the extension format
   of Mobile IPv4 [RFC3344].

   This protocol has been partly developed in parallel with EAP-AKA
   [EAP-AKA], and hence this specification incorporates many ideas from
   Jari Arkko.

Top      Up      ToC       Page 77 
14.2.1.  Contributors' Addresses

   Nora Dabbous
   Gemplus
   34 rue Guynemer
   92447 Issy les Moulineaux
   France

   Phone: +33 1 4648 2000
   EMail: nora.dabbous@gemplus.com


   Jose Puthenkulam
   Intel Corporation
   2111 NE 25th Avenue, JF2-58
   Hillsboro, OR 97124
   USA

   Phone: +1 503 264 6121
   EMail: jose.p.puthenkulam@intel.com


   Prasanna Satarasinghe
   Transat Technologies
   180 State Street, Suite 240
   Southlake, TX 76092
   USA

   Phone: + 1 817 4814412
   EMail: prasannas@transat-tech.com


Next RFC Part