tech-invite   World Map     

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

RFC 4186

 
 
 

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

Part 3 of 5, p. 30 to 48
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 30 
5.  Fast Re-Authentication

5.1.  General

   In some environments, EAP authentication may be performed frequently.
   Because the EAP-SIM full authentication procedure makes use of the
   GSM SIM A3/A8 algorithms, and therefore requires 2 or 3 fresh
   triplets from the Authentication Centre, the full authentication
   procedure is not very well suited for frequent use.  Therefore,
   EAP-SIM includes a more inexpensive fast re-authentication procedure
   that does not make use of the SIM A3/A8 algorithms and does not need
   new triplets from the Authentication Centre.  Re-authentication can
   be performed in fewer roundtrips than the full authentication.

   Fast re-authentication is optional to implement for both the EAP-SIM
   server and peer.  On each EAP authentication, either one of the
   entities may also fall back on full authentication if it does not
   want to use fast re-authentication.

   Fast re-authentication is based on the keys derived on the preceding
   full authentication.  The same K_aut and K_encr keys that were used
   in full authentication are used to protect EAP-SIM packets and
   attributes, and the original Master Key from full authentication is
   used to generate a fresh Master Session Key, as specified in Section
   7.

   The fast re-authentication exchange makes use of an unsigned 16-bit
   counter, included in the AT_COUNTER attribute.  The counter has three
   goals: 1) it can be used to limit the number of successive
   reauthentication exchanges without full authentication 2) it
   contributes to the keying material, and 3) it protects the peer and
   the server from replays.  On full authentication, both the server and
   the peer initialize the counter to one.  The counter value of at
   least one is used on the first fast re-authentication.  On subsequent
   fast re-authentications, the counter MUST be greater than on any of
   the previous re-authentications.  For example, on the second fast
   re-authentication, the counter value is two or greater.  The
   AT_COUNTER attribute is encrypted.

   Both the peer and the EAP server maintain a copy of the counter.  The
   EAP server sends its counter value to the peer in the fast
   re-authentication request.  The peer MUST verify that its counter
   value is less than or equal to the value sent by the EAP server.

Top      Up      ToC       Page 31 
   The server includes an encrypted server random nonce (AT_NONCE_S) in
   the fast re-authentication request.  The AT_MAC attribute in the
   peer's response is calculated over NONCE_S to provide a
   challenge/response authentication scheme.  The NONCE_S also
   contributes to the new Master Session Key.

   Both the peer and the server SHOULD have an upper limit for the
   number of subsequent fast re-authentications allowed before a full
   authentication needs to be performed.  Because a 16-bit counter is
   used in fast re-authentication, the theoretical maximum number of
   re-authentications is reached when the counter value reaches FFFF
   hexadecimal.

   In order to use fast re-authentication, the peer and the EAP server
   need to store the following values: Master Key, latest counter value
   and the next fast re-authentication identity.  K_aut, K_encr may
   either be stored or derived again from MK.  The server may also need
   to store the permanent identity of the user.

5.2.  Comparison to UMTS AKA

   When analyzing the fast re-authentication exchange, it may be helpful
   to compare it with the UMTS Authentication and Key Agreement (AKA)
   exchange, which it resembles closely.  The counter corresponds to the
   UMTS AKA sequence number, NONCE_S corresponds to RAND, AT_MAC in
   EAP-Request/SIM/Re-authentication corresponds to AUTN, the AT_MAC in
   EAP-Response/SIM/Re-authentication corresponds to RES,
   AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter
   corresponds to the usage of the Anonymity Key.  Also, the key
   generation on fast re-authentication, with regard to random or fresh
   material, is similar to UMTS AKA -- the server generates the NONCE_S
   and counter values, and the peer only verifies that the counter value
   is fresh.

   It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER,
   or AT_COUNTER_TOO_SMALL attributes is not important to the security
   of the fast re-authentication exchange.

5.3.  Fast Re-authentication Identity

   The fast re-authentication procedure makes use of separate
   re-authentication user identities.  Pseudonyms and the permanent
   identity are reserved for full authentication only.  If a
   re-authentication identity is lost and the network does not recognize
   it, the EAP server can fall back on full authentication.

Top      Up      ToC       Page 32 
   If the EAP server supports fast re-authentication, it MAY include the
   skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of
   EAP-Request/SIM/Challenge message (Section 9.3).  This attribute
   contains a new fast re-authentication identity for the next fast
   re-authentication.  The attribute also works as a capability flag
   that, indicating that the server supports fast re-authentication, and
   that the server wants to continue using fast re-authentication within
   the current context.  The peer MAY ignore this attribute, in which
   case it MUST use full authentication next time.  If the peer wants to
   use re-authentication, it uses this fast re-authentication identity
   on next authentication.  Even if the peer has a fast
   re-authentication identity, the peer MAY discard the fast
   re-authentication identity and use a pseudonym or the permanent
   identity instead, in which case full authentication MUST be
   performed.  If the EAP server does not include the AT_NEXT_REAUTH_ID
   in the encrypted data of EAP-Request/SIM/Challenge or
   EAP-Request/SIM/ Re-authentication, then the peer MUST discard its
   current fast re-authentication state information and perform a full
   authentication next time.

   In environments where a realm portion is needed in the peer identity,
   the fast re-authentication identity received in AT_NEXT_REAUTH_ID
   MUST contain both a username portion and a realm portion, as per the
   NAI format.  The EAP Server can choose an appropriate realm part in
   order to have the AAA infrastructure route subsequent fast
   re-authentication related requests to the same AAA server.  For
   example, the realm part MAY include a portion that is specific to the
   AAA server.  Hence, it is sufficient to store the context required
   for fast re-authentication in the AAA server that performed the full
   authentication.

   The peer MAY use the fast re-authentication identity in the
   EAP-Response/Identity packet or, in response to the server's
   AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication
   identity in the AT_IDENTITY attribute of the EAP-Response/SIM/Start
   packet.

   The peer MUST NOT modify the username portion of the fast
   re-authentication identity, but the peer MAY modify the realm portion
   or replace it with another realm portion.  The peer might need to
   modify the realm in order to influence the AAA routing, for example,
   to make sure that the correct server is reached.  It should be noted
   that sharing the same fast re-authentication key among several
   servers may have security risks, so changing the realm portion of the
   NAI in order to change the EAP server is not desirable.

Top      Up      ToC       Page 33 
   Even if the peer uses a fast re-authentication identity, the server
   may want to fall back on full authentication, for example because the
   server does not recognize the fast re-authentication identity or does
   not want to use fast re-authentication.  In this case, the server
   starts the full authentication procedure by issuing an
   EAP-Request/SIM/Start packet.  This packet always starts a full
   authentication sequence if it does not include the AT_ANY_ID_REQ
   attribute.  If the server was not able to recover the peer's identity
   from the fast re-authentication identity, the server includes either
   the AT_FULLAUTH_ID_REQ or the AT_PERMANENT_ID_REQ attribute in this
   EAP request.

5.4.  Fast Re-authentication Procedure

   Figure 8 illustrates the fast re-authentication procedure.  In this
   example, the optional protected success indication is not used.
   Encrypted attributes are denoted with '*'.  The peer uses its
   re-authentication identity in the EAP-Response/Identity packet.  As
   discussed above, an alternative way to communicate the
   re-authentication identity to the server is for the peer to use the
   AT_IDENTITY attribute in the EAP-Response/SIM/Start message.  This
   latter case is not illustrated in the figure below, and it is only
   possible when the server requests that the peer send its identity by
   including the AT_ANY_ID_REQ attribute in the EAP-Request/SIM/Start
   packet.

   If the server recognizes the identity as a valid fast
   re-authentication identity, and if the server agrees to use fast
   re-authentication, then the server sends the EAP-Request/SIM/
   Re-authentication packet to the peer.  This packet MUST include the
   encrypted AT_COUNTER attribute, with a fresh counter value, the
   encrypted AT_NONCE_S attribute that contains a random number chosen
   by the server, the AT_ENCR_DATA and the AT_IV attributes used for
   encryption, and the AT_MAC attribute that contains a message
   authentication code over the packet.  The packet MAY also include an
   encrypted AT_NEXT_REAUTH_ID attribute that contains the next fast
   re-authentication identity.

   Fast re-authentication identities are one-time identities.  If the
   peer does not receive a new fast re-authentication identity, it MUST
   use either the permanent identity or a pseudonym identity on the next
   authentication to initiate full authentication.

   The peer verifies that AT_MAC is correct, and that the counter value
   is fresh (greater than any previously used value).  The peer MAY save
   the next fast re-authentication identity from the encrypted
   AT_NEXT_REAUTH_ID for next time.  If all checks are successful, the
   peer responds with the EAP-Response/SIM/Re-authentication packet,

Top      Up      ToC       Page 34 
   including the AT_COUNTER attribute with the same counter value and
   AT_MAC attribute.

   The server verifies the AT_MAC attribute and also verifies that the
   counter value is the same that it used in the EAP-Request/SIM/
   Re-authentication packet.  If these checks are successful, the
   re-authentication has succeeded and the server sends the EAP-Success
   packet to the peer.

   If protected success indications (Section 6.2) were used, the
   EAP-Success packet would be preceded by an EAP-SIM notification
   round.

Top      Up      ToC       Page 35 
       Peer                                             Authenticator
          |                                                       |
          |                               EAP-Request/Identity    |
          |<------------------------------------------------------|
          |                                                       |
          | EAP-Response/Identity                                 |
          | (Includes a fast re-authentication identity)          |
          |------------------------------------------------------>|
          |                                                       |
          |                          +--------------------------------+
          |                          | Server recognizes the identity |
          |                          | and agrees to use fast         |
          |                          | re-authentication              |
          |                          +--------------------------------+
          |                                                       |
          :                                                       :
          :                                                       :
          :                                                       :
          :                                                       :
          |  EAP-Request/SIM/Re-authentication                    |
          |  (AT_IV, AT_ENCR_DATA, *AT_COUNTER,                   |
          |   *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC)            |
          |<------------------------------------------------------|
          |                                                       |
     +-----------------------------------------------+            |
     | Peer verifies AT_MAC and the freshness of     |            |
     | the counter. Peer MAY store the new fast re-  |            |
     | authentication identity for next re-auth.     |            |
     +-----------------------------------------------+            |
          |                                                       |
          | EAP-Response/SIM/Re-authentication                    |
          | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value,    |
          |  AT_MAC)                                              |
          |------------------------------------------------------>|
          |                          +--------------------------------+
          |                          | Server verifies AT_MAC and     |
          |                          | the counter                    |
          |                          +--------------------------------+
          |                                                       |
          |                                          EAP-Success  |
          |<------------------------------------------------------|
          |                                                       |

                    Figure 8: Fast Re-authentication

Top      Up      ToC       Page 36 
5.5.  Fast Re-authentication Procedure when Counter Is Too Small

   If the peer does not accept the counter value of EAP-Request/SIM/
   Re-authentication, it indicates the counter synchronization problem
   by including the encrypted AT_COUNTER_TOO_SMALL in EAP-Response/SIM/
   Re-authentication.  The server responds with EAP-Request/SIM/Start to
   initiate a normal full authentication procedure.  This is illustrated
   in Figure 9.  Encrypted attributes are denoted with '*'.

       Peer                                             Authenticator
          |          EAP-Request/SIM/Start                        |
          |          (AT_ANY_ID_REQ, AT_VERSION_LIST)             |
          |<------------------------------------------------------|
          |                                                       |
          | EAP-Response/SIM/Start                                |
          | (AT_IDENTITY)                                         |
          | (Includes a fast re-authentication identity)          |
          |------------------------------------------------------>|
          |                                                       |
          |  EAP-Request/SIM/Re-authentication                    |
          |  (AT_IV, AT_ENCR_DATA, *AT_COUNTER,                   |
          |   *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC)            |
          |<------------------------------------------------------|
     +-----------------------------------------------+            |
     | AT_MAC is valid but the counter is not fresh. |            |
     +-----------------------------------------------+            |
          |                                                       |
          | EAP-Response/SIM/Re-authentication                    |
          | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL,          |
          |  *AT_COUNTER, AT_MAC)                                 |
          |------------------------------------------------------>|
          |            +----------------------------------------------+
          |            | Server verifies AT_MAC but detects           |
          |            | That peer has included AT_COUNTER_TOO_SMALL  |
          |            +----------------------------------------------+
          |                                                       |
          |                        EAP-Request/SIM/Start          |
          |                        (AT_VERSION_LIST)              |
          |<------------------------------------------------------|
     +---------------------------------------------------------------+
     |                Normal full authentication follows.            |
     +---------------------------------------------------------------+
          |                                                       |

          Figure 9: Fast Re-authentication, counter is not fresh

Top      Up      ToC       Page 37 
   In the figure above, the first three messages are similar to the
   basic fast re-authentication case.  When the peer detects that the
   counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
   attribute in EAP-Response/SIM/Re-authentication.  This attribute
   doesn't contain any data, but it is a request for the server to
   initiate full authentication.  In this case, the peer MUST ignore the
   contents of the server's AT_NEXT_REAUTH_ID attribute.

   On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and
   verifies that AT_COUNTER contains the same counter value as in the
   EAP-Request/SIM/Re-authentication packet.  If not, the server
   terminates the authentication exchange by sending the
   EAP-Request/SIM/Notification with AT_NOTIFICATION code "General
   failure" (16384).  If all checks on the packet are successful, the
   server transmits a new EAP-Request/SIM/Start packet and the full
   authentication procedure is performed as usual.  Since the server
   already knows the subscriber identity, it MUST NOT include
   AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_PERMANENT_ID_REQ in the
   EAP-Request/SIM/Start.

   It should be noted that in this case, peer identity is only
   transmitted in the AT_IDENTITY attribute at the beginning of the
   whole EAP exchange.  The fast re-authentication identity used in this
   AT_IDENTITY attribute will be used in key derivation (see Section 7).

6.  EAP-SIM Notifications

6.1.  General

   EAP-SIM does not prohibit the use of the EAP Notifications as
   specified in [RFC3748].  EAP Notifications can be used at any time in
   the EAP-SIM exchange.  It should be noted that EAP-SIM does not
   protect EAP Notifications.  EAP-SIM also specifies method-specific
   EAP-SIM notifications that are protected in some cases.

   The EAP server can use EAP-SIM notifications to convey notifications
   and result indications (Section 6.2) to the peer.

   The server MUST use notifications in cases discussed in
   Section 6.3.2.  When the EAP server issues an
   EAP-Request/SIM/Notification packet to the peer, the peer MUST
   process the notification packet.  The peer MAY show a notification
   message to the user and the peer MUST respond to the EAP server with
   an EAP-Response/SIM/Notification packet, even if the peer did not
   recognize the notification code.

Top      Up      ToC       Page 38 
   An EAP-SIM full authentication exchange or a fast re-authentication
   exchange MUST NOT include more than one EAP-SIM notification round.

   The notification code is a 16-bit number.  The most significant bit
   is called the Success bit (S bit).  The S bit specifies whether the
   notification implies failure.  The code values with the S bit set to
   zero (code values 0...32767) are used on unsuccessful cases.  The
   receipt of a notification code from this range implies a failed EAP
   exchange, so the peer can use the notification as a failure
   indication.  After receiving the EAP-Response/SIM/Notification for
   these notification codes, the server MUST send the EAP-Failure
   packet.

   The receipt of a notification code with the S bit set to one (values
   32768...65536) does not imply failure.  Notification code "Success"
   (32768) has been reserved as a general notification code to indicate
   successful authentication.

   The second most significant bit of the notification code is called
   the Phase bit (P bit).  It specifies at which phase of the EAP-SIM
   exchange the notification can be used.  If the P bit is set to zero,
   the notification can only be used after a successful
   EAP/SIM/Challenge round in full authentication or a successful
   EAP/SIM/Re-authentication round in reauthentication.  A
   re-authentication round is considered successful only if the peer has
   successfully verified AT_MAC and AT_COUNTER attributes, and does not
   include the AT_COUNTER_TOO_SMALL attribute in
   EAP-Response/SIM/Re-authentication.

   If the P bit is set to one, the notification can only by used before
   the EAP/SIM/Challenge round in full authentication, or before the
   EAP/SIM/Re-authentication round in reauthentication.  These
   notifications can only be used to indicate various failure cases.  In
   other words, if the P bit is set to one, then the S bit MUST be set
   to zero.

   Section 9.8 and Section 9.9 specify what other attributes must be
   included in the notification packets.

   Some of the notification codes are authorization related and, hence,
   are not usually considered part of the responsibility of an EAP
   method.  However, they are included as part of EAP-SIM because there
   are currently no other ways to convey this information to the user in
   a localizable way, and the information is potentially useful for the
   user.  An EAP-SIM server implementation may decide never to send
   these EAP-SIM notifications.

Top      Up      ToC       Page 39 
6.2.  Result Indications

   As discussed in Section 6.3, the server and the peer use explicit
   error messages in all error cases.  If the server detects an error
   after successful authentication, the server uses an EAP-SIM
   notification to indicate failure to the peer.  In this case, the
   result indication is integrity and replay protected.

   By sending an EAP-Response/SIM/Challenge packet or an
   EAP-Response/SIM/Re-authentication packet (without
   AT_COUNTER_TOO_SMALL), the peer indicates that it has successfully
   authenticated the server and that the peer's local policy accepts the
   EAP exchange.  In other words, these packets are implicit success
   indications from the peer to the server.

   EAP-SIM also supports optional protected success indications from the
   server to the peer.  If the EAP server wants to use protected success
   indications, it includes the AT_RESULT_IND attribute in the
   EAP-Request/SIM/Challenge or the EAP-Request/SIM/Re-authentication
   packet.  This attribute indicates that the EAP server would like to
   use result indications in both successful and unsuccessful cases.  If
   the peer also wants this, the peer includes AT_RESULT_IND in
   EAP-Response/SIM/Challenge or EAP-Response/SIM/Re-authentication.
   The peer MUST NOT include AT_RESULT_IND if it did not receive
   AT_RESULT_IND from the server.  If both the peer and the server used
   AT_RESULT_IND, then the EAP exchange is not complete yet, but an
   EAP-SIM notification round will follow.  The following EAP-SIM
   notification may indicate either failure or success.

   Success indications with the AT_NOTIFICATION code "Success" (32768)
   can only be used if both the server and the peer indicate they want
   to use them with AT_RESULT_IND.  If the server did not include
   AT_RESULT_IND in the EAP-Request/SIM/Challenge or
   EAP-Request/SIM/Re-authentication packet, or if the peer did not
   include AT_RESULT_IND in the corresponding response packet, then the
   server MUST NOT use protected success indications.

   Because the server uses the AT_NOTIFICATION code "Success" (32768) to
   indicate that the EAP exchange has completed successfully, the EAP
   exchange cannot fail when the server processes the EAP-SIM response
   to this notification.  Hence, the server MUST ignore the contents of
   the EAP-SIM response it receives from the
   EAP-Request/SIM/Notification with this code.  Regardless of the
   contents of the EAP-SIM response, the server MUST send EAP-Success as
   the next packet.

Top      Up      ToC       Page 40 
6.3.  Error Cases

   This section specifies the operation of the peer and the server in
   error cases.  The subsections below require the EAP-SIM peer and
   server to send an error packet (EAP-Response/SIM/Client-Error from
   the peer or EAP-Request/SIM/Notification from the server) in error
   cases.  However, implementations SHOULD NOT rely upon the correct
   error reporting behavior of the peer, authenticator, or the server.
   It is possible for error and other messages to be lost in transit or
   for a malicious participant to attempt to consume resources by not
   issuing error messages.  Both the peer and the EAP server SHOULD have
   a mechanism to clean up state, even if an error message or
   EAP-Success is not received after a timeout period.

6.3.1.  Peer Operation

   In general, if an EAP-SIM peer detects an error in a received EAP-SIM
   packet, the EAP-SIM implementation responds with the
   EAP-Response/SIM/Client-Error packet.  In response to the
   EAP-Response/SIM/Client-Error, the EAP server MUST issue the
   EAP-Failure packet and the authentication exchange terminates.

   By default, the peer uses the client error code 0, "unable to process
   packet".  This error code is used in the following cases:

   o  EAP exchange is not acceptable according to the peer's local
      policy.

   o  the peer is not able to parse the EAP request, i.e., the EAP
      request is malformed.

   o  the peer encountered a malformed attribute.

   o  wrong attribute types or duplicate attributes have been included
      in the EAP request.

   o  a mandatory attribute is missing.

   o  unrecognized, non-skippable attribute.

   o  unrecognized or unexpected EAP-SIM Subtype in the EAP request.

   o  A RAND challenge repeated in AT_RAND.

   o  invalid AT_MAC.  The peer SHOULD log this event.

   o  invalid pad bytes in AT_PADDING.

Top      Up      ToC       Page 41 
   o  the peer does not want to process AT_PERMANENT_ID_REQ.

   Separate error codes have been defined for the following error cases
   in Section 10.19:

   As specified in Section 4.1, when processing the AT_VERSION_LIST
   attribute, which lists the EAP-SIM versions supported by the server,
   if the attribute does not include a version that is implemented by
   the peer and allowed in the peer's security policy, then the peer
   MUST send the EAP-Response/SIM/Client-Error packet with the error
   code "unsupported version".

   If the number of RAND challenges is smaller than what is required by
   peer's local policy when processing the AT_RAND attribute, the peer
   MUST send the EAP-Response/SIM/Client-Error packet with the error
   code "insufficient number of challenges".

   If the peer believes that the RAND challenges included in AT_RAND are
   not fresh e.g., because it is capable of remembering some previously
   used RANDs, the peer MUST send the EAP-Response/SIM/Client-Error
   packet with the error code "RANDs are not fresh".

6.3.2.  Server Operation

   If an EAP-SIM server detects an error in a received EAP-SIM response,
   the server MUST issue the EAP-Request/SIM/Notification packet with an
   AT_NOTIFICATION code that implies failure.  By default, the server
   uses one of the general failure codes ("General failure after
   authentication" (0), or "General failure" (16384)).  The choice
   between these two codes depends on the phase of the EAP-SIM exchange,
   see Section 6.  When the server issues an EAP-
   Request/SIM/Notification that implies failure, the error cases
   include the following:

   o  the server is not able to parse the peer's EAP response

   o  the server encounters a malformed attribute, a non-recognized
      non-skippable attribute, or a duplicate attribute

   o  a mandatory attribute is missing or an invalid attribute was
      included

   o  unrecognized or unexpected EAP-SIM Subtype in the EAP Response

   o  invalid AT_MAC.  The server SHOULD log this event.

   o  invalid AT_COUNTER

Top      Up      ToC       Page 42 
6.3.3.  EAP-Failure

   The EAP-SIM server sends EAP-Failure in two cases:

   1) In response to an EAP-Response/SIM/Client-Error packet the server
      has received from the peer, or

   2) Following an EAP-SIM notification round, when the AT_NOTIFICATION
      code implies failure.

   The EAP-SIM server MUST NOT send EAP-Failure in cases other than
   these two.  However, it should be noted that even though the EAP-SIM
   server would not send an EAP-Failure, an authorization decision that
   happens outside EAP-SIM, such as in the AAA server or in an
   intermediate AAA proxy, may result in a failed exchange.

   The peer MUST accept the EAP-Failure packet in case 1) and case 2),
   above.  The peer SHOULD silently discard the EAP-Failure packet in
   other cases.

6.3.4.  EAP-Success

   On full authentication, the server can only send EAP-Success after
   the EAP/SIM/Challenge round.  The peer MUST silently discard any
   EAP-Success packets if they are received before the peer has
   successfully authenticated the server and sent the
   EAP-Response/SIM/Challenge packet.

   If the peer did not indicate that it wants to use protected success
   indications with AT_RESULT_IND (as discussed in Section 6.2) on full
   authentication, then the peer MUST accept EAP-Success after a
   successful EAP/SIM/Challenge round.

   If the peer indicated that it wants to use protected success
   indications with AT_RESULT_IND (as discussed in Section 6.2), then
   the peer MUST NOT accept EAP-Success after a successful
   EAP/SIM/Challenge round.  In this case, the peer MUST only accept
   EAP-Success after receiving an EAP-SIM Notification with the
   AT_NOTIFICATION code "Success" (32768).

   On fast re-authentication, EAP-Success can only be sent after the
   EAP/SIM/Re-authentication round.  The peer MUST silently discard any
   EAP-Success packets if they are received before the peer has
   successfully authenticated the server and sent the
   EAP-Response/SIM/Re-authentication packet.

   If the peer did not indicate that it wants to use protected success
   indications with AT_RESULT_IND (as discussed in Section 6.2) on fast

Top      Up      ToC       Page 43 
   re-authentication, then the peer MUST accept EAP-Success after a
   successful EAP/SIM/Re-authentication round.

   If the peer indicated that it wants to use protected success
   indications with AT_RESULT_IND (as discussed in Section 6.2), then
   the peer MUST NOT accept EAP-Success after a successful EAP/SIM/Re-
   authentication round.  In this case, the peer MUST only accept
   EAP-Success after receiving an EAP-SIM Notification with the
   AT_NOTIFICATION code "Success" (32768).

   If the peer receives an EAP-SIM notification (Section 6) that
   indicates failure, then the peer MUST no longer accept the
   EAP-Success packet, even if the server authentication was
   successfully completed.

7.  Key Generation

   This section specifies how keying material is generated.

   On EAP-SIM full authentication, a Master Key (MK) is derived from the
   underlying GSM authentication values (Kc keys), the NONCE_MT, and
   other relevant context as follows.

   MK = SHA1(Identity|n*Kc| NONCE_MT| Version List| Selected Version)

   In the formula above, the "|" character denotes concatenation.
   "Identity" denotes the peer identity string without any terminating
   null characters.  It is the identity from the last AT_IDENTITY
   attribute sent by the peer in this exchange, or, if AT_IDENTITY was
   not used, it is the identity from the EAP-Response/Identity packet.
   The identity string is included as-is, without any changes.  As
   discussed in Section 4.2.2.2, relying on EAP-Response/Identity for
   conveying the EAP-SIM peer identity is discouraged, and the server
   SHOULD use the EAP-SIM method-specific identity attributes.

   The notation n*Kc in the formula above denotes the n Kc values
   concatenated.  The Kc keys are used in the same order as the RAND
   challenges in AT_RAND attribute.  NONCE_MT denotes the NONCE_MT value
   (not the AT_NONCE_MT attribute, but only the nonce value).  The
   Version List includes the 2-byte-supported version numbers from
   AT_VERSION_LIST, in the same order as in the attribute.  The Selected
   Version is the 2-byte selected version from AT_SELECTED_VERSION.
   Network byte order is used, just as in the attributes.  The hash
   function SHA-1 is specified in [SHA-1].  If several EAP/SIM/Start
   roundtrips are used in an EAP-SIM exchange, then the NONCE_MT,
   Version List and Selected version from the last EAP/SIM/Start round
   are used, and the previous EAP/SIM/Start rounds are ignored.

Top      Up      ToC       Page 44 
   The Master Key is fed into a Pseudo-Random number Function (PRF)
   which generates separate Transient EAP Keys (TEKs) for protecting
   EAP-SIM packets, as well as a Master Session Key (MSK) for link layer
   security, and an Extended Master Session Key (EMSK) for other
   purposes.  On fast re-authentication, the same TEKs MUST be used for
   protecting EAP packets, but a new MSK and a new EMSK MUST be derived
   from the original MK and from new values exchanged in the fast
   re-authentication.

   EAP-SIM requires two TEKs for its own purposes; the authentication
   key K_aut is to be used with the AT_MAC attribute, and the encryption
   key K_encr is to be used with the AT_ENCR_DATA attribute.  The same
   K_aut and K_encr keys are used in full authentication and subsequent
   fast re-authentications.

   Key derivation is based on the random number generation specified in
   NIST Federal Information Processing Standards (FIPS) Publication
   186-2 [PRF].  The pseudo-random number generator is specified in the
   change notice 1 (2001 October 5) of [PRF] (Algorithm 1).  As
   specified in the change notice (page 74), when Algorithm 1 is used as
   a general-purpose pseudo-random number generator, the "mod q" term in
   step 3.3 is omitted.  The function G used in the algorithm is
   constructed via the Secure Hash Standard, as specified in Appendix
   3.3 of the standard.  It should be noted that the function G is very
   similar to SHA-1, but the message padding is different.  Please refer
   to [PRF] for full details.  For convenience, the random number
   algorithm with the correct modification is cited in Appendix B.

   160-bit XKEY and XVAL values are used, so b = 160.  On each full
   authentication, the Master Key is used as the initial secret seed-key
   XKEY.  The optional user input values (XSEED_j) in step 3.1 are set
   to zero.

   On full authentication, the resulting 320-bit random numbers (x_0,
   x_1, ..., x_m-1) are concatenated and partitioned into suitable-sized
   chunks and used as keys in the following order: K_encr (128 bits),
   K_aut (128 bits), Master Session Key (64 bytes), Extended Master
   Session Key (64 bytes).

   On fast re-authentication, the same pseudo-random number generator
   can be used to generate a new Master Session Key and a new Extended
   Master Session Key.  The seed value XKEY' is calculated as follows:

   XKEY' = SHA1(Identity|counter|NONCE_S| MK)

   In the formula above, the Identity denotes the fast re-authentication
   identity, without any terminating null characters, from the
   AT_IDENTITY attribute of the EAP-Response/SIM/Start packet, or, if

Top      Up      ToC       Page 45 
   EAP-Response/SIM/Start was not used on fast re-authentication, it
   denotes the identity string from the EAP-Response/Identity packet.
   The counter denotes the counter value from the AT_COUNTER attribute
   used in the EAP-Response/SIM/Re-authentication packet.  The counter
   is used in network byte order.  NONCE_S denotes the 16-byte NONCE_S
   value from the AT_NONCE_S attribute used in the
   EAP-Request/SIM/Re-authentication packet.  The MK is the Master Key
   derived on the preceding full authentication.

   On fast re-authentication, the pseudo-random number generator is run
   with the new seed value XKEY', and the resulting 320-bit random
   numbers (x_0, x_1, ..., x_m-1) are concatenated and partitioned into
   two 64-byte chunks and used as the new 64-byte Master Session Key and
   the new 64-byte Extended Master Session Key.  Note that because
   K_encr and K_aut are not derived on fast re-authentication, the
   Master Session Key and the Extended Master Session key are obtained
   from the beginning of the key stream (x_0, x_1, ...).

   The first 32 bytes of the MSK can be used as the Pairwise Master Key
   (PMK) for IEEE 802.11i.

   When the RADIUS attributes specified in [RFC2548] are used to
   transport keying material, then the first 32 bytes of the MSK
   correspond to MS-MPPE-RECV-KEY and the second 32 bytes to
   MS-MPPE-SEND-KEY.  In this case, only 64 bytes of keying material
   (the MSK) are used.

   When generating the initial Master Key, the hash function is used as
   a mixing function to combine several session keys (Kc's) generated by
   the GSM authentication procedure and the random number NONCE_MT into
   a single session key.  There are several reasons for this.  The
   current GSM session keys are, at most, 64 bits, so two or more of
   them are needed to generate a longer key.  By using a one-way
   function to combine the keys, we are assured that, even if an
   attacker managed to learn one of the EAP-SIM session keys, it
   wouldn't help him in learning the original GSM Kc's.  In addition,
   since we include the random number NONCE_MT in the calculation, the
   peer is able to verify that the EAP-SIM packets it receives from the
   network are fresh and not replays (also see Section 11).

8.  Message Format and Protocol Extensibility

8.1.  Message Format

   As specified in [RFC3748], EAP packets begin with the Code,
   Identifiers, Length, and Type fields, which are followed by EAP-
   method-specific Type-Data.  The Code field in the EAP header is set
   to 1 for EAP requests, and to 2 for EAP Responses.  The usage of the

Top      Up      ToC       Page 46 
   Length and Identifier fields in the EAP header are also specified in
   [RFC3748].  In EAP-SIM, the Type field is set to 18.

   In EAP-SIM, the Type-Data begins with an EAP-SIM header that consists
   of a 1-octet Subtype field and a 2-octet reserved field.  The Subtype
   values used in EAP-SIM are defined in the IANA considerations section
   of the EAP-AKA specification [EAP-AKA].  The formats of the EAP
   header and the EAP-SIM header are shown below.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Code      |  Identifier   |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Subtype    |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The rest of the Type-Data that immediately follows the EAP-SIM header
   consists of attributes that are encoded in Type, Length, Value
   format.  The figure below shows the generic format of an attribute.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type     |    Length     |  Value...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Attribute Type

         Indicates the particular type of attribute.  The attribute type
         values are listed in the IANA considerations section of the
         EAP-AKA specification [EAP-AKA].

   Length

         Indicates the length of this attribute in multiples of four
         bytes.  The maximum length of an attribute is 1024 bytes.  The
         length includes the Attribute Type and Length bytes.

   Value

         The particular data associated with this attribute.  This field
         is always included and it may be two or more bytes in length.
         The type and length fields determine the format and length
         of the value field.

Top      Up      ToC       Page 47 
   Attributes numbered within the range 0 through 127 are called
   non-skippable attributes.  When an EAP-SIM peer encounters a
   non-skippable attribute that the peer does not recognize, the peer
   MUST send the EAP-Response/SIM/Client-Error packet, which terminates
   the authentication exchange.  If an EAP-SIM server encounters a
   non-skippable attribute that the server does not recognize, then the
   server sends the EAP-Request/SIM/Notification packet with an
   AT_NOTIFICATION code, which implies general failure ("General failure
   after authentication" (0), or "General failure" (16384), depending on
   the phase of the exchange), which terminates the authentication
   exchange.

   Attributes within the range of 128 through 255 are called skippable
   attributes.  When a skippable attribute is encountered and is not
   recognized, it is ignored.  The rest of the attributes and message
   data MUST still be processed.  The Length field of the attribute is
   used to skip the attribute value in searching for the next attribute.

   Unless otherwise specified, the order of the attributes in an EAP-SIM
   message is insignificant and an EAP-SIM implementation should not
   assume a certain order to be used.

   Attributes can be encapsulated within other attributes.  In other
   words, the value field of an attribute type can be specified to
   contain other attributes.

8.2.  Protocol Extensibility

   EAP-SIM can be extended by specifying new attribute types.  If
   skippable attributes are used, it is possible to extend the protocol
   without breaking old implementations.

   However, any new attributes added to the EAP-Request/SIM/Start or
   EAP-Response/SIM/Start packets would not be integrity-protected.
   Therefore, these messages MUST NOT be extended in the current version
   of EAP-SIM.  If the list of supported EAP-SIM versions in the
   AT_VERSION_LIST does not include versions other than 1, then the
   server MUST NOT include attributes other than those specified in this
   document in the EAP-Request/SIM/Start message.  Note that future
   versions of this protocol might specify new attributes for
   EAP-Request/SIM/Start and still support version 1 of the protocol.
   In this case, the server might send an EAP-Request/SIM/Start message
   that includes new attributes and indicates support for protocol
   version 1 and other versions in the AT_VERSION_LIST attribute.  If
   the peer selects version 1, then the peer MUST ignore any other
   attributes included in EAP-Request/SIM/Start, other than those
   specified in this document.  If the selected EAP-SIM version in
   peer's AT_SELECTED_VERSION is 1, then the peer MUST NOT include other

Top      Up      ToC       Page 48 
   attributes aside from those specified in this document in the
   EAP-Response/SIM/Start message.

   When specifying new attributes, it should be noted that EAP-SIM does
   not support message fragmentation.  Hence, the sizes of the new
   extensions MUST be limited so that the maximum transfer unit (MTU) of
   the underlying lower layer is not exceeded.  According to [RFC3748],
   lower layers must provide an EAP MTU of 1020 bytes or greater, so any
   extensions to EAP-SIM SHOULD NOT exceed the EAP MTU of 1020 bytes.

   Because EAP-SIM supports version negotiation, new versions of the
   protocol can also be specified by using a new version number.



(page 48 continued on part 4)

Next RFC Part