rcf4186.txt

RCF4186 about EAP-SIM

   EAP-Response/SIM/Start message, and the server does not indicate any
   preferred type for the identity.  This is done in other cases, such
   as when the server ignores a received EAP-Response/Identity, the
   server does not have any identity, or the server does not recognize
   the format of a received identity.

4.2.5.  Processing of EAP-Request/SIM/Start by the Peer

   Upon receipt of an EAP-Request/SIM/Start message, the peer MUST
   perform the following steps.

   If the EAP-Request/SIM/Start does not include an identity request
   attribute, then the peer responds with EAP-Response/SIM/Start without
   AT_IDENTITY.  The peer includes the AT_SELECTED_VERSION and
   AT_NONCE_MT attributes, because the exchange is a full authentication
   exchange.

   If the EAP-Request/SIM/Start includes AT_PERMANENT_ID_REQ, and if the
   peer does not have a pseudonym available, then the peer MUST respond
   with EAP-Response/SIM/Start and include the permanent identity in



Haverinen & Salowey          Informational                     [Page 20]

RFC 4186                 EAP-SIM Authentication             January 2006


   AT_IDENTITY.  If the peer has a pseudonym available, then the peer
   MAY refuse to send the permanent identity; hence, in this case the
   peer MUST either respond with EAP-Response/SIM/Start and include the
   permanent identity in AT_IDENTITY or respond with EAP-Response/SIM/
   Client-Error packet with the code "unable to process packet".

   If the EAP-Request/SIM/Start includes AT_FULL_AUTH_ID_REQ, and if the
   peer has a pseudonym available, then the peer SHOULD respond with
   EAP-Response/SIM/Start and include the pseudonym identity in
   AT_IDENTITY.  If the peer does not have a pseudonym when it receives
   this message, then the peer MUST respond with EAP-Response/SIM/Start
   and include the permanent identity in AT_IDENTITY.  The Peer MUST NOT
   use a re-authentication identity in the AT_IDENTITY attribute.

   If the EAP-Request/SIM/Start includes AT_ANY_ID_REQ, and if the peer
   has maintained fast re-authentication state information and the peer
   wants to use fast re-authentication, then the peer responds with
   EAP-Response/SIM/Start and includes the fast re-authentication
   identity in AT_IDENTITY.  Else, if the peer has a pseudonym identity
   available, then the peer responds with EAP-Response/SIM/Start and
   includes the pseudonym identity in AT_IDENTITY.  Else, the peer
   responds with EAP-Response/SIM/Start and includes the permanent
   identity in AT_IDENTITY.

   An EAP-SIM exchange may include several EAP/SIM/Start rounds.  The
   server may issue a second EAP-Request/SIM/Start if it was not able to
   recognize the identity that the peer used in the previous AT_IDENTITY
   attribute.  At most, three EAP/SIM/Start rounds can be used, so the
   peer MUST NOT respond to more than three EAP-Request/SIM/Start
   messages within an EAP exchange.  The peer MUST verify that the
   sequence of EAP-Request/SIM/Start packets that the peer receives
   comply with the sequencing rules defined in this document.  That is,
   AT_ANY_ID_REQ can only be used in the first EAP-Request/SIM/Start; in
   other words, AT_ANY_ID_REQ MUST NOT be used in the second or third
   EAP-Request/SIM/Start.  AT_FULLAUTH_ID_REQ MUST NOT be used if the
   previous EAP-Request/SIM/Start included AT_PERMANENT_ID_REQ.  The
   peer operation, in cases when it receives an unexpected attribute or
   an unexpected message, is specified in Section 6.3.1.

4.2.6.  Attacks Against Identity Privacy

   The section above specifies two possible ways the peer can operate
   upon receipt of AT_PERMANENT_ID_REQ.  This is because a received
   AT_PERMANENT_ID_REQ does not necessarily originate from the valid
   network, but an active attacker may transmit an EAP-Request/SIM/
   Start packet with an AT_PERMANENT_ID_REQ attribute to the peer, in an
   effort to find out the true identity of the user.  If the peer does
   not want to reveal its permanent identity, then the peer sends the



Haverinen & Salowey          Informational                     [Page 21]

RFC 4186                 EAP-SIM Authentication             January 2006


   EAP-Response/SIM/Client-Error packet with the error code "unable to
   process packet", and the authentication exchange terminates.

   Basically, there are two different policies that the peer can employ
   with regard to AT_PERMANENT_ID_REQ.  A "conservative" peer assumes
   that the network is able to maintain pseudonyms robustly.  Therefore,
   if a conservative peer has a pseudonym username, the peer responds
   with EAP-Response/SIM/Client-Error to the EAP packet with
   AT_PERMANENT_ID_REQ, because the peer believes that the valid network
   is able to map the pseudonym identity to the peer's permanent
   identity.  (Alternatively, the conservative peer may accept
   AT_PERMANENT_ID_REQ in certain circumstances, for example, if the
   pseudonym was received a long time ago.)  The benefit of this policy
   is that it protects the peer against active attacks on anonymity.  On
   the other hand, a "liberal" peer always accepts the
   AT_PERMANENT_ID_REQ and responds with the permanent identity.  The
   benefit of this policy is that it works even if the valid network
   sometimes loses pseudonyms and is not able to map them to the
   permanent identity.

4.2.7.  Processing of AT_IDENTITY by the Server

   When the server receives an EAP-Response/SIM/Start message with the
   AT_IDENTITY (in response to the server's identity requesting
   attribute), the server MUST operate as follows.

   If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does
   not contain a valid permanent identity, then the server sends
   EAP-Request/SIM/Notification with AT_NOTIFICATION code "General
   failure" (16384), and the EAP exchange terminates.  If the server
   recognizes the permanent identity and is able to continue, then the
   server proceeds with full authentication by sending EAP-Request/SIM/
   Challenge.

   If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a
   valid permanent identity or a pseudonym identity that the server can
   map to a valid permanent identity, then the server proceeds with full
   authentication by sending EAP-Request/SIM/Challenge.  If AT_IDENTITY
   contains a pseudonym identity that the server is not able to map to a
   valid permanent identity, or an identity that the server is not able
   to recognize or classify, then the server sends EAP-Request/SIM/Start
   with AT_PERMANENT_ID_REQ.

   If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a
   valid permanent identity or a pseudonym identity that the server can
   map to a valid permanent identity, then the server proceeds with full
   authentication by sending EAP-Request/SIM/Challenge.




Haverinen & Salowey          Informational                     [Page 22]

RFC 4186                 EAP-SIM Authentication             January 2006


   If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
   fast re-authentication identity and the server agrees on using
   re-authentication, then the server proceeds with fast
   re-authentication by sending EAP-Request/SIM/Re-authentication
   (Section 5).

   If the server used AT_ANY_ID_REQ, and if the peer sent an
   EAP-Response/SIM/Start with only AT_IDENTITY (indicating
   re-authentication), but the server is not able to map the identity to
   a permanent identity, then the server sends EAP-Request/SIM/Start
   with AT_FULLAUTH_ID_REQ.

   If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
   fast re-authentication identity that the server is able to map to a
   permanent identity, and if the server does not want to use fast
   re-authentication, then the server sends EAP-Request/SIM/Start
   without any identity requesting attributes.

   If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
   identity that the server recognizes as a pseudonym identity but the
   server is not able to map the pseudonym identity to a permanent
   identity, then the server sends EAP-Request/SIM/Start with
   AT_PERMANENT_ID_REQ.

   If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
   identity that the server is not able to recognize or classify, then
   the server sends EAP-Request/SIM/Start with AT_FULLAUTH_ID_REQ.

4.3.  Message Sequence Examples (Informative)

   This section contains non-normative message sequence examples to
   illustrate how the peer identity can be communicated to the server.



















Haverinen & Salowey          Informational                     [Page 23]

RFC 4186                 EAP-SIM Authentication             January 2006


4.3.1.  Full Authentication

   This case for full authentication is illustrated below in Figure 2.
   In this case, AT_IDENTITY contains either the permanent identity or a
   pseudonym identity.  The same sequence is also used in case the
   server uses the AT_FULLAUTH_ID_REQ in EAP-Request/SIM/Start.

      Peer                                             Authenticator
        |                                                       |
        |                            +------------------------------+
        |                            | Server does not have a       |
        |                            | Subscriber identity available|
        |                            | When starting EAP-SIM        |
        |                            +------------------------------+
        |                                                       |
        |          EAP-Request/SIM/Start                        |
        |          (AT_ANY_ID_REQ, AT_VERSION_LIST)             |
        |<------------------------------------------------------|
        |                                                       |
        |                                                       |
        | EAP-Response/SIM/Start                                |
        | (AT_IDENTITY, AT_NONCE_MT,                            |
        |  AT_SELECTED_VERSION)                                 |
        |------------------------------------------------------>|
        |                                                       |

         Figure 2: Requesting any identity, full authentication

   If the peer uses its full authentication identity and the AT_IDENTITY
   attribute contains a valid permanent identity or a valid pseudonym
   identity that the EAP server is able to map to the permanent
   identity, then the full authentication sequence proceeds as usual
   with the EAP Server issuing the EAP-Request/SIM/Challenge message.


















Haverinen & Salowey          Informational                     [Page 24]

RFC 4186                 EAP-SIM Authentication             January 2006


4.3.2.  Fast Re-authentication

   The case when the server uses the AT_ANY_ID_REQ and the peer wants to
   perform fast re-authentication is illustrated below in Figure 3.

      Peer                                             Authenticator
        |                                                       |
        |                            +------------------------------+
        |                            | Server does not have a       |
        |                            | Subscriber identity available|
        |                            | When starting EAP-SIM        |
        |                            +------------------------------+
        |                                                       |
        |        EAP-Request/SIM/Start                          |
        |        (AT_ANY_ID_REQ, AT_VERSION_LIST)               |
        |<------------------------------------------------------|
        |                                                       |
        |                                                       |
        | EAP-Response/SIM/Start                                |
        | (AT_IDENTITY containing a fast re-auth. identity)     |
        |--