added EAP-SIM authentication
authorMartin Willi <martin@strongswan.org>
Tue, 13 Mar 2007 15:01:02 +0000 (15:01 -0000)
committerMartin Willi <martin@strongswan.org>
Tue, 13 Mar 2007 15:01:02 +0000 (15:01 -0000)
  client side only
  uses an external SIM reader library specified with SIM_READER_LIB
  untested

configure.in
src/charon/Makefile.am
src/charon/doc/standards/rfc4186.txt [new file with mode: 0644]
src/charon/sa/authenticators/eap/eap_method.c
src/charon/sa/authenticators/eap/eap_method.h
src/charon/sa/authenticators/eap/eap_sim.c [new file with mode: 0644]
src/charon/sa/authenticators/eap/eap_sim.h [new file with mode: 0644]
src/starter/confread.c

index aa8b624..03f0f0e 100644 (file)
@@ -119,6 +119,13 @@ AC_ARG_ENABLE(
 )
 AM_CONDITIONAL(USE_LEAK_DETECTIVE, test x$leak_detective = xtrue)
 
+AC_ARG_ENABLE(
+    [eap-sim],
+    AS_HELP_STRING([--enable-eap-sim],[build SIM authenication module for EAP (default is NO).]),
+    eap_sim=true
+)
+AM_CONDITIONAL(BUILD_EAP_SIM, test x$eap_sim = xtrue)
+
 dnl =========================
 dnl  check required programs
 dnl =========================
index 0eb3b49..c422939 100644 (file)
@@ -1,8 +1,17 @@
 # SUBDIRS = . testing
 
-eap_LTLIBRARIES =
+eap_LTLIBRARIES = libeapidentity.la
+
+# always build EAP Identity module
+libeapidentity_la_SOURCES = sa/authenticators/eap/eap_identity.h sa/authenticators/eap/eap_identity.c
+libeapidentity_la_LDFLAGS = -module
 
 # build optional EAP modules
+if BUILD_EAP_SIM
+  eap_LTLIBRARIES += libeapsim.la
+  libeapsim_la_SOURCES = sa/authenticators/eap/eap_sim.h sa/authenticators/eap/eap_sim.c
+  libeapsim_la_LDFLAGS = -module
+endif
 
 ipsec_PROGRAMS = charon
 
diff --git a/src/charon/doc/standards/rfc4186.txt b/src/charon/doc/standards/rfc4186.txt
new file mode 100644 (file)
index 0000000..e7435a0
--- /dev/null
@@ -0,0 +1,5155 @@
+
+
+
+
+
+
+Network Working Group                                  H. Haverinen, Ed.
+Request for Comments: 4186                                         Nokia
+Category: Informational                                  J. Salowey, Ed.
+                                                           Cisco Systems
+                                                            January 2006
+
+
+             Extensible Authentication Protocol Method for
+             Global System for Mobile Communications (GSM)
+                 Subscriber Identity Modules (EAP-SIM)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+IESG Note
+
+   The EAP-SIM protocol was developed by 3GPP.  The documentation of
+   EAP-SIM is provided as information to the Internet community.  While
+   the EAP WG has verified that EAP-SIM is compatible with EAP, as
+   defined in RFC 3748, no other review has been done, including
+   validation of the security claims.  The IETF has also not reviewed
+   the security of the cryptographic algorithms.
+
+Abstract
+
+   This document specifies an Extensible Authentication Protocol (EAP)
+   mechanism for authentication and session key distribution using the
+   Global System for Mobile Communications (GSM) Subscriber Identity
+   Module (SIM).  GSM is a second generation mobile network standard.
+   The EAP-SIM mechanism specifies enhancements to GSM authentication
+   and key agreement whereby multiple authentication triplets can be
+   combined to create authentication responses and session keys of
+   greater strength than the individual GSM triplets.  The mechanism
+   also includes network authentication, user anonymity support, result
+   indications, and a fast re-authentication procedure.
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                      [Page 1]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Terms ...........................................................5
+   3. Overview ........................................................8
+   4. Operation ......................................................10
+      4.1. Version Negotiation .......................................10
+      4.2. Identity Management .......................................11
+           4.2.1. Format, Generation and Usage of Peer Identities ....11
+           4.2.2. Communicating the Peer Identity to the Server ......17
+           4.2.3. Choice of Identity for the EAP-Response/Identity ...19
+           4.2.4. Server Operation in the Beginning of
+                  EAP-SIM Exchange ...................................19
+           4.2.5. Processing of EAP-Request/SIM/Start by the Peer ....20
+           4.2.6. Attacks Against Identity Privacy ...................21
+           4.2.7. Processing of AT_IDENTITY by the Server ............22
+      4.3. Message Sequence Examples (Informative) ...................23
+           4.3.1. Full Authentication ................................24
+           4.3.2. Fast Re-authentication .............................25
+           4.3.3. Fall Back to Full Authentication ...................26
+           4.3.4. Requesting the Permanent Identity 1 ................27
+           4.3.5. Requesting the Permanent Identity 2 ................28
+           4.3.6. Three EAP-SIM/Start Roundtrips .....................28
+   5. Fast Re-Authentication .........................................30
+      5.1. General ...................................................30
+      5.2. Comparison to UMTS AKA ....................................31
+      5.3. Fast Re-authentication Identity ...........................31
+      5.4. Fast Re-authentication Procedure ..........................33
+      5.5. Fast Re-authentication Procedure when Counter Is
+           Too Small .................................................36
+   6. EAP-SIM Notifications ..........................................37
+      6.1. General ...................................................37
+      6.2. Result Indications ........................................39
+      6.3. Error Cases ...............................................40
+           6.3.1. Peer Operation .....................................40
+           6.3.2. Server Operation ...................................41
+           6.3.3. EAP-Failure ........................................42
+           6.3.4. EAP-Success ........................................42
+   7. Key Generation .................................................43
+   8. Message Format and Protocol Extensibility ......................45
+      8.1. Message Format ............................................45
+      8.2. Protocol Extensibility ....................................47
+   9. Messages .......................................................48
+      9.1. EAP-Request/SIM/Start .....................................48
+      9.2. EAP-Response/SIM/Start ....................................49
+      9.3. EAP-Request/SIM/Challenge .................................49
+      9.4. EAP-Response/SIM/Challenge ................................50
+      9.5. EAP-Request/SIM/Re-authentication .........................51
+
+
+
+Haverinen & Salowey          Informational                      [Page 2]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+      9.6. EAP-Response/SIM/Re-authentication ........................51
+      9.7. EAP-Response/SIM/Client-Error .............................52
+      9.8. EAP-Request/SIM/Notification ..............................52
+      9.9. EAP-Response/SIM/Notification .............................53
+   10. Attributes ....................................................53
+      10.1. Table of Attributes ......................................53
+      10.2. AT_VERSION_LIST ..........................................54
+      10.3. AT_SELECTED_VERSION ......................................55
+      10.4. AT_NONCE_MT ..............................................55
+      10.5. AT_PERMANENT_ID_REQ ......................................56
+      10.6. AT_ANY_ID_REQ ............................................56
+      10.7. AT_FULLAUTH_ID_REQ .......................................57
+      10.8. AT_IDENTITY ..............................................57
+      10.9. AT_RAND ..................................................58
+      10.10. AT_NEXT_PSEUDONYM .......................................59
+      10.11. AT_NEXT_REAUTH_ID .......................................59
+      10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING .....................60
+      10.13. AT_RESULT_IND ...........................................62
+      10.14. AT_MAC ..................................................62
+      10.15. AT_COUNTER ..............................................63
+      10.16. AT_COUNTER_TOO_SMALL ....................................63
+      10.17. AT_NONCE_S ..............................................64
+      10.18. AT_NOTIFICATION .........................................64
+      10.19. AT_CLIENT_ERROR_CODE ....................................65
+   11. IANA Considerations ...........................................66
+   12. Security Considerations .......................................66
+      12.1. A3 and A8 Algorithms .....................................66
+      12.2. Identity Protection ......................................66
+      12.3. Mutual Authentication and Triplet Exposure ...............67
+      12.4. Flooding the Authentication Centre .......................69
+      12.5. Key Derivation ...........................................69
+      12.6. Cryptographic Separation of Keys and Session
+            Independence .............................................70
+      12.7. Dictionary Attacks .......................................71
+      12.8. Credentials Re-use .......................................71
+      12.9. Integrity and Replay Protection, and Confidentiality .....72
+      12.10. Negotiation Attacks .....................................73
+      12.11. Protected Result Indications ............................73
+      12.12. Man-in-the-Middle Attacks ...............................74
+      12.13. Generating Random Numbers ...............................74
+   13. Security Claims ...............................................74
+   14. Acknowledgements and Contributions ............................75
+      14.1. Contributors .............................................75
+      14.2. Acknowledgements .........................................75
+           14.2.1. Contributors' Addresses ...........................77
+   15. References ....................................................78
+      15.1. Normative References .....................................78
+      15.2. Informative References ...................................79
+
+
+
+Haverinen & Salowey          Informational                      [Page 3]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   Appendix A.  Test Vectors .........................................81
+      A.1.  EAP-Request/Identity .....................................81
+      A.2.  EAP-Response/Identity ....................................81
+      A.3.  EAP-Request/SIM/Start ....................................82
+      A.4.  EAP-Response/SIM/Start ...................................82
+      A.5.  EAP-Request/SIM/Challenge ................................83
+      A.6.  EAP-Response/SIM/Challenge ...............................86
+      A.7.  EAP-Success ..............................................86
+      A.8.  Fast Re-authentication ...................................86
+      A.9.  EAP-Request/SIM/Re-authentication ........................87
+      A.10.  EAP-Response/SIM/Re-authentication ......................89
+   Appendix B.  Pseudo-Random Number Generator .......................90
+
+1.  Introduction
+
+   This document specifies an Extensible Authentication Protocol (EAP)
+   [RFC3748] mechanism for authentication and session key distribution
+   using the Global System for Mobile Communications (GSM) Subscriber
+   Identity Module (SIM).
+
+   GSM is a second generation mobile network standard.  Second
+   generation mobile networks and third generation mobile networks use
+   different authentication and key agreement mechanisms.  EAP-AKA
+   [EAP-AKA] specifies an EAP method that is based on the Authentication
+   and Key Agreement (AKA) mechanism used in 3rd generation mobile
+   networks.
+
+   GSM authentication is based on a challenge-response mechanism.  The
+   A3/A8 authentication and key derivation algorithms that run on the
+   SIM can be given a 128-bit random number (RAND) as a challenge.  The
+   SIM runs operator-specific algorithms, which take the RAND and a
+   secret key Ki (stored on the SIM) as input, and produce a 32-bit
+   response (SRES) and a 64-bit long key Kc as output.  The Kc key is
+   originally intended to be used as an encryption key over the air
+   interface, but in this protocol, it is used for deriving keying
+   material and is not directly used.  Hence, the secrecy of Kc is
+   critical to the security of this protocol.  For more information
+   about GSM authentication, see [GSM-03.20].  See Section 12.1 for more
+   discussion about the GSM algorithms used in EAP-SIM.
+
+   The lack of mutual authentication is a weakness in GSM
+   authentication.  The derived 64-bit cipher key (Kc) is not strong
+   enough for data networks in which stronger and longer keys are
+   required.  Hence, in EAP-SIM, several RAND challenges are used for
+   generating several 64-bit Kc keys, which are combined to constitute
+   stronger keying material.  In EAP-SIM, the client issues a random
+   number NONCE_MT to the network in order to contribute to key
+   derivation, and to prevent replays of EAP-SIM requests from previous
+
+
+
+Haverinen & Salowey          Informational                      [Page 4]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   exchanges.  The NONCE_MT can be conceived as the client's challenge
+   to the network.  EAP-SIM also extends the combined RAND challenges
+   and other messages with a message authentication code in order to
+   provide message integrity protection along with mutual
+   authentication.
+
+   EAP-SIM specifies optional support for protecting the privacy of
+   subscriber identity using the same concept as the GSM, which uses
+   pseudonyms/temporary identifiers.  It also specifies an optional fast
+   re-authentication procedure.
+
+   The security of EAP-SIM builds on underlying GSM mechanisms.  The
+   security properties of EAP-SIM are documented in Section 11 of this
+   document.  Implementers and users of EAP-SIM are advised to carefully
+   study the security considerations in Section 11 in order to determine
+   whether the security properties are sufficient for the environment in
+   question, especially as the secrecy of Kc keys is essential to the
+   security of EAP-SIM.  In brief, EAP-SIM is in no sense weaker than
+   the GSM mechanisms.  In some cases EAP-SIM provides better security
+   properties than the underlying GSM mechanisms, particularly if the
+   SIM credentials are only used for EAP-SIM and are not re-used from
+   GSM/GPRS.  Many of the security features of EAP-SIM rely upon the
+   secrecy of the Kc values in the SIM triplets, so protecting these
+   values is key to the security of the EAP-SIM protocol.
+
+   The 3rd Generation Partnership Project (3GPP) has specified an
+   enhanced Authentication and Key Agreement (AKA) architecture for the
+   Universal Mobile Telecommunications System (UMTS).  The 3rd
+   generation AKA mechanism includes mutual authentication, replay
+   protection, and derivation of longer session keys.  EAP-AKA [EAP-AKA]
+   specifies an EAP method that is based on the 3rd generation AKA.
+   EAP-AKA, which is a more secure protocol, may be used instead of
+   EAP-SIM, if 3rd generation identity modules and 3G network
+   infrastructures are available.
+
+2.  Terms
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   The terms and abbreviations "authenticator", "backend authentication
+   server", "EAP server", "peer", "Silently Discard", "Master Session
+   Key (MSK)", and "Extended Master Session Key (EMSK)" in this document
+   are to be interpreted as described in [RFC3748].
+
+
+
+
+
+
+Haverinen & Salowey          Informational                      [Page 5]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   This document frequently uses the following terms and abbreviations:
+
+   AAA protocol
+
+         Authentication, Authorization, and Accounting protocol
+
+   AuC
+
+         Authentication Centre.  The GSM network element that provides
+         the authentication triplets for authenticating
+         the subscriber.
+
+   Authentication vector
+
+         GSM triplets can be alternatively called authentication
+         vectors.
+
+   EAP
+
+         Extensible Authentication Protocol
+
+   Fast re-authentication
+
+         An EAP-SIM authentication exchange that is based on keys
+         derived upon a preceding full authentication exchange.
+         The GSM authentication and key exchange algorithms are not
+         used in the fast re-authentication procedure.
+
+   Fast Re-authentication Identity
+
+         A fast re-authentication identity of the peer, including an NAI
+         realm portion in environments where a realm is used.  Used on
+         fast re-authentication only.
+
+   Fast Re-authentication Username
+
+         The username portion of fast re-authentication identity,
+         i.e., not including any realm portions.
+
+   Full authentication
+
+         An EAP-SIM authentication exchange based on the GSM
+         authentication and key agreement algorithms.
+
+   GSM
+
+         Global System for Mobile communications.
+
+
+
+
+Haverinen & Salowey          Informational                      [Page 6]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   GSM Triplet
+
+         The tuple formed by the three GSM authentication values RAND,
+         Kc, and SRES.
+
+   IMSI
+
+         International Mobile Subscriber Identifier, used in GSM to
+         identify subscribers.
+
+   MAC
+
+         Message Authentication Code
+
+   NAI
+
+         Network Access Identifier
+
+   Nonce
+
+         A value that is used at most once or that is never repeated
+         within the same cryptographic context.  In general, a nonce can
+         be predictable (e.g., a counter) or unpredictable (e.g., a
+         random value).  Since some cryptographic properties may depend
+         on the randomness of the nonce, attention should be paid to
+         whether a nonce is required to be random or not.  In this
+         document, the term nonce is only used to denote random nonces,
+         and it is not used to denote counters.
+
+   Permanent Identity
+
+         The permanent identity of the peer, including an NAI realm
+         portion in environments where a realm is used.  The permanent
+         identity is usually based on the IMSI.  Used on full
+         authentication only.
+
+   Permanent Username
+
+         The username portion of permanent identity, i.e., not including
+         any realm portions.
+
+   Pseudonym Identity
+
+         A pseudonym identity of the peer, including an NAI realm
+         portion in environments where a realm is used.  Used on
+         full authentication only.
+
+
+
+
+
+Haverinen & Salowey          Informational                      [Page 7]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   Pseudonym Username
+
+         The username portion of pseudonym identity, i.e., not including
+         any realm portions.
+
+   SIM
+
+         Subscriber Identity Module.  The SIM is traditionally a smart
+         card distributed by a GSM operator.
+
+3.  Overview
+
+   Figure 1 shows an overview of the EAP-SIM full authentication
+   procedure, wherein optional protected success indications are not
+   used.  The authenticator typically communicates with an EAP server
+   that is located on a backend authentication server using an AAA
+   protocol.  The authenticator shown in the figure is often simply
+   relaying EAP messages to and from the EAP server, but these backend
+   AAA communications are not shown.
+
+     Peer                                               Authenticator
+       |                               EAP-Request/Identity       |
+       |<---------------------------------------------------------|
+       |                                                          |
+       | EAP-Response/Identity                                    |
+       |--------------------------------------------------------->|
+       |                                                          |
+       |                  EAP-Request/SIM/Start (AT_VERSION_LIST) |
+       |<---------------------------------------------------------|
+       |                                                          |
+       | EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)|
+       |--------------------------------------------------------->|
+       |                                                          |
+       |           EAP-Request/SIM/Challenge (AT_RAND, AT_MAC)    |
+       |<---------------------------------------------------------|
+   +-------------------------------------+                        |
+   | Peer runs GSM algorithms, verifies  |                        |
+   | AT_MAC and derives session keys     |                        |
+   +-------------------------------------+                        |
+       | EAP-Response/SIM/Challenge (AT_MAC)                      |
+       |--------------------------------------------------------->|
+       |                                                          |
+       |                                             EAP-Success  |
+       |<---------------------------------------------------------|
+       |                                                          |
+
+            Figure 1: EAP-SIM full authentication procedure
+
+
+
+
+Haverinen & Salowey          Informational                      [Page 8]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   The first EAP Request issued by the authenticator is
+   EAP-Request/Identity.  On full authentication, the peer's response
+   includes either the user's International Mobile Subscriber Identity
+   (IMSI) or a temporary identity (pseudonym) if identity privacy is in
+   effect, as specified in Section 4.2.
+
+   Following the peer's EAP-Response/Identity packet, the peer receives
+   EAP Requests of Type 18 (SIM) from the EAP server and sends the
+   corresponding EAP Responses.  The EAP packets that are of the Type
+   SIM also have a Subtype field.  On full authentication, the first
+   EAP-Request/SIM packet is of the Subtype 10 (Start).  EAP-SIM packets
+   encapsulate parameters in attributes, encoded in a Type, Length,
+   Value format.  The packet format and the use of attributes are
+   specified in Section 8.
+
+   The EAP-Request/SIM/Start packet contains the list of EAP-SIM
+   versions supported by the EAP server in the AT_VERSION_LIST
+   attribute.  This packet may also include attributes for requesting
+   the subscriber identity, as specified in Section 4.2.
+
+   The peer responds to a EAP-Request/SIM/Start with the
+   EAP-Response/SIM/Start packet, which includes the AT_NONCE_MT
+   attribute that contains a random number NONCE_MT, chosen by the peer,
+   and the AT_SELECTED_VERSION attribute that contains the version
+   number selected by the peer.  The version negotiation is protected by
+   including the version list and the selected version in the
+   calculation of keying material (Section 7).
+
+   After receiving the EAP Response/SIM/Start, the EAP server obtains n
+   GSM triplets for use in authenticating the subscriber, where n = 2 or
+   n = 3.  From the triplets, the EAP server derives the keying
+   material, as specified in Section 7.  The triplets may be obtained by
+   contacting an Authentication Centre (AuC) on the GSM network; per GSM
+   specifications, between 1 and 5 triplets may be obtained at a time.
+   Triplets may be stored in the EAP server for use at a later time, but
+   triplets MUST NOT be re-used, except in some error cases that are
+   specified in Section 10.9.
+
+   The next EAP Request the EAP Server issues is of the type SIM and
+   subtype Challenge (11).  It contains the RAND challenges and a
+   message authentication code attribute AT_MAC to cover the challenges.
+   The AT_MAC attribute is a general message authentication code
+   attribute that is used in many EAP-SIM messages.
+
+   On receipt of the EAP-Request/SIM/Challenge message, the peer runs
+   the GSM authentication algorithm and calculates a copy of the message
+   authentication code.  The peer then verifies that the calculated MAC
+   equals the received MAC.  If the MAC's do not match, then the peer
+
+
+
+Haverinen & Salowey          Informational                      [Page 9]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   sends the EAP-Response/SIM/Client-Error packet and the authentication
+   exchange terminates.
+
+   Since the RANDs given to a peer are accompanied by the message
+   authentication code AT_MAC, and since the peer's NONCE_MT value
+   contributes to AT_MAC, the peer is able to verify that the EAP-SIM
+   message is fresh (i.e., not a replay) and that the sender possesses
+   valid GSM triplets for the subscriber.
+
+   If all checks out, the peer responds with the
+   EAP-Response/SIM/Challenge, containing the AT_MAC attribute that
+   covers the peer's SRES response values (Section 9.4).  The EAP server
+   verifies that the MAC is correct.  Because protected success
+   indications are not used in this example, the EAP server sends the
+   EAP-Success packet, indicating that the authentication was
+   successful.  (Protected success indications are discussed in
+   Section 6.2.)  The EAP server may also include derived keying
+   material in the message it sends to the authenticator.  The peer has
+   derived the same keying material, so the authenticator does not
+   forward the keying material to the peer along with EAP-Success.
+
+   EAP-SIM also includes a separate fast re-authentication procedure
+   that does not make use of the A3/A8 algorithms or the GSM
+   infrastructure.  Fast re-authentication is based on keys derived on
+   full authentication.  If the peer has maintained state information
+   for fast re-authentication and wants to use fast re-authentication,
+   then the peer indicates this by using a specific fast
+   re-authentication identity instead of the permanent identity or a
+   pseudonym identity.  The fast re-authentication procedure is
+   described in Section 5.
+
+4.  Operation
+
+4.1.  Version Negotiation
+
+   EAP-SIM includes version negotiation so as to allow future
+   developments in the protocol.  The version negotiation is performed
+   on full authentication and it uses two attributes, AT_VERSION_LIST,
+   which the server always includes in EAP-Request/SIM/Start, and
+   AT_SELECTED_VERSION, which the peer includes in
+   EAP-Response/SIM/Start on full authentication.
+
+   AT_VERSION_LIST includes the EAP-SIM versions supported by the
+   server.  If AT_VERSION_LIST 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
+   (Section 9.7) to the server with the error code "unsupported
+   version".  If a suitable version is included, then the peer includes
+
+
+
+Haverinen & Salowey          Informational                     [Page 10]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   the AT_SELECTED_VERSION attribute, containing the selected version in
+   the EAP-Response/SIM/Start packet.  The peer MUST only indicate a
+   version that is included in the AT_VERSION_LIST.  If several versions
+   are acceptable, then the peer SHOULD choose the version that occurs
+   first in the version list.
+
+   The version number list of AT_VERSION_LIST and the selected version
+   of AT_SELECTED_VERSION are included in the key derivation procedure
+   (Section 7).  If an attacker modifies either one of these attributes,
+   then the peer and the server derive different keying material.
+   Because K_aut keys are different, the server and peer calculate
+   different AT_MAC values.  Hence, the peer detects that AT_MAC,
+   included in EAP-Request/SIM/Challenge, is incorrect and sends the
+   EAP-Response/SIM/Client-Error packet.  The authentication procedure
+   terminates.
+
+4.2.  Identity Management
+
+4.2.1.  Format, Generation and Usage of Peer Identities
+
+4.2.1.1.  General
+
+   In the beginning of EAP authentication, the Authenticator or the EAP
+   server usually issues the EAP-Request/Identity packet to the peer.
+   The peer responds with the EAP-Response/Identity, which contains the
+   user's identity.  The formats of these packets are specified in
+   [RFC3748].
+
+   GSM subscribers are identified with the International Mobile
+   Subscriber Identity (IMSI) [GSM-03.03].  The IMSI is a string of not
+   more than 15 digits.  It is composed of a three digit Mobile Country
+   Code (MCC), a two or three digit Mobile Network Code (MNC), and a
+   Mobile Subscriber Identification Number (MSIN) of no more than 10
+   digits.  MCC and MNC uniquely identify the GSM operator and help
+   identify the AuC from which the authentication vectors need to be
+   retrieved for this subscriber.
+
+   Internet AAA protocols identify users with the Network Access
+   Identifier (NAI) [RFC4282].  When used in a roaming environment, the
+   NAI is composed of a username and a realm, separated with "@"
+   (username@realm).  The username portion identifies the subscriber
+   within the realm.
+
+   This section specifies the peer identity format used in EAP-SIM.  In
+   this document, the term "identity" or "peer identity" refers to the
+   whole identity string that is used to identify the peer.  The peer
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 11]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   identity may include a realm portion.  "Username" refers to the
+   portion of the peer identity that identifies the user, i.e., the
+   username does not include the realm portion.
+
+4.2.1.2.  Identity Privacy Support
+
+   EAP-SIM includes optional identity privacy (anonymity) support that
+   can be used to hide the cleartext permanent identity and thereby make
+   the subscriber's EAP exchanges untraceable to eavesdroppers.  Because
+   the permanent identity never changes, revealing it would help
+   observers to track the user.  The permanent identity is usually based
+   on the IMSI, which may further help the tracking, because the same
+   identifier may be used in other contexts as well.  Identity privacy
+   is based on temporary identities, or pseudonyms, which are equivalent
+   to but separate from the Temporary Mobile Subscriber Identities
+   (TMSI) that are used on cellular networks.  Please see Section 12.2
+   for security considerations regarding identity privacy.
+
+4.2.1.3.  Username Types in EAP-SIM identities
+
+   There are three types of usernames in EAP-SIM peer identities:
+
+   (1) Permanent usernames.  For example,
+   1123456789098765@myoperator.com might be a valid permanent identity.
+   In this example, 1123456789098765 is the permanent username.
+
+   (2) Pseudonym usernames.  For example, 3s7ah6n9q@myoperator.com might
+   be a valid pseudonym identity.  In this example, 3s7ah6n9q is the
+   pseudonym username.
+
+   (3) Fast re-authentication usernames.  For example,
+   53953754@myoperator.com might be a valid fast re-authentication
+   identity.  In this case, 53953754 is the fast re-authentication
+   username.  Unlike permanent usernames and pseudonym usernames, fast
+   re-authentication usernames are one-time identifiers, which are not
+   re-used across EAP exchanges.
+
+   The first two types of identities are used only on full
+   authentication and the last one only on fast re-authentication.  When
+   the optional identity privacy support is not used, the non-pseudonym
+   permanent identity is used on full authentication.  The fast
+   re-authentication exchange is specified in Section 5.
+
+4.2.1.4.  Username Decoration
+
+   In some environments, the peer may need to decorate the identity by
+   prepending or appending the username with a string, in order to
+   indicate supplementary AAA routing information in addition to the NAI
+
+
+
+Haverinen & Salowey          Informational                     [Page 12]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   realm.  (The usage of an NAI realm portion is not considered
+   decoration.)  Username decoration is out of the scope of this
+   document.  However, it should be noted that username decoration might
+   prevent the server from recognizing a valid username.  Hence,
+   although the peer MAY use username decoration in the identities that
+   the peer includes in EAP-Response/Identity, and although the EAP
+   server MAY accept a decorated peer username in this message, the peer
+   or the EAP server MUST NOT decorate any other peer identities that
+   are used in various EAP-SIM attributes.  Only the identity used in
+   the EAP-Response/Identity may be decorated.
+
+4.2.1.5.  NAI Realm Portion
+
+   The peer MAY include a realm portion in the peer identity, as per the
+   NAI format.  The use of a realm portion is not mandatory.
+
+   If a realm is used, the realm MAY be chosen by the subscriber's home
+   operator and it MAY be a configurable parameter in the EAP-SIM peer
+   implementation.  In this case, the peer is typically configured with
+   the NAI realm of the home operator.  Operators MAY reserve a specific
+   realm name for EAP-SIM users.  This convention makes it easy to
+   recognize that the NAI identifies a GSM subscriber.  Such a reserved
+   NAI realm may be a useful hint as to the first authentication method
+   to use during method negotiation.  When the peer is using a pseudonym
+   username instead of the permanent username, the peer selects the
+   realm name portion similarly as it select the realm portion when
+   using the permanent username.
+
+   If no configured realm name is available, the peer MAY derive the
+   realm name from the MCC and MNC portions of the IMSI.  A RECOMMENDED
+   way to derive the realm from the IMSI using the realm 3gppnetwork.org
+   is specified in [3GPP-TS-23.003].
+
+   Some old implementations derive the realm name from the IMSI by
+   concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits
+   of IMSI, and ".owlan.org".  For example, if the IMSI is
+   123456789098765, and the MNC is three digits long, then the derived
+   realm name is "mnc456.mcc123.owlan.org".  As there are no DNS servers
+   running at owlan.org, these realm names can only be used with
+   manually configured AAA routing.  New implementations SHOULD use the
+   mechanism specified in [3GPP-TS-23.003] instead of owlan.org.
+
+   The IMSI is a string of digits without any explicit structure, so the
+   peer may not be able to determine the length of the MNC portion.  If
+   the peer is not able to determine whether the MNC is two or three
+   digits long, the peer MAY use a 3-digit MNC.  If the correct length
+   of the MNC is two, then the MNC used in the realm name includes the
+   first digit of the MSIN.  Hence, when configuring AAA networks for
+
+
+
+Haverinen & Salowey          Informational                     [Page 13]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   operators that have 2-digit MNCs, the network SHOULD also be prepared
+   for realm names with incorrect, 3-digit MNCs.
+
+4.2.1.6.  Format of the Permanent Username
+
+   The non-pseudonym permanent username SHOULD be derived from the IMSI.
+   In this case, the permanent username MUST be of the format "1" |
+   IMSI, where the character "|" denotes concatenation.  In other words,
+   the first character of the username is the digit one (ASCII value 31
+   hexadecimal), followed by the IMSI.  The IMSI is encoded as an ASCII
+   string that consists of not more than 15 decimal digits (ASCII values
+   between 30 and 39 hexadecimal), one character per IMSI digit, in the
+   order specified in [GSM-03.03].  For example, a permanent username
+   derived from the IMSI 295023820005424 would be encoded as the ASCII
+   string "1295023820005424" (byte values in hexadecimal notation: 31 32
+   39 35 30 32 33 38 32 30 30 30 35 34 32 34).
+
+   The EAP server MAY use the leading "1" as a hint to try EAP-SIM as
+   the first authentication method during method negotiation, rather
+   than, for example EAP/AKA.  The EAP-SIM server MAY propose EAP-SIM,
+   even if the leading character was not "1".
+
+   Alternatively, an implementation MAY choose a permanent username that
+   is not based on the IMSI.  In this case, the selection of the
+   username, its format, and its processing is out of the scope of this
+   document.  In this case, the peer implementation MUST NOT prepend any
+   leading characters to the username.
+
+4.2.1.7.  Generating Pseudonyms and Fast Re-authentication Identities by
+          the Server
+
+   Pseudonym usernames and fast re-authentication identities are
+   generated by the EAP server.  The EAP server produces pseudonym
+   usernames and fast re-authentication identities in an
+   implementation-dependent manner.  Only the EAP server needs to be
+   able to map the pseudonym username to the permanent identity, or to
+   recognize a fast re-authentication identity.
+
+   EAP-SIM includes no provisions to ensure that the same EAP server
+   that generated a pseudonym username will be used on the
+   authentication exchange when the pseudonym username is used.  It is
+   recommended that the EAP servers implement some centralized mechanism
+   to allow all EAP servers of the home operator to map pseudonyms
+   generated by other severs to the permanent identity.  If no such
+   mechanism is available, then the EAP server failing to understand a
+   pseudonym issued by another server can request the that peer send the
+   permanent identity.
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 14]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   When issuing a fast re-authentication identity, the EAP server may
+   include a realm name in the identity to make the fast
+   re-authentication request be forwarded to the same EAP server.
+
+   When generating fast re-authentication identities, the server SHOULD
+   choose a fresh, new fast re-authentication identity that is different
+   from the previous ones that were used after the same full
+   authentication exchange.  A full authentication exchange and the
+   associated fast re-authentication exchanges are referred to here as
+   the same "full authentication context".  The fast re-authentication
+   identity SHOULD include a random component.  This random component
+   works as a full authentication context identifier.  A
+   context-specific fast re-authentication identity can help the server
+   to detect whether its fast re-authentication state information
+   matches that of its peer (in other words, whether the state
+   information is from the same full authentication exchange).  The
+   random component also makes the fast re-authentication identities
+   unpredictable, so an attacker cannot initiate a fast
+   re-authentication exchange to get the server's EAP-Request/SIM/
+   Re-authentication packet.
+
+   Transmitting pseudonyms and fast re-authentication identities from
+   the server to the peer is discussed in Section 4.2.1.8.  The
+   pseudonym is transmitted as a username, without an NAI realm, and the
+   fast re-authentication identity is transmitted as a complete NAI,
+   including a realm portion if a realm is required.  The realm is
+   included in the fast re-authentication identity to allow the server
+   to include a server-specific realm.
+
+   Regardless of the construction method, the pseudonym username MUST
+   conform to the grammar specified for the username portion of an NAI.
+   The fast re-authentication identity also MUST conform to the NAI
+   grammar.  The EAP servers that the subscribers of an operator can use
+   MUST ensure that the pseudonym usernames and the username portions
+   used in fast re-authentication identities they generate are unique.
+
+   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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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
+   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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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)     |
+        |------------------------------------------------------>|
+        |                                                       |
+
+       Figure 3: Requesting any identity, fast re-authentication
+
+   On fast re-authentication, if the AT_IDENTITY attribute contains a
+   valid fast re-authentication identity and the server agrees on using
+   fast re-authentication, then the server proceeds with the fast
+   re-authentication sequence and issues the EAP-Request/SIM/
+   Re-authentication packet, as specified in Section 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 25]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+4.3.3.  Fall Back to Full Authentication
+
+   Figure 4 illustrates cases in which the server does not recognize the
+   fast re-authentication identity the peer used in AT_IDENTITY, and
+   issues a second EAP-Request/SIM/Start message.
+
+      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)     |
+        |------------------------------------------------------>|
+        |                                                       |
+        |                            +------------------------------+
+        |                            | Server does not recognize    |
+        |                            | The fast re-auth.            |
+        |                            | Identity                     |
+        |                            +------------------------------+
+        |                                                       |
+        |     EAP-Request/SIM/Start                             |
+        |     (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST)             |
+        |<------------------------------------------------------|
+        |                                                       |
+        |                                                       |
+        | EAP-Response/SIM/Start                                |
+        | (AT_IDENTITY with a full-auth. identity, AT_NONCE_MT, |
+        |  AT_SELECTED_VERSION)                                 |
+        |------------------------------------------------------>|
+        |                                                       |
+
+              Figure 4: Fall back to full authentication
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 26]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+4.3.4.  Requesting the Permanent Identity 1
+
+   Figure 5 illustrates the case in which the EAP server fails to map
+   the pseudonym identity included in the EAP-Response/Identity packet
+   to a valid permanent identity.
+
+      Peer                                             Authenticator
+         |                                                       |
+         |                               EAP-Request/Identity    |
+         |<------------------------------------------------------|
+         |                                                       |
+         | EAP-Response/Identity                                 |
+         | (Includes a pseudonym)                                |
+         |------------------------------------------------------>|
+         |                                                       |
+         |                            +------------------------------+
+         |                            | Server fails to map the      |
+         |                            | Pseudonym to a permanent id. |
+         |                            +------------------------------+
+         |  EAP-Request/SIM/Start                                |
+         |  (AT_PERMANENT_ID_REQ, AT_VERSION_LIST)               |
+         |<------------------------------------------------------|
+         |                                                       |
+         | EAP-Response/SIM/Start                                |
+         | (AT_IDENTITY with permanent identity, AT_NONCE_MT,    |
+         |  AT_SELECTED_VERSION)                                 |
+         |------------------------------------------------------>|
+         |                                                       |
+
+              Figure 5: Requesting the permanent identity
+
+   If the server recognizes the permanent identity, then the
+   authentication sequence proceeds as usual with the EAP Server issuing
+   the EAP-Request/SIM/Challenge message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 27]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+4.3.5.  Requesting the Permanent Identity 2
+
+   Figure 6 illustrates the case in which the EAP server fails to map
+   the pseudonym included in the AT_IDENTITY attribute to a valid
+   permanent identity.
+
+      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 with a pseudonym identity, AT_NONCE_MT,   |
+         | AT_SELECTED_VERSION)                                  |
+         |------------------------------------------------------>|
+         |                           +-------------------------------+
+         |                           | Server fails to map the       |
+         |                           | Pseudonym in AT_IDENTITY      |
+         |                           | to a valid permanent identity |
+         |                           +-------------------------------+
+         |                                                       |
+         |                EAP-Request/SIM/Start                  |
+         |                (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
+         |<------------------------------------------------------|
+         |                                                       |
+         | EAP-Response/SIM/Start                                |
+         | (AT_IDENTITY with permanent identity,                 |
+         |  AT_NONCE_MT, AT_SELECTED_VERSION)                    |
+         |------------------------------------------------------>|
+         |                                                       |
+
+   Figure 6: Requesting a permanent identity (two EAP-SIM Start rounds)
+
+4.3.6.  Three EAP-SIM/Start Roundtrips
+
+   In the worst case, there are three EAP/SIM/Start round trips before
+   the server obtains an acceptable identity.  This case is illustrated
+   in Figure 7.
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 28]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+      Peer                                             Authenticator
+       |                                                       |
+       |                            +------------------------------+
+       |                            | Server does not have a       |
+       |                            | Subscriber identity available|
+       |                            | When starting EAP-SIM        |
+       |                            +------------------------------+
+       |        EAP-Request/SIM/Start                          |
+       |        (Includes AT_ANY_ID_REQ, AT_VERSION_LIST)      |
+       |<------------------------------------------------------|
+       |                                                       |
+       | EAP-Response/SIM/Start                                |
+       | (AT_IDENTITY with fast re-auth. identity)             |
+       |------------------------------------------------------>|
+       |                                                       |
+       |                            +------------------------------+
+       |                            | Server does not accept       |
+       |                            | The fast re-auth.            |
+       |                            | Identity                     |
+       |                            +------------------------------+
+       |     EAP-Request/SIM/Start                             |
+       |     (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST)             |
+       |<------------------------------------------------------|
+       |                                                       |
+       :                                                       :
+       :                                                       :
+       :                                                       :
+       :                                                       :
+       |EAP-Response/SIM/Start                                 |
+       |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT,   |
+       | AT_SELECTED_VERSION)                                  |
+       |------------------------------------------------------>|
+       |                                                       |
+       |                           +-------------------------------+
+       |                           | Server fails to map the       |
+       |                           | Pseudonym in AT_IDENTITY      |
+       |                           | to a valid permanent identity |
+       |                           +-------------------------------+
+       |           EAP-Request/SIM/Start                       |
+       |           (AT_PERMANENT_ID_REQ, AT_VERSION_LIST)      |
+       |<------------------------------------------------------|
+       |                                                       |
+       | EAP-Response/SIM/Start                                |
+       | (AT_IDENTITY with permanent identity, AT_NONCE_MT,    |
+       |  AT_SELECTED_VERSION)                                 |
+       |------------------------------------------------------>|
+       |                                                       |
+                Figure 7: Three EAP-SIM Start rounds
+
+
+
+Haverinen & Salowey          Informational                     [Page 29]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   After the last EAP-Response/SIM/Start message, the full
+   authentication sequence proceeds as usual.  If the EAP Server
+   recognizes the permanent identity and is able to proceed, the server
+   issues the EAP-Request/SIM/Challenge message.
+
+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.
+
+
+
+Haverinen & Salowey          Informational                     [Page 30]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 31]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 32]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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,
+
+
+
+Haverinen & Salowey          Informational                     [Page 33]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 34]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+       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
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 35]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 36]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 37]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 38]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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.
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 39]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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.
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 40]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 41]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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
+
+
+
+Haverinen & Salowey          Informational                     [Page 42]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 43]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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
+
+
+
+Haverinen & Salowey          Informational                     [Page 44]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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
+
+
+
+Haverinen & Salowey          Informational                     [Page 45]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 46]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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
+
+
+
+Haverinen & Salowey          Informational                     [Page 47]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+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.
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 48]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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
+
+
+
+Haverinen & Salowey          Informational                     [Page 49]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 50]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 51]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 52]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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.
+
+
+
+Haverinen & Salowey          Informational                     [Page 53]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+              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
+
+
+
+Haverinen & Salowey          Informational                     [Page 54]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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                            |
+    |                                                               |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 55]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 56]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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.
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 57]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 58]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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
+
+
+
+Haverinen & Salowey          Informational                     [Page 59]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 60]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+     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...                    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+    |                                                               |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 61]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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                                 |
+    |                                                               |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 62]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 63]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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.
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 64]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 65]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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
+
+
+
+Haverinen & Salowey          Informational                     [Page 66]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 67]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 68]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 69]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+Haverinen & Salowey          Informational                     [Page 70]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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
+
+
+
+Haverinen & Salowey          Informational                     [Page 71]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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
+
+
+
+Haverinen & Salowey          Informational                     [Page 72]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 73]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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)
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 74]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 75]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 76]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 77]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+15.  References
+
+15.1.  Normative References
+
+   [GSM-03.20]        European Telecommunications Standards  Institute,
+                      "GSM Technical Specification GSM 03.20 (ETS 300
+                      534):  "Digital cellular telecommunication system
+                      (Phase 2); Security related network functions"",
+                      August 1997.
+
+   [RFC2119]          Bradner, S., "Key words for use in RFCs to
+                      Indicate Requirement Levels", BCP 14, RFC 2119,
+                      March 1997.
+
+   [GSM-03.03]        European Telecommunications Standards Institute,
+                      "GSM Technical Specification GSM 03.03 (ETS 300
+                      523): "Digital cellular telecommunication system
+                      (Phase 2); Numbering, addressing and
+                      identification"", April 1997.
+
+   [RFC2104]          Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
+                      Keyed-Hashing for Message Authentication", RFC
+                      2104, February 1997.
+
+   [RFC4282]          Aboba, B., Beadles, M., Arkko, J., and P. Eronen,
+                      "The Network Access Identifier", RFC 4282,
+                      December 2005.
+
+   [AES]              National Institute of  Standards and Technology,
+                      "Federal Information Processing Standards (FIPS)
+                      Publication 197, "Advanced Encryption Standard
+                      (AES)"", November 2001.
+                      http://csrc.nist.gov/publications/fips/fips197/
+                      fips-197.pdf
+
+   [CBC]              National Institute of Standards and Technology,
+                      "NIST Special Publication 800-38A, "Recommendation
+                      for Block Cipher Modes of Operation - Methods and
+                      Techniques"", December 2001.
+                      http://csrc.nist.gov/publications/nistpubs/
+                      800-38a/sp800-38a.pdf
+
+   [SHA-1]            National Institute of Standards and Technology,
+                      U.S.  Department of Commerce, "Federal Information
+                      Processing Standard (FIPS) Publication 180-1,
+                      "Secure Hash Standard"", April 1995.
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 78]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   [PRF]              National Institute of Standards and Technology,
+                      "Federal Information Processing Standards (FIPS)
+                      Publication  186-2 (with change notice); Digital
+                      Signature Standard (DSS)", January 2000.
+                      Available on-line at:
+                      http://csrc.nist.gov/publications/
+                      fips/fips186-2/fips186-2-change1.pdf
+
+   [RFC3629]          Yergeau, F., "UTF-8, a transformation format of
+                      ISO 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3748]          Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
+                      and H. Levkowetz, "Extensible Authentication
+                      Protocol (EAP)", RFC 3748, June 2004.
+
+   [EAP-AKA]          Arkko, J. and H. Haverinen, "Extensible
+                      Authentication Protocol Method for 3rd Generation
+                      Authentication and Key Agreement (EAP-AKA)", RFC
+                      4187, January 2006.
+
+15.2.  Informative References
+
+   [3GPP-TS-23.003]   3rd Generation Partnership Project, "3GPP
+                      Technical Specification 3GPP TS 23.003 V6.8.0:
+                      "3rd Generation Parnership Project; Technical
+                      Specification Group Core Network; Numbering,
+                      addressing and identification (Release 6)"",
+                      December 2005.
+
+   [3GPP-TS-55.205]   3rd Generation Partnership Project, "3GPP
+                      Technical Specification 3GPP TS 55.205 V 6.0.0:
+                      "3rd Generation Partnership Project; Technical
+                      Specification Group Services and System Aspects;
+                      Specification of the GSM-MILENAGE Algorithms: An
+                      example algorithm set for the GSM Authentication
+                      and Key Generation functions A3 and A8 (Release
+                      6)"", December 2002.
+
+   [PEAP]             Palekar, A., Simon, D., Zorn, G., Salowey, J.,
+                      Zhou, H., and S. Josefsson, "Protected EAP
+                      Protocol (PEAP) Version 2", Work in Progress,
+                      October 2004.
+
+   [PEAP-02]          Anderson, H., Josefsson, S., Zorn, G., Simon, D.,
+                      and A. Palekar, "Protected EAP Protocol (PEAP)",
+                      Work in Progress, February 2002.
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 79]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   [EAP-Keying]       Aboba, B., Simon, D., Arkko, J., Eronen, P., and
+                      H.  Levkowetz, "Extensible Authentication Protocol
+                      (EAP) Key Management Framework", Work in Progress,
+                      October 2005.
+
+   [Service-Identity] Arkko, J. and P. Eronen, "Authenticated Service
+                      Information for the Extensible Authentication
+                      Protocol (EAP)", Work in Progress, October 2004.
+
+   [RFC4086]          Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+                      "Randomness Requirements for Security", BCP 106,
+                      RFC 4086, June 2005.
+
+   [S3-020125]        Qualcomm, "Comments on draft EAP/SIM, 3rd
+                      Generation Partnership Project document 3GPP TSG
+                      SA WG3 Security S3#22, S3-020125", February 2002.
+
+   [RFC3344]          Perkins, C., "IP Mobility Support for IPv4", RFC
+                      3344, August 2002.
+
+   [RFC2548]          Zorn, G., "Microsoft Vendor-specific RADIUS
+                      Attributes ", RFC 2548, March 1999.
+
+   [EAP-SRP]          Carlson, J., Aboba, B., and H. Haverinen, "EAP
+                      SRP-SHA1 Authentication Protocol", Work in
+                      Progress, July 2001.
+
+   [GSM-Cloning]      Wagner, D., "GSM Cloning".  Web page about
+                      COMP-128 version 1 vulnerabilities, available at
+                      http://www.isaac.cs.berkeley.edu/isaac/gsm.html
+
+   [Barkan-2003]      Barkan, E., Biham, E., and N. Keller, "Instant
+                      Ciphertext-Only Cryptanalysis of GSM Encrypted
+                      Communications".  available on-line at
+                      http://cryptome.org/gsm-crack-bbk.pdf
+
+   [Patel-2003]       Patel, S., "Analysis of EAP-SIM Session Key
+                      Agreement".  Posted to the EAP mailing list 29
+                      May,2003. http://
+                      mail.frascone.com/pipermail/public/eap/2003-May/
+                      001267.html
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 80]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+Appendix A.  Test Vectors
+
+   Test vectors for the NIST FIPS 186-2 pseudo-random number generator
+   [PRF] are available at the following URL:
+   http://csrc.nist.gov/encryption/dss/Examples-1024bit.pdf
+
+   The following examples show the contents of EAP-SIM packets on full
+   authentication and fast re-authentication.
+
+A.1.  EAP-Request/Identity
+
+   The first packet is a plain Identity Request:
+
+      01                   ; Code: Request
+      00                   ; Identifier: 0
+      00 05                ; Length: 5 octets
+      01                   ; Type: Identity
+
+A.2.  EAP-Response/Identity
+
+   The client's identity is "1244070100000001@eapsim.foo", so it
+   responds with the following packet:
+
+      02                   ; Code: Response
+      00                   ; Identifier: 0
+      00 20                ; Length: 32 octets
+      01                   ; Type: Identity
+         31 32 34 34       ; "1244070100000001@eapsim.foo"
+         30 37 30 31
+         30 30 30 30
+         30 30 30 31
+         40 65 61 70
+         73 69 6d 2e
+         66 6f 6f
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 81]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+A.3.  EAP-Request/SIM/Start
+
+   The server's first packet looks like this:
+
+      01                   ; Code: Request
+      01                   ; Identifier: 1
+      00 10                ; Length: 16 octets
+      12                   ; Type: EAP-SIM
+         0a                ; EAP-SIM subtype: Start
+         00 00             ; (reserved)
+         0f                ; Attribute type: AT_VERSION_LIST
+            02             ; Attribute length: 8 octets (2*4)
+            00 02          ; Actual version list length: 2 octets
+            00 01          ; Version: 1
+            00 00          ; (attribute padding)
+
+A.4.  EAP-Response/SIM/Start
+
+   The client selects a nonce and responds with the following packet:
+
+      02                   ; Code: Response
+      01                   ; Identifier: 1
+      00 20                ; Length: 32 octets
+      12                   ; Type: EAP-SIM
+         0a                ; EAP-SIM subtype: Start
+         00 00             ; (reserved)
+         07                ; Attribute type: AT_NONCE_MT
+            05             ; Attribute length: 20 octets (5*4)
+            00 00          ; (reserved)
+            01 23 45 67    ; NONCE_MT value
+            89 ab cd ef
+            fe dc ba 98
+            76 54 32 10
+         10                ; Attribute type: AT_SELECTED_VERSION
+            01             ; Attribute length: 4 octets (1*4)
+            00 01          ; Version: 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 82]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+A.5.  EAP-Request/SIM/Challenge
+
+   Next, the server selects three authentication triplets
+
+         (RAND1,SRES1,Kc1) = (10111213 14151617 18191a1b 1c1d1e1f,
+                              d1d2d3d4,
+                              a0a1a2a3 a4a5a6a7)
+         (RAND2,SRES2,Kc2) = (20212223 24252627 28292a2b 2c2d2e2f,
+                              e1e2e3e4,
+                              b0b1b2b3 b4b5b6b7)
+         (RAND3,SRES3,Kc3) = (30313233 34353637 38393a3b 3c3d3e3f,
+                              f1f2f3f4,
+                              c0c1c2c3 c4c5c6c7)
+
+   Next, the MK is calculated as specified in Section 7*.
+
+   MK = e576d5ca 332e9930 018bf1ba ee2763c7 95b3c712
+
+   And the other keys are derived using the PRNG:
+
+         K_encr = 536e5ebc 4465582a a6a8ec99 86ebb620
+         K_aut =  25af1942 efcbf4bc 72b39434 21f2a974
+         MSK =    39d45aea f4e30601 983e972b 6cfd46d1
+                  c3637733 65690d09 cd44976b 525f47d3
+                  a60a985e 955c53b0 90b2e4b7 3719196a
+                  40254296 8fd14a88 8f46b9a7 886e4488
+         EMSK =   5949eab0 fff69d52 315c6c63 4fd14a7f
+                  0d52023d 56f79698 fa6596ab eed4f93f
+                  bb48eb53 4d985414 ceed0d9a 8ed33c38
+                  7c9dfdab 92ffbdf2 40fcecf6 5a2c93b9
+
+   Next, the server selects a pseudonym and a fast re-authentication
+   identity (in this case, "w8w49PexCazWJ&xCIARmxuMKht5S1sxR
+   DqXSEFBEg3DcZP9cIxTe5J4OyIwNGVzxeJOU1G" and
+   "Y24fNSrz8BP274jOJaF17WfxI8YO7QX0
+   0pMXk9XMMVOw7broaNhTczuFq53aEpOkk3L0dm@eapsim.foo", respectively).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 83]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   The following plaintext will be encrypted and stored in the
+   AT_ENCR_DATA attribute:
+
+         84               ; Attribute type: AT_NEXT_PSEUDONYM
+            13            ; Attribute length: 76 octets (19*4)
+            00 46         ; Actual pseudonym length: 70 octets
+            77 38 77 34 39 50 65 78 43 61 7a 57 4a 26 78 43
+            49 41 52 6d 78 75 4d 4b 68 74 35 53 31 73 78 52
+            44 71 58 53 45 46 42 45 67 33 44 63 5a 50 39 63
+            49 78 54 65 35 4a 34 4f 79 49 77 4e 47 56 7a 78
+            65 4a 4f 55 31 47
+            00 00          ; (attribute padding)
+         85                ; Attribute type: AT_NEXT_REAUTH_ID
+            16             ; Attribute length: 88 octets (22*4)
+            00 51          ; Actual re-auth identity length: 81 octets
+            59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f
+            4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30
+            30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f
+            61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b
+            6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f
+            6f
+            00 00 00       ; (attribute padding)
+         06                ; Attribute type: AT_PADDING
+            03             ; Attribute length: 12 octets (3*4)
+            00 00 00 00
+            00 00 00 00
+            00 00
+
+   The EAP packet looks like this:
+
+      01                   ; Code: Request
+      02                   ; Identifier: 2
+      01 18                ; Length: 280 octets
+      12                   ; Type: EAP-SIM
+         0b                ; EAP-SIM subtype: Challenge
+         00 00             ; (reserved)
+         01                ; Attribute type: AT_RAND
+            0d             ; Attribute length: 52 octets (13*4)
+            00 00          ; (reserved)
+            10 11 12 13    ; first RAND
+            14 15 16 17
+            18 19 1a 1b
+            1c 1d 1e 1f
+            20 21 22 23    ; second RAND
+            24 25 26 27
+            28 29 2a 2b
+            2c 2d 2e 2f
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 84]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+            30 31 32 33    ; third RAND
+            34 35 36 37
+            38 39 3a 3b
+            3c 3d 3e 3f
+         81                ; Attribute type: AT_IV
+            05             ; Attribute length: 20 octets (5*4)
+            00 00          ; (reserved)
+            9e 18 b0 c2    ; IV value
+            9a 65 22 63
+            c0 6e fb 54
+            dd 00 a8 95
+         82               ; Attribute type: AT_ENCR_DATA
+            2d            ; Attribute length: 180 octets (45*4)
+            00 00         ; (reserved)
+            55 f2 93 9b bd b1 b1 9e a1 b4 7f c0 b3 e0 be 4c
+            ab 2c f7 37 2d 98 e3 02 3c 6b b9 24 15 72 3d 58
+            ba d6 6c e0 84 e1 01 b6 0f 53 58 35 4b d4 21 82
+            78 ae a7 bf 2c ba ce 33 10 6a ed dc 62 5b 0c 1d
+            5a a6 7a 41 73 9a e5 b5 79 50 97 3f c7 ff 83 01
+            07 3c 6f 95 31 50 fc 30 3e a1 52 d1 e1 0a 2d 1f
+            4f 52 26 da a1 ee 90 05 47 22 52 bd b3 b7 1d 6f
+            0c 3a 34 90 31 6c 46 92 98 71 bd 45 cd fd bc a6
+            11 2f 07 f8 be 71 79 90 d2 5f 6d d7 f2 b7 b3 20
+            bf 4d 5a 99 2e 88 03 31 d7 29 94 5a ec 75 ae 5d
+            43 c8 ed a5 fe 62 33 fc ac 49 4e e6 7a 0d 50 4d
+         0b                ; Attribute type: AT_MAC
+            05             ; Attribute length: 20 octets (5*4)
+            00 00          ; (reserved)
+            fe f3 24 ac    ; MAC value
+            39 62 b5 9f
+            3b d7 82 53
+            ae 4d cb 6a
+
+   The MAC is calculated over the EAP packet above (with MAC value set
+   to zero), followed by the NONCE_MT value (a total of 296 bytes).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 85]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+A.6.  EAP-Response/SIM/Challenge
+
+   The client's response looks like this:
+
+      02                   ; Code: Response
+      02                   ; Identifier: 2
+      00 1c                ; Length: 28 octets
+      12                   ; Type: EAP-SIM
+         0b                ; EAP-SIM subtype: Challenge
+         00 00             ; (reserved)
+         0b                ; Attribute type: AT_MAC
+            05             ; Attribute length: 20 octets (5*4)
+            00 00          ; (reserved)
+            f5 6d 64 33    ; MAC value
+            e6 8e d2 97
+            6a c1 19 37
+            fc 3d 11 54
+
+   The MAC is calculated over the EAP packet above (with MAC value set
+   to zero), followed by the SRES values (a total of 40 bytes).
+
+A.7.  EAP-Success
+
+   The last packet is an EAP-Success:
+
+      03                   ; Code: Success
+      02                   ; Identifier: 2
+      00 04                ; Length: 4 octets
+
+A.8.  Fast Re-authentication
+
+   When performing fast re-authentication, the EAP-Request/Identity
+   packet is the same as usual.  The EAP-Response/Identity contains the
+   fast re-authentication identity (from AT_ENCR_DATA attribute above):
+
+      02                   ; Code: Response
+      00                   ; Identifier: 0
+      00 56                ; Length: 86 octets
+      01                   ; Type: Identity
+         59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f
+         4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30
+         30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f
+         61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b
+         6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f
+         6f
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 86]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+A.9.  EAP-Request/SIM/Re-authentication
+
+   The server recognizes the reauthentication identity, so it will
+   respond with EAP-Request/SIM/Re-authentication.  It retrieves the
+   associated counter value, generates a nonce, and picks a new
+   reauthentication identity (in this case,
+   "uta0M0iyIsMwWp5TTdSdnOLvg2XDVf21OYt1vnfiMcs5dnIDHOIFVavIRzMR
+   yzW6vFzdHW@eapsim.foo").
+
+   The following plaintext will be encrypted and stored in the
+   AT_ENCR_DATA attribute.  Note that AT_PADDING is not used because the
+   length of the plaintext is a multiple of 16 bytes.
+
+         13                ; Attribute type: AT_COUNTER
+            01             ; Attribute length: 4 octets (1*4)
+            00 01          ; Counter value
+         15                ; Attribute type: AT_NONCE_S
+            05             ; Attribute length: 20 octets (5*4)
+            00 00          ; (reserved)
+            01 23 45 67    ; NONCE_S value
+            89 ab cd ef
+            fe dc ba 98
+            76 54 32 10
+         85                ; Attribute type: AT_NEXT_REAUTH_ID
+            16             ; Attribute length: 88 octets (22*4)
+            00 51          ; Actual re-auth identity length: 81 octets
+            75 74 61 30 4d 30 69 79 49 73 4d 77 57 70 35 54
+            54 64 53 64 6e 4f 4c 76 67 32 58 44 56 66 32 31
+            4f 59 74 31 76 6e 66 69 4d 63 73 35 64 6e 49 44
+            48 4f 49 46 56 61 76 49 52 7a 4d 52 79 7a 57 36
+            76 46 7a 64 48 57 40 65 61 70 73 69 6d 2e 66 6f
+            6f
+            00 00 00       ; (attribute padding)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 87]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   The EAP packet looks like this:
+
+      01                   ; Code: Request
+      01                   ; Identifier: 1
+      00 a4                ; Length: 164 octets
+      12                   ; Type: EAP-SIM
+         0d                ; EAP-SIM subtype: Re-authentication
+         00 00             ; (reserved)
+         81                ; Attribute type: AT_IV
+            05             ; Attribute length: 20 octets (5*4)
+            00 00          ; (reserved)
+            d5 85 ac 77    ; IV value
+            86 b9 03 36
+            65 7c 77 b4
+            65 75 b9 c4
+         82                ; Attribute type: AT_ENCR_DATA
+            1d             ; Attribute length: 116 octets (29*4)
+            00 00          ; (reserved)
+            68 62 91 a9 d2 ab c5 8c aa 32 94 b6 e8 5b 44 84
+            6c 44 e5 dc b2 de 8b 9e 80 d6 9d 49 85 8a 5d b8
+            4c dc 1c 9b c9 5c 01 b9 6b 6e ca 31 34 74 ae a6
+            d3 14 16 e1 9d aa 9d f7 0f 05 00 88 41 ca 80 14
+            96 4d 3b 30 a4 9b cf 43 e4 d3 f1 8e 86 29 5a 4a
+            2b 38 d9 6c 97 05 c2 bb b0 5c 4a ac e9 7d 5e af
+            f5 64 04 6c 8b d3 0b c3 9b e5 e1 7a ce 2b 10 a6
+         0b                ; Attribute type: AT_MAC
+            05             ; Attribute length: 20 octets (5*4)
+            00 00          ; (reserved)
+            48 3a 17 99    ; MAC value
+            b8 3d 7c d3
+            d0 a1 e4 01
+            d9 ee 47 70
+
+   The MAC is calculated over the EAP packet above (with MAC value set
+   to zero; a total of 164 bytes).
+
+   Finally, the server derives new keys.  The XKEY' is calculated as
+   described in Section 7*:
+
+   XKEY' = 863dc120 32e08343 c1a2308d b48377f6 801f58d4
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 88]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+   The new MSK and EMSK are derived using the PRNG (note that K_encr and
+   K_aut stay the same).
+
+         MSK   =  6263f614 973895e1 335f7e30 cff028ee
+                  2176f519 002c9abe 732fe0ef 00cf167c
+                  756d9e4c ed6d5ed6 40eb3fe3 8565ca07
+                  6e7fb8a8 17cfe8d9 adbce441 d47c4f5e
+         EMSK  =  3d8ff786 3a630b2b 06e2cf20 9684c13f
+                  6b82f992 f2b06f1b 54bf51ef 237f2a40
+                  1ef5e0d7 e098a34c 533eaebf 34578854
+                  b7721526 20a777f0 e0340884 a294fb73
+
+A.10.  EAP-Response/SIM/Re-authentication
+
+   The client's response includes the counter as well.  The following
+   plaintext will be encrypted and stored in the AT_ENCR_DATA attribute:
+
+         13                ; Attribute type: AT_COUNTER
+            01             ; Attribute length: 4 octets (1*4)
+            00 01          ; Counter value
+         06                ; Attribute type: AT_PADDING
+            03             ; Attribute length: 12 octets (3*4)
+            00 00 00 00
+            00 00 00 00
+            00 00
+
+   The EAP packet looks like this:
+
+      02                   ; Code: Response
+      01                   ; Identifier: 1
+      00 44                ; Length: 68 octets
+      12                   ; Type: EAP-SIM
+         0d                ; EAP-SIM subtype: Re-authentication
+         00 00             ; (reserved)
+         81                ; Attribute type: AT_IV
+            05             ; Attribute length: 20 octets (5*4)
+            00 00          ; (reserved)
+            cd f7 ff a6    ; IV value
+            5d e0 4c 02
+            6b 56 c8 6b
+            76 b1 02 ea
+         82                ; Attribute type: AT_ENCR_DATA
+            05             ; Attribute length: 20 octets (5*4)
+            00 00          ; (reserved)
+            b6 ed d3 82
+            79 e2 a1 42
+            3c 1a fc 5c
+            45 5c 7d 56
+
+
+
+Haverinen & Salowey          Informational                     [Page 89]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+         0b                ; Attribute type: AT_MAC
+            05             ; Attribute length: 20 octets (5*4)
+            00 00          ; (reserved)
+            fa f7 6b 71    ; MAC value
+            fb e2 d2 55
+            b9 6a 35 66
+            c9 15 c6 17
+
+   The MAC is calculated over the EAP packet above (with MAC value set
+   to zero), followed by the NONCE_S value (a total of 84 bytes).
+
+   The next packet will be EAP-Success:
+
+      03                   ; Code: Success
+      01                   ; Identifier: 1
+      00 04                ; Length: 4 octets
+
+Appendix B.  Pseudo-Random Number Generator
+
+   The "|" character denotes concatenation, and "^" denotes
+   exponentiation.
+
+   Step 1: Choose a new, secret value for the seed-key, XKEY
+
+   Step 2: In hexadecimal notation let
+       t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0
+       This is the initial value for H0|H1|H2|H3|H4
+       in the FIPS SHS [SHA-1]
+
+   Step 3: For j = 0 to m - 1 do
+         3.1 XSEED_j = 0 /* no optional user input */
+         3.2 For i = 0 to 1 do
+             a. XVAL = (XKEY + XSEED_j) mod 2^b
+             b. w_i = G(t, XVAL)
+             c. XKEY = (1 + XKEY + w_i) mod 2^b
+         3.3 x_j = w_0|w_1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 90]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+Authors' Addresses
+
+   Henry Haverinen (editor)
+   Nokia Enterprise Solutions
+   P.O. Box 12
+   FIN-40101 Jyvaskyla
+   Finland
+
+   EMail: henry.haverinen@nokia.com
+
+
+   Joseph Salowey (editor)
+   Cisco Systems
+   2901 Third Avenue
+   Seattle, WA  98121
+   USA
+
+   Phone: +1 206 256 3380
+   EMail: jsalowey@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 91]
+\f
+RFC 4186                 EAP-SIM Authentication             January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Haverinen & Salowey          Informational                     [Page 92]
+\f
index 435aa9d..a4d8abb 100644 (file)
@@ -41,7 +41,9 @@ ENUM_BEGIN(eap_type_names, EAP_IDENTITY, EAP_TOKEN_CARD,
        "EAP_MD5",
        "EAP_ONE_TIME_PASSWORD",
        "EAP_TOKEN_CARD");
-ENUM_NEXT(eap_type_names, EAP_AKA, EAP_AKA, EAP_TOKEN_CARD,
+ENUM_NEXT(eap_type_names, EAP_SIM, EAP_SIM, EAP_TOKEN_CARD,
+       "EAP_SIM");
+ENUM_NEXT(eap_type_names, EAP_AKA, EAP_AKA, EAP_SIM,
        "EAP_AKA");
 ENUM_END(eap_type_names, EAP_AKA);
 
index 2b09c0f..d43dc00 100644 (file)
@@ -60,6 +60,7 @@ enum eap_type_t {
        EAP_MD5 = 4,
        EAP_ONE_TIME_PASSWORD = 5,
        EAP_TOKEN_CARD = 6,
+       EAP_SIM = 18,
        EAP_AKA = 23,
 };
 
diff --git a/src/charon/sa/authenticators/eap/eap_sim.c b/src/charon/sa/authenticators/eap/eap_sim.c
new file mode 100644 (file)
index 0000000..21f6fb2
--- /dev/null
@@ -0,0 +1,677 @@
+/**
+ * @file eap_sim.c
+ *
+ * @brief Implementation of eap_sim_t.
+ *
+ */
+
+/*
+ * Copyright (C) 2007 Martin Willi
+ * Hochschule fuer Technik Rapperswil
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.  See <http://www.fsf.org/copyleft/gpl.txt>.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * for more details.
+ */
+
+#include "eap_sim.h"
+
+#include <dlfcn.h>
+
+#include <daemon.h>
+#include <library.h>
+
+ENUM(sim_subtype_names, SIM_START, SIM_CLIENT_ERROR,
+       "SIM_START",
+       "SIM_CHALLENGE",
+       "SIM_NOTIFICATION",
+       "SIM_13",
+       "SIM_CLIENT_ERROR",
+);
+
+ENUM_BEGIN(sim_attribute_names, AT_END, AT_CLIENT_ERROR_CODE,
+       "AT_END",
+       "AT_0",
+       "AT_RAND",
+       "AT_AUTN",
+       "AT_RES",
+       "AT_AUTS",
+       "AT_5",
+       "AT_PADDING",
+       "AT_NONCE_MT",
+       "AT_8",
+       "AT_9",
+       "AT_PERMANENT_ID_REQ",
+       "AT_MAC",
+       "AT_NOTIFICATION",
+       "AT_ANY_ID_REQ",
+       "AT_IDENTITY",
+       "AT_VERSION_LIST",
+       "AT_SELECTED_VERSION",
+       "AT_FULLAUTH_ID_REQ",
+       "AT_18",
+       "AT_COUNTER",
+       "AT_COUNTER_TOO_SMALL",
+       "AT_NONCE_S",
+       "AT_CLIENT_ERROR_CODE");
+ENUM_NEXT(sim_attribute_names, AT_IV, AT_RESULT_IND, AT_CLIENT_ERROR_CODE,
+       "AT_IV",
+       "AT_ENCR_DATA",
+       "AT_131",
+       "AT_NEXT_PSEUDONYM",
+       "AT_NEXT_REAUTH_ID",
+       "AT_CHECKCODE",
+       "AT_RESULT_IND");
+ENUM_END(sim_attribute_names, AT_RESULT_IND);
+
+
+typedef struct private_eap_sim_t private_eap_sim_t;
+
+/**
+ * Private data of an eap_sim_t object.
+ */
+struct private_eap_sim_t {
+       
+       /**
+        * Public authenticator_t interface.
+        */
+       eap_sim_t public;
+       
+       /**
+        * ID of ourself
+        */
+       identification_t *peer;
+       
+       /**
+        * SIM cardreader function loaded from library
+        */
+       sim_algo_t alg;
+       
+       /**
+        * handle of the loaded library
+        */
+       void *handle;
+       
+       /**
+        * version this implementation uses
+        */
+       chunk_t version;
+       
+       /**
+        * version list received from server
+        */
+       chunk_t version_list;
+       
+       /**
+        * Nonce value used in AT_NONCE_MT
+        */
+       chunk_t nonce;
+       
+       /**
+        * k_encr key derived from MK
+        */
+       chunk_t k_encr;
+       
+       /**
+        * k_auth key derived from MK, used for AT_MAC verification
+        */
+       chunk_t k_auth;
+       
+       /**
+        * MSK, used for EAP-SIM based IKEv2 authentication
+        */
+       chunk_t msk;
+       
+       /**
+        * EMSK, extendes MSK for further uses
+        */
+       chunk_t emsk;
+};
+
+/** length of the AT_NONCE_MT nonce value */
+#define NONCE_LEN 16
+/** length of the AT_MAC value */
+#define MAC_LEN 16
+/** length of the AT_RAND value */
+#define RAND_LEN 16
+/** length of the k_encr key */
+#define KENCR_LEN 16
+/** length of the k_Auth value */
+#define KAUTH_LEN 16
+/** length of the MSK */
+#define MSK_LEN 64
+/** length of the EMSK */
+#define EMSK_LEN 64
+
+/* client error codes used in AT_CLIENT_ERROR_CODE */
+char client_error_general_buf[] = {0x00, 0x01};
+char client_error_unsupported_buf[] = {0x00, 0x02};
+char client_error_insufficient_buf[] = {0x00, 0x03};
+char client_error_notfresh_buf[] = {0x00, 0x04};
+chunk_t client_error_general = chunk_from_buf(client_error_general_buf);
+chunk_t client_error_unsupported = chunk_from_buf(client_error_unsupported_buf);
+chunk_t client_error_insufficient = chunk_from_buf(client_error_insufficient_buf);
+chunk_t client_error_notfresh = chunk_from_buf(client_error_notfresh_buf);
+
+/**
+ * Read EAP and EAP-SIM header, return SIM type
+ */
+static sim_subtype_t read_header(chunk_t *message)
+{
+       sim_subtype_t type;
+
+       if (message->len < 8)
+       {
+               *message = chunk_empty;
+               return 0;
+       }
+       type = *(message->ptr + 5);
+       *message = chunk_skip(*message, 8);
+       return type;
+}
+
+/**
+ * read the next attribute from the chunk data
+ */
+static sim_attribute_t read_attribute(chunk_t *message, chunk_t *data)
+{
+       sim_attribute_t attribute;
+       size_t length;
+       
+       DBG3(DBG_IKE, "reading attribute from %B", message);
+       
+       if (message->len < 2)
+       {
+               return AT_END;
+       }
+       attribute = *message->ptr++;
+       length = *message->ptr++ * 4 - 2;
+       message->len -= 2;
+       DBG3(DBG_IKE, "found attribute %N with length %d",
+                sim_attribute_names, attribute, length);
+
+       if (length > message->len)
+       {
+               return AT_END;
+       }
+       data->len = length;
+       data->ptr = message->ptr;
+       *message = chunk_skip(*message, length);
+       return attribute;
+}
+
+/**
+ * Build an EAP-SIM payload using a variable length attribute list.
+ * The variable argument takes a sim_attribute_t followed by its data in a chunk.
+ */
+static eap_payload_t *build_payload(private_eap_sim_t *this, u_int8_t identifier,
+                                                                       sim_subtype_t type, ...)
+{
+       chunk_t message = chunk_alloca(512);
+       chunk_t pos = message;
+       eap_payload_t *payload;
+       va_list args;
+       sim_attribute_t attr;
+       u_int8_t *mac_pos = NULL;
+       chunk_t mac_data = chunk_empty;
+       
+       /* write EAP header, skip length bytes */
+       *pos.ptr++ = EAP_RESPONSE;
+       *pos.ptr++ = identifier;
+       pos.ptr += 2;
+       pos.len -= 4;
+       /* write SIM header with type and subtype, zero reserved bytes */
+       *pos.ptr++ = EAP_SIM;
+       *pos.ptr++ = type;
+       *pos.ptr++ = 0;
+       *pos.ptr++ = 0;
+       pos.len -= 4;
+       
+       va_start(args, type);
+       while ((attr = va_arg(args, sim_attribute_t)) != AT_END)
+       {
+               chunk_t data = va_arg(args, chunk_t);
+               
+               DBG3(DBG_IKE, "building %N %B", sim_attribute_names, attr, &data);
+               
+               /* write attribute header */
+               *pos.ptr++ = attr;
+               pos.len--;
+               
+               switch (attr)
+               {
+                       case AT_CLIENT_ERROR_CODE:
+                       case AT_SELECTED_VERSION:
+                       {
+                               *pos.ptr = data.len/4 + 1;
+                               pos = chunk_skip(pos, 1);
+                               memcpy(pos.ptr, data.ptr, data.len);
+                               pos = chunk_skip(pos, data.len);
+                               break;
+                       }
+                       case AT_IDENTITY:
+                       {
+                               *pos.ptr = data.len/4 + 1;
+                               pos = chunk_skip(pos, 1);
+                               /* actual length in bytes */
+                               *(u_int16_t*)pos.ptr = htons(data.len);
+                               pos = chunk_skip(pos, sizeof(u_int16_t));
+                               memcpy(pos.ptr, data.ptr, data.len);
+                               pos = chunk_skip(pos, data.len);
+                               break;
+                       }
+                       case AT_NONCE_MT:
+                       {
+                               *pos.ptr = data.len/4 + 1;
+                               pos = chunk_skip(pos, 1);
+                               memset(pos.ptr, 0, 2);
+                               pos = chunk_skip(pos, 2);
+                               memcpy(pos.ptr, data.ptr, data.len);
+                               pos = chunk_skip(pos, data.len);
+                               break;
+                       }
+                       case AT_MAC:
+                       {
+                               *pos.ptr++ = 5; pos.len--;
+                               *pos.ptr++ = 0; pos.len--;
+                               *pos.ptr++ = 0; pos.len--;
+                               mac_pos = pos.ptr;
+                               memset(mac_pos, 0, MAC_LEN);
+                               pos = chunk_skip(pos, MAC_LEN);
+                               mac_data = data;
+                               break;
+                       }
+                       case AT_RAND:
+                       {
+                               *pos.ptr++ = data.len/4 + 1; pos.len--;
+                               *pos.ptr++ = 0; pos.len--;
+                               *pos.ptr++ = 0; pos.len--;
+                               memcpy(pos.ptr, data.ptr, data.len);
+                               pos = chunk_skip(pos, data.len);
+                               break;
+                       }
+                       default:
+                               DBG1(DBG_IKE, "no rule to build EAP_SIM attribute %N, skipped",
+                                        sim_attribute_names, attr);
+                               break;
+               }
+       }
+       va_end(args);
+       
+       /* calculate message length, write into header */
+       message.len = pos.ptr - message.ptr;
+       *(u_int16_t*)(message.ptr + 2) = htons(message.len);
+       
+       /* create MAC if AT_MAC attribte was included. Append supplied va_arg
+        * chunk mac_data to "to-sign" chunk */
+       if (mac_pos)
+       {
+               signer_t *signer = signer_create(AUTH_HMAC_SHA1_128);
+               signer->set_key(signer, this->k_auth);
+               mac_data = chunk_cata("cc", message, mac_data);
+               DBG3(DBG_IKE, "AT_MAC signature of %B", &mac_data);
+               DBG3(DBG_IKE, "using k_auth %B", &this->k_auth);
+               signer->get_signature(signer, mac_data, mac_pos);
+               DBG3(DBG_IKE, "is %b", mac_pos, MAC_LEN);
+               signer->destroy(signer);
+       }
+       
+       payload = eap_payload_create_data(message);
+       
+       DBG3(DBG_IKE, "created EAP message %B", &message);
+       return payload;
+}
+
+/**
+ * process an EAP-SIM/Request/Start message
+ */
+static status_t process_start(private_eap_sim_t *this, eap_payload_t *in,
+                                                         eap_payload_t **out)
+{
+       chunk_t message, data;
+       sim_attribute_t attribute, include_id = AT_END;
+       u_int8_t identifier;
+
+       identifier = in->get_identifier(in);
+       message = in->get_data(in);
+       read_header(&message);
+
+       while ((attribute = read_attribute(&message, &data)) != AT_END)
+       {
+               switch (attribute)
+               {
+                       case AT_VERSION_LIST:
+                       {
+                               /* check if server supports our implementation */
+                               bool found = FALSE;
+                               if (data.len > 2)
+                               {
+                                       /* read actual length first */
+                                       data.len = ntohs(*(u_int16_t*)data.ptr);
+                                       data = chunk_skip(data, 2);
+                                       this->version_list = chunk_clone(data);
+                                       while (data.len >= this->version.len)
+                                       {
+                                               if (memeq(data.ptr, this->version.ptr, this->version.len))
+                                               {
+                                                       found = TRUE;
+                                                       break;
+                                               }
+                                               data = chunk_skip(data, this->version.len);
+                                       }
+                               }
+                               if (!found)
+                               {
+                                       DBG1(DBG_IKE, "server does not support EAP_SIM "
+                                                "version number %#B", &this->version);
+                                       *out = build_payload(this, identifier, SIM_CLIENT_ERROR,
+                                                       AT_CLIENT_ERROR_CODE, client_error_unsupported,
+                                                       AT_END);
+                                       return FAILED;
+                               }
+                               break;
+                       }
+                       case AT_PERMANENT_ID_REQ:
+                       case AT_FULLAUTH_ID_REQ:
+                       case AT_ANY_ID_REQ:
+                               /* only include AT_IDENTITY if requested */
+                               include_id = AT_IDENTITY;
+                               break;
+                       default:
+                               DBG1(DBG_IKE, "ignoring EAP_SIM attribute %N",
+                                        sim_attribute_names, attribute);
+                               break;
+               }
+       }
+       
+       /* build payload. If "include_id" is AT_END, AT_IDENTITY is ommited */
+       *out = build_payload(this, identifier, SIM_START,
+                                                AT_SELECTED_VERSION, this->version,
+                                                AT_NONCE_MT, this->nonce,
+                                                include_id, this->peer->get_encoding(this->peer),
+                                                AT_END);
+       return NEED_MORE;
+}
+
+/**
+ * process an EAP-SIM/Request/Challenge message
+ */
+static status_t process_challenge(private_eap_sim_t *this, eap_payload_t *in,
+                                                                 eap_payload_t **out)
+{
+       chunk_t message, data, tmp, kcs, kc, sreses, sres, mk;
+       sim_attribute_t attribute;
+       u_int8_t identifier;
+       chunk_t mac = chunk_empty, rands = chunk_empty;
+       signer_t *signer;
+       hasher_t *hasher;
+       prf_t *prf;
+
+       identifier = in->get_identifier(in);
+       message = in->get_data(in);
+       read_header(&message);
+
+       while ((attribute = read_attribute(&message, &data)) != AT_END)
+       {
+               switch (attribute)
+               {
+                       case AT_RAND:
+                       {
+                               rands = chunk_skip(data, 2);
+                               break;
+                       }
+                       case AT_MAC:
+                       {
+                               /* backup MAC, zero it inline for later verification */
+                               mac = chunk_clonea(chunk_skip(data, 2));
+                               memset(data.ptr, 0, data.len);
+                               break;
+                       }
+                       default:
+                               DBG1(DBG_IKE, "ignoring EAP_SIM attribute %N",
+                                        sim_attribute_names, attribute);
+                               break;
+               }
+       }
+       
+       /* excepting two or three RAND, each 16 bytes. We require two valid
+        * and different (!) RANDs */
+       if ((rands.len != 2 * RAND_LEN && rands.len != 3 * RAND_LEN) ||
+               memeq(rands.ptr, rands.ptr + RAND_LEN, RAND_LEN))
+       {
+               DBG1(DBG_IKE, "no valid AT_RAND received");
+               *out = build_payload(this, identifier, SIM_CLIENT_ERROR,
+                                                        AT_CLIENT_ERROR_CODE, client_error_insufficient,
+                                                        AT_END);
+               return FAILED;
+       }
+       if (mac.len != MAC_LEN)
+       {
+               DBG1(DBG_IKE, "no valid AT_MAC received");
+               *out = build_payload(this, identifier, SIM_CLIENT_ERROR,
+                                                        AT_CLIENT_ERROR_CODE, client_error_general,
+                                                        AT_END);
+               return FAILED;
+       }
+       
+       /* get two or three KCs/SRESes from SIM using RANDs */
+       kcs = kc = chunk_alloca(rands.len / 2);
+       sreses = sres = chunk_alloca(kcs.len / 2);
+       while (rands.len > 0)
+       {
+               if (this->alg(rands.ptr, RAND_LEN, kc.ptr, &kc.len, sres.ptr, &sres.len))
+               {
+                       DBG1(DBG_IKE, "unable to get triplets from SIM");
+                       *out = build_payload(this, identifier, SIM_CLIENT_ERROR,
+                                                                AT_CLIENT_ERROR_CODE, client_error_general,
+                                                                AT_END);
+                       return FAILED;
+               }
+               kc = chunk_skip(kc, kc.len);
+               sres = chunk_skip(sres, sres.len);
+               rands = chunk_skip(rands, RAND_LEN);
+       }
+       
+       /* build MK */
+       tmp = chunk_cata("ccccc", this->peer->get_encoding(this->peer), kcs,
+                                        this->nonce, this->version_list, this->version);
+       hasher = hasher_create(HASH_SHA1);
+       mk = chunk_alloca(hasher->get_hash_size(hasher));
+       hasher->get_hash(hasher, tmp, mk.ptr);
+       hasher->destroy(hasher);
+       
+       /* K_encr | K_auth | MSK | EMSK = prf() | prf() | prf() | prf()
+        * FIPS PRF has 320 bit block size, we need 160 byte for keys
+        *  => run prf four times */
+       prf = prf_create(PRF_FIPS_SHA1_160);
+       prf->set_key(prf, mk);
+       tmp = chunk_alloca(prf->get_block_size(prf) * 4);
+       prf->get_bytes(prf, chunk_empty, tmp.ptr);
+       prf->get_bytes(prf, chunk_empty, tmp.ptr + tmp.len / 4 * 1);
+       prf->get_bytes(prf, chunk_empty, tmp.ptr + tmp.len / 4 * 2);
+       prf->get_bytes(prf, chunk_empty, tmp.ptr + tmp.len / 4 * 3);
+       prf->destroy(prf);
+       chunk_split(tmp, "aaaa", KENCR_LEN, &this->k_encr, KAUTH_LEN, &this->k_auth,
+                               MSK_LEN, &this->msk, EMSK_LEN, &this->emsk);
+       DBG3(DBG_IKE, "MK %B", &mk);
+       DBG3(DBG_IKE, "PRF res %B", &tmp);
+       DBG3(DBG_IKE, "K_encr %B", &this->k_encr);
+       DBG3(DBG_IKE, "K_auth %B", &this->k_auth);
+       DBG3(DBG_IKE, "MSK %B", &this->msk);
+       DBG3(DBG_IKE, "EMSK %B", &this->emsk);
+       
+       /* verify AT_MAC attribute, signature is over "EAP packet | NONCE_MT"  */
+       signer = signer_create(AUTH_HMAC_SHA1_128);
+       signer->set_key(signer, this->k_auth);
+       tmp = chunk_cata("cc", message, this->nonce);
+       DBG3(DBG_IKE, "verifying AT_MAC signature of %B", &tmp);
+       DBG3(DBG_IKE, "using k_auth %B", &this->k_auth);
+       if (!signer->verify_signature(signer, tmp, mac))
+       {
+               DBG1(DBG_IKE, "MAC in AT_MAC attribute verification failed");
+               signer->destroy(signer);
+               chunk_free(&this->msk);
+               *out = build_payload(this, identifier, SIM_CLIENT_ERROR,
+                                                        AT_CLIENT_ERROR_CODE, client_error_general,
+                                                        AT_END);
+               return FAILED;
+       }
+       signer->destroy(signer);
+       
+       /* build response, AT_MAC is built over "EAP packet | n*SRES" */
+       *out = build_payload(this, identifier, SIM_CHALLENGE,
+                                                AT_MAC, sreses,
+                                                AT_END);
+       return NEED_MORE;
+}
+
+/**
+ * Implementation of eap_method_t.process for the peer
+ */
+static status_t process(private_eap_sim_t *this,
+                                               eap_payload_t *in, eap_payload_t **out)
+{
+       sim_subtype_t type;
+       chunk_t message;
+       
+       message = in->get_data(in);
+       type = read_header(&message);
+       
+       switch (type)
+       {
+               case SIM_START:
+                       return process_start(this, in, out);
+               case SIM_CHALLENGE:
+                       return process_challenge(this, in, out);
+               default:
+                       DBG1(DBG_IKE, "unable to process EAP_SIM subtype %N",
+                                sim_subtype_names, type);
+                       *out = build_payload(this, in->get_identifier(in), SIM_CLIENT_ERROR,
+                                       AT_CLIENT_ERROR_CODE, client_error_general, AT_END);
+                       return NEED_MORE;
+       }
+}
+
+/**
+ * Implementation of eap_method_t.initiate for the peer
+ */
+static status_t initiate(private_eap_sim_t *this, eap_payload_t **out)
+{
+       /* peer never initiates */
+       return FAILED;
+}
+
+/**
+ * Implementation of eap_method_t.get_type.
+ */
+static eap_type_t get_type(private_eap_sim_t *this)
+{
+       return EAP_SIM;
+}
+
+/**
+ * Implementation of eap_method_t.get_msk.
+ */
+static status_t get_msk(private_eap_sim_t *this, chunk_t *msk)
+{
+       if (this->msk.ptr)
+       {
+               *msk = this->msk;
+               return SUCCESS;
+       }
+       return FAILED;
+}
+
+/**
+ * Implementation of eap_method_t.is_mutual.
+ */
+static bool is_mutual(private_eap_sim_t *this)
+{
+       return TRUE;
+}
+
+/**
+ * Implementation of eap_method_t.destroy.
+ */
+static void destroy(private_eap_sim_t *this)
+{
+       dlclose(this->handle);
+       chunk_free(&this->nonce);
+       chunk_free(&this->version_list);
+       chunk_free(&this->k_auth);
+       chunk_free(&this->k_encr);
+       chunk_free(&this->msk);
+       chunk_free(&this->emsk);
+       free(this);
+}
+
+/*
+ * Described in header.
+ */
+eap_sim_t *eap_create(eap_role_t role,
+                                         identification_t *server, identification_t *peer)
+{
+       private_eap_sim_t *this;
+       randomizer_t *randomizer;
+       static char version[] = {0x00,0x01};
+       
+       if (role != EAP_PEER)
+       {
+               return NULL;
+       }       
+       this = malloc_thing(private_eap_sim_t);
+       
+       this->handle = dlopen(SIM_READER_LIB, RTLD_LAZY);
+       if (this->handle == NULL)
+       {
+               DBG1(DBG_IKE, "unable to open SIM reader '%s'", SIM_READER_LIB);                
+               free(this);
+               return NULL;
+       }
+       this->alg = dlsym(this->handle, SIM_READER_ALG);
+       if (this->alg == NULL)
+       {
+               DBG1(DBG_IKE, "unable to open SIM reader function '%s' in '%s'",
+                        SIM_READER_ALG, SIM_READER_LIB);
+               dlclose(this->handle);
+               free(this);
+               return NULL;
+       }
+       
+       randomizer = randomizer_create();
+       if (randomizer->allocate_pseudo_random_bytes(randomizer, NONCE_LEN,
+                                                                                                &this->nonce))
+       {
+               DBG1(DBG_IKE, "unable to generate NONCE for EAP_SIM");          
+               randomizer->destroy(randomizer);
+               free(this);
+               return NULL;
+       }
+       randomizer->destroy(randomizer);
+       
+       /* public functions */
+       this->public.eap_method_interface.initiate = (status_t(*)(eap_method_t*,eap_payload_t**))initiate;
+       this->public.eap_method_interface.process = (status_t(*)(eap_method_t*,eap_payload_t*,eap_payload_t**))process;
+       this->public.eap_method_interface.get_type = (eap_type_t(*)(eap_method_t*))get_type;
+       this->public.eap_method_interface.is_mutual = (bool(*)(eap_method_t*))is_mutual;
+       this->public.eap_method_interface.get_msk = (status_t(*)(eap_method_t*,chunk_t*))get_msk;
+       this->public.eap_method_interface.destroy = (void(*)(eap_method_t*))destroy;
+       
+       /* private data */
+       this->peer = peer;
+       this->version.ptr = version;
+       this->version.len = sizeof(version);
+       this->version_list = chunk_empty;
+       this->k_auth = chunk_empty;
+       this->k_encr = chunk_empty;
+       this->msk = chunk_empty;
+       this->emsk = chunk_empty;
+       
+       return &this->public;
+}
diff --git a/src/charon/sa/authenticators/eap/eap_sim.h b/src/charon/sa/authenticators/eap/eap_sim.h
new file mode 100644 (file)
index 0000000..d27356d
--- /dev/null
@@ -0,0 +1,142 @@
+/**
+ * @file eap_sim.h
+ *
+ * @brief Interface of eap_sim_t.
+ *
+ */
+
+/*
+ * Copyright (C) 2007 Martin Willi
+ * Hochschule fuer Technik Rapperswil
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.  See <http://www.fsf.org/copyleft/gpl.txt>.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * for more details.
+ */
+
+#ifndef EAP_SIM_H_
+#define EAP_SIM_H_
+
+typedef struct eap_sim_t eap_sim_t;
+typedef enum sim_subtype_t sim_subtype_t;
+typedef enum sim_attribute_t sim_attribute_t;
+
+#include <sa/authenticators/eap/eap_method.h>
+
+/**
+ * Subtypes of SIM messages
+ */
+enum sim_subtype_t {
+       SIM_START = 10,
+       SIM_CHALLENGE = 11,
+       SIM_NOTIFICATION = 12,
+       SIM_CLIENT_ERROR = 14,
+};
+
+/**
+ * enum names for sim_subtype_t
+ */
+extern enum_name_t *sim_subtype_names;
+
+enum sim_attribute_t {
+       /** defines the end of attribute list */
+       AT_END = -1,
+       AT_RAND = 1,
+       AT_AUTN = 2,
+       AT_RES = 3,
+       AT_AUTS = 4,
+       AT_PADDING = 6,
+       AT_NONCE_MT = 7,
+       AT_PERMANENT_ID_REQ = 10,
+       AT_MAC = 11,
+       AT_NOTIFICATION = 12,
+       AT_ANY_ID_REQ = 13,
+       AT_IDENTITY = 14,
+       AT_VERSION_LIST = 15,
+       AT_SELECTED_VERSION = 16,
+       AT_FULLAUTH_ID_REQ = 17,
+       AT_COUNTER = 19,
+       AT_COUNTER_TOO_SMALL = 20,
+       AT_NONCE_S = 21,
+       AT_CLIENT_ERROR_CODE = 22,
+       AT_IV = 129,
+       AT_ENCR_DATA = 130,
+       AT_NEXT_PSEUDONYM = 132,
+       AT_NEXT_REAUTH_ID = 133,
+       AT_CHECKCODE = 134,
+       AT_RESULT_IND = 135,
+};
+
+/**
+ * enum names for sim_subtype_t
+ */
+extern enum_name_t *sim_attribute_names;
+
+/** 
+ * @brief Cardreaders SIM function.
+ *
+ * @param rand                 RAND to run algo with
+ * @param rand_length  length of value in rand
+ * @param sres                 buffer to get SRES
+ * @param sres_length  size of buffer in sres, returns bytes written to SRES
+ * @param kc                   buffer to get Kc
+ * @param kc_length            size of buffer in Kc, returns bytes written to Kc
+ * @return                             zero on success
+ */
+typedef int (*sim_algo_t)(const unsigned char *rand, int rand_length,
+                                                 unsigned char *sres, int *sres_length, 
+                                                 unsigned char *kc, int *kc_length);
+
+#ifndef SIM_READER_LIB
+/** the library containing the cardreader with the SIM function */
+#define SIM_READER_LIB "/home/martin/strongswan/trunk/src/charon/sa/authenticators/eap/sim_reader/sim_api.so"
+#endif /* SIM_READER_LIB */
+
+#ifndef SIM_READER_ALG
+/** the SIM_READER_LIB's algorithm, uses sim_algo_t signature */
+#define SIM_READER_ALG "sim_run_alg"
+#endif /* SIM_READER_ALG */
+
+
+
+/**
+ * @brief Implementation of the eap_method_t interface using EAP-SIM.
+ *
+ * This EAP-SIM client implementation uses another pluggable library to
+ * access the SIM card. This module is specified using the SIM_READER_LIB
+ * definition. The function to run the algorithm has the sim_algo_t type and
+ * is named as SIM_READER_ALG is defined.
+ *
+ * @b Constructors:
+ *  - eap_sim_create()
+ *  - eap_client_create() using eap_method EAP_SIM
+ *
+ * @ingroup eap
+ */
+struct eap_sim_t {
+
+       /**
+        * Implemented eap_method_t interface.
+        */
+       eap_method_t eap_method_interface;
+};
+
+/**
+ * @brief Creates the EAP method EAP-SIM.
+ *
+ * @param server       ID of the EAP server
+ * @param peer         ID of the EAP client
+ * @return                     eap_sim_t object
+ *
+ * @ingroup eap
+ */
+eap_sim_t *eap_create(eap_role_t role,
+                                         identification_t *server, identification_t *peer);
+
+#endif /* EAP_SIM_H_ */
index 9e83581..e7a4789 100644 (file)
@@ -466,6 +466,11 @@ load_conn(starter_conn_t *conn, kw_list_t *kw, starter_config_t *cfg)
                        /* TODO: a gperf function for all EAP types */
                        if (streq(kw->value, "aka"))
                                conn->eap = 23;
+                       else if (streq(kw->value, "sim"))
+                       {
+                               conn->eap = 18;
+                       
+                       }
                        else
                        {
                                conn->eap = atoi(kw->value);