rcf4186.txt

RCF4186 about EAP-SIM

   In any case, it is necessary that permanent usernames, pseudonym
   usernames, and fast re-authentication usernames are separate and
   recognizable from each other.  It is also desirable that EAP-SIM and
   EAP-AKA [EAP-AKA] usernames be distinguishable from each other as an
   aid for the server on which method to offer.

   In general, it is the task of the EAP server and the policies of its
   administrator to ensure sufficient separation of the usernames.
   Pseudonym usernames and fast re-authentication usernames are both
   produced and used by the EAP server.  The EAP server MUST compose
   pseudonym usernames and fast re-authentication usernames so that it
   can determine if an NAI username is an EAP-SIM pseudonym username or



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


   an EAP-SIM fast re-authentication username.  For instance, when the
   usernames have been derived from the IMSI, the server could use
   different leading characters in the pseudonym usernames and fast
   re-authentication usernames (e.g., the pseudonym could begin with a
   leading "3" character).  When mapping a fast re-authentication
   identity to a permanent identity, the server SHOULD only examine the
   username portion of the fast re-authentication identity and ignore
   the realm portion of the identity.

   Because the peer may fail to save a pseudonym username sent in an
   EAP-Request/SIM/Challenge, for example due to malfunction, the EAP
   server SHOULD maintain at least the most recently used pseudonym
   username in addition to the most recently issued pseudonym username.
   If the authentication exchange is not completed successfully, then
   the server SHOULD NOT overwrite the pseudonym username that was
   issued during the most recent successful authentication exchange.

4.2.1.8.  Transmitting Pseudonyms and Fast Re-authentication Identities
          to the Peer

   The server transmits pseudonym usernames and fast re-authentication
   identities to the peer in cipher, using the AT_ENCR_DATA attribute.

   The EAP-Request/SIM/Challenge message MAY include an encrypted
   pseudonym username and/or an encrypted fast re-authentication
   identity in the value field of the AT_ENCR_DATA attribute.  Because
   identity privacy support and fast re-authentication are optional
   implementations, the peer MAY ignore the AT_ENCR_DATA attribute and
   always use the permanent identity.  On fast re-authentication
   (discussed in Section 5), the server MAY include a new, encrypted
   fast re-authentication identity in the
   EAP-Request/SIM/Re-authentication message.

   On receipt of the EAP-Request/SIM/Challenge, the peer MAY decrypt the
   encrypted data in AT_ENCR_DATA.  If the authentication exchange is
   successful, and the encrypted data includes a pseudonym username,
   then the peer may use the obtained pseudonym username on the next
   full authentication.  If a fast re-authentication identity is
   included, then the peer MAY save it together with other fast
   re-authentication state information, as discussed in Section 5, for
   the next fast re-authentication.  If the authentication exchange does
   not complete successfully, the peer MUST ignore the received
   pseudonym username and the fast re-authentication identity.

   If the peer does not receive a new pseudonym username in the
   EAP-Request/SIM/Challenge message, the peer MAY use an old pseudonym
   username instead of the permanent username on the next full
   authentication.  The username portions of fast re-authentication



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


   identities are one-time usernames, which the peer MUST NOT re-use.
   When the peer uses a fast re-authentication identity in an EAP
   exchange, the peer MUST discard the fast re-authentication identity
   and not re-use it in another EAP authentication exchange, even if the
   authentication exchange was not completed.

4.2.1.9.  Usage of the Pseudonym by the Peer

   When the optional identity privacy support is used on full
   authentication, the peer MAY use a pseudonym username received as
   part of a previous full authentication sequence as the username
   portion of the NAI.  The peer MUST NOT modify the pseudonym username
   received in AT_NEXT_PSEUDONYM.  However, as discussed above, the peer
   MAY need to decorate the username in some environments by appending
   or prepending the username with a string that indicates supplementary
   AAA routing information.

   When using a pseudonym username in an environment where a realm
   portion is used, the peer concatenates the received pseudonym
   username with the "@" character and an NAI realm portion.  The
   selection of the NAI realm is discussed above.  The peer can select
   the realm portion similarly, regardless of whether it uses the
   permanent username or a pseudonym username.

4.2.1.10.  Usage of the Fast Re-authentication Identity by the Peer

   On fast re-authentication, the peer uses the fast re-authentication
   identity that was received as part of the previous authentication
   sequence.  A new re-authentication identity may be delivered as part
   of both full authentication and fast re-authentication.  The peer
   MUST NOT modify the username part of the fast re-authentication
   identity received in AT_NEXT_REAUTH_ID, except in cases when username
   decoration is required.  Even in these cases, the "root" fast
   re-authentication username must not be modified, but it may be
   appended or prepended with another string.

4.2.2.  Communicating the Peer Identity to the Server

4.2.2.1.  General

   The peer identity MAY be communicated to the server with the
   EAP-Response/Identity message.  This message MAY contain the
   permanent identity, a pseudonym identity, or a fast re-authentication
   identity.  If the peer uses the permanent identity or a pseudonym
   identity, which the server is able to map to the permanent identity,
   then the authentication proceeds as discussed in the overview of
   Section 3.  If the peer uses a fast re-authentication identity, and
   if the fast re-authentication identity matches with a valid fast



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


   re-authentication identity maintained by the server, and if the
   server agrees to use fast re-authentication, then a fast
   re-authentication exchange is performed, as described in Section 5.

   The peer identity can also be transmitted from the peer to the server
   using EAP-SIM messages instead of the EAP-Response/Identity.  In this
   case, the server includes an identity-requesting attribute
   (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the
   EAP-Request/SIM/Start message, and the peer includes the AT_IDENTITY
   attribute, which contains the peer's identity, in the
   EAP-Response/SIM/Start message.  The AT_ANY_ID_REQ attribute is a
   general identity-requesting attribute, which the server uses if it
   does not specify which kind of an identity the peer should return in
   AT_IDENTITY.  The server uses the AT_FULLAUTH_ID_REQ attribute to
   request either the permanent identity or a pseudonym identity.  The
   server uses the AT_PERMANENT_ID_REQ attribute to request that the
   peer send its permanent identity.

   The identity format in the AT_IDENTITY attribute is the same as in
   the EAP-Response/Identity packet (except that identity decoration is
   not allowed).  The AT_IDENTITY attribute contains a permanent
   identity, a pseudonym identity, or a fast re-authentication identity.

   Please note that the EAP-SIM peer and the EAP-SIM server only process
   the AT_IDENTITY attribute; entities that only pass through EAP
   packets do not process this attribute.  Hence, the authenticator and
   other intermediate AAA elements (such as possible AAA proxy servers)
   will continue to refer to the peer with the original identity from
   the EAP-Response/Identity packet unless the identity authenticated in
   the AT_IDENTITY attribute is communicated to them in another way
   within the AAA protocol.

4.2.2.2.  Relying on EAP-Response/Identity Discouraged

   The EAP-Response/Identity packet is not method-specific, so in many
   implementations it may be handled by an EAP Framework.  This
   introduces an additional layer of processing between the EAP peer and
   EAP server.  The extra layer of processing may cache identity
   responses or add decorations to the identity.  A modification of the
   identity response will cause the EAP peer and EAP server to use
   different identities in the key derivation, which will cause the
   protocol to fail.

   For this reason, it is RECOMMENDED that the EAP peer and server use
   the method-specific identity attributes in EAP-SIM, and the server is
   strongly discouraged from relying upon the EAP-Response/Identity.





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


   In particular, if the EAP server receives a decorated identity in
   EAP-Response/Identity, then the EAP server MUST use the
   identity-requesting attributes to request that the peer send an
   unmodified and undecorated copy of the identity in AT_IDENTITY.

4.2.3.  Choice of Identity for the EAP-Response/Identity

   If EAP-SIM peer is started upon receiving an EAP-Request/Identity
   message, then the peer MAY use an EAP-SIM identity in the EAP-
   Response/Identity packet.  In this case, the peer performs the
   following steps.

   If the peer has maintained fast re-authentication state information
   and wants to use fast re-authentication, then the peer transmits the
   fast re-authentication identity in EAP-Response/Identity.

   Else, if the peer has a pseudonym username available, then the peer
   transmits the pseudonym identity in EAP-Response/Identity.

   In other cases, the peer transmits the permanent identity in
   EAP-Response/Identity.

4.2.4.  Server Operation in the Beginning of EAP-SIM Exchange

   As discussed in Section 4.2.2.2, the server SHOULD NOT rely on an
   identity string received in EAP-Response/Identity.  Therefore, the
   RECOMMENDED way to start an EAP-SIM exchange is to ignore any
   received identity strings.  The server SHOULD begin the EAP-SIM
   exchange by issuing the EAP-Request/SIM/Start packet with an
   identity-requesting attribute to indicate that the server wants the
   peer to include an identity in the AT_IDENTITY attribute of the EAP-
   Response/SIM/Start message.  Three methods to request an identity
   from the peer are discussed below.

   If the server chooses not to ignore the contents of EAP-
   Response/Identity, then the server may have already received an EAP-
   SIM identity in this packet.  However, if the EAP server has not
   received any EAP-SIM peer identity (permanent identity, pseudonym
   identity, or fast re-authentication identity) from the peer when
   sending the first EAP-SIM request, or if the EAP server has received
   an EAP-Response/Identity packet but the contents do not appear to be
   a valid permanent identity, pseudonym identity or a re-authentication
   identity, then the server MUST request an identity from the peer
   using one of the methods below.

   The server sends the EAP-Request/SIM/Start message with the
   AT_PERMANENT_ID_REQ attribute to indicate that the server wants the
   peer to include the permanent identity in the AT_IDENTITY attribute



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


   of the EAP-Response/SIM/Start message.  This is done in the following
   cases:

   o  The server does not support fast re-authentication or identity
      privacy.

   o  The server decided to process a received identity, and the server
      recognizes the received identity as a pseudonym identity but the
      server is not able to map the pseudonym identity to a permanent
      identity.

   The server issues the EAP-Request/SIM/Start packet with the
   AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the
   peer to include a full authentication identity (pseudonym identity or
   permanent identity) in the AT_IDENTITY attribute of the
   EAP-Response/SIM/Start message.  This is done in the following cases:

   o  The server does not support fast re-authentication and the server
      supports identity privacy.

   o  The server decided to process a received identity, and the server
      recognizes the received identity as a re-authentication identity
      but the server is not able to map the re-authentication identity
      to a permanent identity.

   The server issues the EAP-Request/SIM/Start packet with the
   AT_ANY_ID_REQ attribute to indicate that the server wants the peer to
   include an identity in the AT_IDENTITY attribute of the