Network Working Group Timothy J. Kniveton Internet Draft Jari T. Malinen Expires: September 1, 2003 Nokia March 1, 2003 SIM Authentication over IPv6 (SIM6) draft-kniveton-sim6-02.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract Providing an existing scalable authorization infrastructure for mobile nodes is needed for IPv6-based mobility. SIM Authentication provides a protocol for authenticating and authorizing services. It uses an authorizing home domain defined by the Subscriber Identity Module (SIM). The protocol is an Internet Control Message Protocol for IPv6 (ICMPv6) [17] extension. It can leverage the existing SIM authorization infrastructure for automatic bootstrapping of security association between the mobile node and a service, where the service can be e.g. authorized last-hop VPN setup for network access or Mobile IPv6 mobile-home security association setup. Kniveton, Malinen Expires September 1, 2003 [Page 1] Internet Draft SIM Authentication over IPv6 March 1, 2003 Contents Status of This Memo 1 Abstract 1 1. Introduction 3 2. Terms 6 3. Protocol Operation 6 3.1. Access Link Signaling . . . . . . . . . . . . . . . . . . 7 3.2. Core Network Signaling . . . . . . . . . . . . . . . . . 8 3.3. Signaling diagram of SIM authentication over AAAv6 . . . 9 4. New requirements for IPv6 Nodes 9 4.1. Mobile node requirements . . . . . . . . . . . . . . . . 11 4.2. Attendant requirements . . . . . . . . . . . . . . . . . 11 4.3. Authentication Gateway requirements . . . . . . . . . . . 11 5. EAP Attribute Types 11 5.1. Peer NAI . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . 12 6. Protocol Messages 13 6.1. Router Advertisement / EAP Data option (Identity Request) 13 6.2. AAAv6 request/EAP-Response/Identity . . . . . . . . . . . 16 6.3. AAAv6 reply/EAP-Request/SIM/Start . . . . . . . . . . . . 18 6.4. AAAv6 request/EAP response/SIM/Start . . . . . . . . . . 21 6.5. AAAv6 reply/EAP request/SIM/Challenge . . . . . . . . . . 26 6.6. AAAv6 request/EAP response/SIM/Challenge . . . . . . . . 29 6.7. AAAv6 reply with key SPI . . . . . . . . . . . . . . . . 32 7. Attendant Operation 35 7.1. Sending EAP Identity Request to the Mobile Node . . . . . 35 7.2. Receiving Identity Response from the Mobile Node . . . . 35 7.3. Sending SIM/Start to the Mobile Node . . . . . . . . . . 36 7.4. Receiving SIM/Start from the Mobile Node . . . . . . . . 36 7.5. Sending SIM/Challenge to the Mobile Node . . . . . . . . 36 7.6. Receiving SIM/Challenge from the Mobile Node . . . . . . 37 7.7. Sending Key Reply to the Mobile Node . . . . . . . . . . 37 8. Mobile Node Operation 38 8.1. Sending SIM/Identity to the Attendant . . . . . . . . . . 38 8.2. Receiving SIM/Start from the Attendant . . . . . . . . . 38 8.3. Sending SIM/Start to the Attendant . . . . . . . . . . . 38 Kniveton, Malinen Expires September 1, 2003 [Page 2] Internet Draft SIM Authentication over IPv6 March 1, 2003 8.4. Receiving SIM/Challenge from the Attendant . . . . . . . 39 8.5. Sending SIM/Challenge to the Attendant . . . . . . . . . 39 8.6. Receiving Key Reply from the Attendant . . . . . . . . . 39 9. Authentication Gateway Operation 39 9.1. Receiving SIM/Start from the mobile node via the Attendant 40 9.2. Sending SIM/Challenge to the mobile node via the Attendant 40 9.3. Receiving SIM/Challenge from the mobile node via the Attendant . . . . . . . . . . . . . . . . . . . . . . . . 41 9.4. Sending Key Reply to the mobile node via the Attendant . 42 10. Applications of SIM Authentication over AAAv6 42 10.1. SIM Authentication for Network Access . . . . . . . . . . 42 10.2. SIM Authentication for Services . . . . . . . . . . . . . 42 11. Protocol Constants 44 12. Security Considerations 44 13. IPv4 Considerations 44 14. Intellectual Property Right Considerations 44 15. Acknowledgements 45 Authors' Addresses 46 Full Copyright Statement 47 1. Introduction This document considers authorization of services in IPv6 for a mobile node, using a Subscriber Identity Module (SIM). The existence of a large number of SIM modules with an associated trust infrastructure provides a widespread existing mechanism for scalable trust delegation. Introduction of totally new mechansims for IP-based trust delegation is expensive. Leveraging an existing SIM-based mechanism for IPv6 [8] can be achieved by a simple extension to the AAAv6 [2] protocol, defined in this document. The mode is an optional extension to AAAv6 functionality. Its requirements are listed in RFC2989, and it also provides revocation, as described in Section 10. When using a hardware-based mechanism, such as a SIM module, for authorizing and authenticating client with a service, bootstrapping of a dynamic trust relationship can be automated so that little or no manual configuration is needed. Services like Mobile IPv6 [14] can benefit from such a mechanism in that, for example, no static mobile-home security association configuration is needed. The presented protocol is Kniveton, Malinen Expires September 1, 2003 [Page 3] Internet Draft SIM Authentication over IPv6 March 1, 2003 applicable to bootstrapping a security association between mobile node and home agent, or mobile node and an access link router. It can also be used for bootstrapping other services. +-------------------------+ | [A] | | +--------+ | | | | | | +-----+ AAAH | | | | | | | | | +--------+ | | +--------+ | | | | | +---| AGW |------------+ | | +---+----+ | +------|-------+ | +---+----+ | | | | | | | AAAL | | | | | | | +---+----+ | | [B] | | +--------+ | +---+----+ | +--------+ | | | | | | | [C] | | MN |---------| AR/LA |------------+ Peer | | | | | | | |e.g. HA | +--------+ | +--------+ | +--------+ +--------------+ Figure 1: Network Reference for SIM Authentication over AAAv6 The protocol uses a network topology reference model as presented in Figure 1. Authorization comes from a domain [A] separate from those of access [B] and from the domain using the authorization [C]. Usually, the authorizing domain is the network of the issuing operator, operator who issued the SIM module. The protocol does not require changes to network entities either in the IPv6 network or in the cellular network, or to existing SIM authentication principles used there. Exceptions are the access router's attendant functionality, the AAAv6 signaling in the mobile node (MN), and the gateway connecting a cellular network with the IPv6 network. New functional elements are the SIM6 functionality in the mobile node, access router, and in the authentication gateway, at the Kniveton, Malinen Expires September 1, 2003 [Page 4] Internet Draft SIM Authentication over IPv6 March 1, 2003 border of the IP network and the cellular domain. The AGW is capable of communicating with the authorization center in the cellular network of the issuing operator. SIM Authentication uses Extensible Authentication Protocol (EAP) [3] messages as a modular key distribution extension to AAAv6. The use of EAP allows for adding other similar extensions over AAAv6. In SIM authentication, an access router includes an EAP option in its router advertisements containing an EAP-Request/SIM/Identity message requesting the mobile node's identity. The mobile node processes this EAP option and recognizes it as signaling the presence of SIM6. The mobile node returns its identity in an EAP message, containing its International Mobile Subscriber Identifier (IMSI) [9]. Next, a SIM Start request is processed, and finally a key request to an authentication gateway (AGW) is returned. The AGW returns a SIM challenge to the mobile node which responds with a SIM challenge response in the second message, computed locally by the SIM module. The identity response, key request, SIM challenge, and SIM response are EAP messages inside AAAv6. If the response matches that locally known by the authentication gateway, a session key is finally returned in a key reply. While mobile node has a local SIM-generated session key, the other instance of the session key is provided in the key reply to its user. This user is called the peer. It can be the access router, for example. Since the mobile node locally creates its copy of the session key, no key material is transported over the access link. The protocol provides a temporary session key pair. Its application can be authentication with the access router, last hop encryption, or authentication with Mobile IPv6 [14] home agent (Section 10), depending on the purpose of authorization, negotiated between MN and AGW. Signaling using the session key, e.g. Mobile IPv6 binding update, can take place parallel to the key distribution, so that a minimal number of signaling roundtrips is achieved. Since current authentication using a SIM module typically only produces a key 64 bits long, the mechanism uses a set of n SIM challenges, responses, and session keys. Thus, the generated session key can be longer, n times 64 bits. A recommended value for n is 2. A session key is a value K, computed from the SIM-generated n session keys Kn, by pseudo-random function PRF(n*Kc, n*RAND | IMSI | NONCE_MT). This way the original SIM-generated Kc keys are not exposed while using them. Also, the client who generates a random number NONCE_MT can know that the information leading to the generation of K was properly replay-protected. Currently, HMAC-MD5-96 [15] and HMAC-SHA-1-96 [16] are the suggested pseudo-random functions used. Protocol version Kniveton, Malinen Expires September 1, 2003 [Page 5] Internet Draft SIM Authentication over IPv6 March 1, 2003 1 uses the former while protocol version 2 uses the latter. These pseudo-random functions are also used in the message authentication code (MAC) fields, as specified in Section 6. 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 RFC 2119 [4]. In addition, this document uses the following terms: GSM Authentication Authentication procedures in the Global System for Mobile communications (GSM) [10]. IMSI International Mobile Subscriber Identifier, used in GSM to identify subscribers. EAP Extensible Authentication Protocol [18], an authentication protocol used with PPP[13] to have a flexible enough authentication extension for multiple authentication methods. SIM Subscriber Identity Module, a chip usually found in cellular phones identifying the user to the operator and containing credentials and algorithms for authentication. word A word is 4 bytes long, and comprises one row in a protocol message diagram. This terminology is intended to conform to those that have been used in IPv6, Mobile IPv6, AAA, and other Internet protocols [8, 14, 6]. 3. Protocol Operation The protocol is an application of AAAv6 where an AAAv6 Embedded Data option contains EAP options for SIM Authentication as described in the EAP SIM Authentication [12]. Identity Privacy support, optional as described in section 5 of [12], is not supported in this protocol draft. Attribute types described therein must not be used by entities communicating with SIM6, and Identifiers are sent as cleartext; no pseudonyms are used. The protocol signaling is illustrated in Figure 2. Kniveton, Malinen Expires September 1, 2003 [Page 6] Internet Draft SIM Authentication over IPv6 March 1, 2003 3.1. Access Link Signaling The access router sends an EAP Request/Identity option in an unsolicited or solicited router advertisement. This is an option added to the router advertisement when AAAv6 attendant functionality in the access router is enabled, and causes the mobile node to begin signalling for SIM6 authentication. After receiving a router advertisement with an EAP Identity Request, the mobile node returns an AAAv6 request to the access router, with an embedded data option containing the identity response, an EAP Response/Identity. This response has the client's ID, a Network Access Identifier (NAI) in the format user@realm, where the user part is an International Mobile Subscriber Identifier (IMSI), and the realm part enables the AAA cloud to route the signal to the authentication gateway (AGW/AAAH). A special realm GSMSIM_NAI_REALM is used to find the first available authentication gateway. Next, the authentication gateway returns an EAP Request/SIM/Start message (again, enclosed in an AAAv6 Request with embedded data option) to the client, which signals the start of the authentication procedure. This AAAv6 request also contains the registration identity of the mobile node in the ID option of AAAv6. The SIM key request is an Embedded Data option in the AAA request which contains an EAP Response/SIM/Start. This provides a signal to the attendant function in the access router to propagate this request together with the NAI to the SIM-aware authentication gateway. The SIM key request also contains a parameter to negotiate lifetime for the session key. When the attendant receives back a SIM challenge (nRAND) embedded in an EAP Request from the authentication gateway, it encloses it in an AAAv6 reply and forwards to the mobile node. The NAI option containing the IMSI is included in the subsequent messages to identify the authentication dialogue in progress. When the mobile node receives the first AAAv6 reply, it invokes the SIM algorithm with the included n random numbers (nRAND) from the message. This generates the n SRES values and a local session key. How big n is depends on how long key is needed. SIM authentication produces a short key of 64 bits but an application may need a longer key. The second AAAv6 request from the mobile node to the local attendant then contains a hash of the generated SRES, mSRES, computed as the MAC_SRES. This conveys the SRES values back to the authentication gateway in a format from which an eavesdropper can not extract the actual RAND/SRES value pairs. The AAAv6 request also contains the NAI option. Kniveton, Malinen Expires September 1, 2003 [Page 7] Internet Draft SIM Authentication over IPv6 March 1, 2003 When receiving the second AAAv6 request, the attendant forwards the signal to the authentication gateway which verifies the mSRES. If correct, the attendant will receive a key reply with a success status and potentially with the generated session key. If incorrect, the key reply will contain a failure status. Finally, the attendant sends a second AAAv6 reply, which contains NAI and a key reply. When receiving the second AAAv6 reply, the mobile node will know whether the SIM authentication succeeded and also contains the chosen purpose for the generated session key. If the attendant receives an AAAv6 message containing the DIAMETER_AUTHENTICATION_REJECTED (4001) or DIAMETER_UNABLE_TO_DELIVER (3002) status code, it uses the code AAAV6_FAILURE (3) in the Code field of the last AAAv6 message encapsulating the EAP key reply, and utilizes the optional EAP error status indicator at the end of the key reply. 3.2. Core Network Signaling The attendant will eventually use DIAMETER [6] NASREQ [5] as the core network signaling with the authentication gateway. Meanwhile, the core network signaling can use e.g. Radius, or directly SIM6 messages. A proxy authentication gateway (Section 9) provides for multi-hop core network signaling as a fallback or for interoperation. Each hop can use its own protocol so that a proxy authentication gateway translates between different core network signaling protocols, useful for transition and migration scenarios. Kniveton, Malinen Expires September 1, 2003 [Page 8] Internet Draft SIM Authentication over IPv6 March 1, 2003 3.3. Signaling diagram of SIM authentication over AAAv6 Below, signaling of the SIM authentication over AAAv6 and core signaling, e.g. DIAMETER, uses key distribution from AGW in the signals left of the AGW/AAAH while signaling with HA is optionally possible, if key distribution to HA is requested. Acronyms: AHR#n - AAA Client Request (using an AAA protocol) number n AHA#n - AAA Client Answer (using an AAA protocol) number n aID - Attendant Identifier (IPv6 source address) ARq#n - AAAv6 Request number n ARp#n - AAAv6 Reply number n MN - Mobile IPv6 Mobile Node [14] AAAL - Local AAA Server [2] AGW/AAAH - Authentication Gateway/AAA Home Server [2] HA - Mobile IPv6 Home Agent [14] CN - Mobile IPv6 Correspondent Node [14] CP - Controlled part of a router system [2] RTSOL - ICMPv6 Router Solicitation [17] cID - Client (MN) Network Access Identifier [1] CR - Credentials (EAP/SIM Start) [2] nRAND - EAP/SIM Challenge [12] mSRES - EAP/SIM Response [12] Start - EAP/SIM Start [12] Ident - EAP/SIM Identity [3] status - Returned status of authorization [2] KR - AAAv6 Key Reply [2] GKm - Generate locally MN instance of session key from SIM SKn - Store the received network instance of the session key UCP - Uncontrolled part of a router system [2] UPD - Update controlled part of router system with session key 4. New requirements for IPv6 Nodes Functionality introduced by SIM6 affect the mobile node, attendant, and authentication gateway. They need to understand the EAP extensions to AAAv6 and how to pass them over the access link and core network protocols. AAAv6 requires two new subtypes of the Embedded Data extension. The core network protocol, e.g. DIAMETER needs to be able to pass an identifier together with the key material in its messages. The key material is passed either in the EAP messages or in a AAAv6 key reply extension. Kniveton, Malinen Expires September 1, 2003 [Page 9] Internet Draft SIM Authentication over IPv6 March 1, 2003 Client Router System AAAL AAAH Peer (e.g.MN) +........+ | (AGW) (e.g.HA) | .UCP CP . | | | | aID,Ident . | | . | | | 7.1.|<--------------------| | . | | | | . | | . | | | | cID,Ident . | | . | | | 7.2.|-------------------->| | . cID,Ident | | | | . |-------------------->| | | | . | | . | | | | . | | . cID,Start | | | | cID,Start. |<--------------------| | | 7.3.|<--------------------| | . | | | | . | | . | | | | ARq#1: cID,Start. | | . | | | 7.4.|-------------------->| AHR#1:aID,cID,Start | | | | . |-------------------->| AHR#1 | | | . | | . |------>| | | . | | . | | | | . | | . | AHA#1 | | | . | AHA#1:cID,nRAND |<------| | | ARp#1:cID,nRAND . |<--------------------| | | 7.5.|<--------------------| | . | | | GKm | . | | . | | | | ARq#2:cID,mSRES . | | . | | | 7.6.|-------------------->| | . | | | | . | AHR#2:aID,cID,mSRES | | | | . |-------------------->| AHR#2 | | | . | | . |------>| | | . | | . | | (KR) | | . | | . | |---------->| | . | | . | | SKn| | . | | . | | (KR) | | . | | . | AHA#2 |<----------| | . | | . |<------| | | . | AHA#2:cID,KR | | | | . |<--------------------| | | | . | | . | | | | . |UPD | . | | | | ARp#2:status,KR . |--->| . | | | 7.7.|<--------------------| | . | | | | . | | . | | | +........+ Figure 2: Signaling of SIM Authentication EAP extension over AAAv6 and core network AAA signaling Kniveton, Malinen Expires September 1, 2003 [Page 10] Internet Draft SIM Authentication over IPv6 March 1, 2003 4.1. Mobile node requirements The mobile node is required to have an extension to its router discovery understanding the EAP Option (containing the Identity Request), and an extension to AAAv6 signaling which recognizes the SIM6 EAP types and protocol stages. Mobile node maintains an autentication session context state for each IMSI it is attempting to authenticate (typically only one). 4.2. Attendant requirements The attendant is required to be able to provide an EAP Identity Request option in the router advertisement. The attendant needs no specific knowledge of the EAP data passed through it, however, the capacity to forward EAP embedded data options is needed. The attendant maintains an authentication session context state for each mobile node. 4.3. Authentication Gateway requirements The authentication gateway is required to understand the EAP extension and key reply extension to the core network protocol. It maintains an authentication session context state for each mobile node and is able to query the RAND, SRES, and session key elements for a received IMSI from a local authorization database, from the GSM network, or from another authentication gateway. 5. EAP Attribute Types The following new attribute types are defined for EAP: 5.1. Peer NAI This optional field can be used to describe service to authorize. When the authentication gateway receives this field, it sends two key replies, one without the key towards the client, and another with the key, towards the peer node where realm of the Peer NAI encodes routing of the key reply to the peer node over the core signaling protocol. Attribute Type 50 = AT_PEER_NAI (This is a temporary value; not yet assigned by IANA) Kniveton, Malinen Expires September 1, 2003 [Page 11] Internet Draft SIM Authentication over IPv6 March 1, 2003 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_PEER_NAI | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer NAI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer NAI cont'd | Pad1 | Pad1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: EAP Attribute / AT-PEER-NAI Length 1+(length of NAI padded to next word) = length of attribute in WORDS Key Lifetime Peer NAI = ASCII identity of service being authorized. Pad1 Since attributes are measured in terms of 4-byte words, the NAI must be padded by 0-3 PAD1s, depending on its length, so that it is word-aligned. These PAD1s are composed of all 0 bits. Since 0 is not a valid value for a character of an ASCII NAI, when a 0 byte is encountered, it should be excluded from the NAI and the rest of the word ignored. 5.2. Key Lifetime The Key Lifetime attribute is used as both a key lifetime request, as in the EAP-Response/SIM/Start in section 6.4, where the mobile node proposes a key lifetime, and a key lifetime response, as in the EAP-Request/SIM/Challenge in section 6.5 where the home agent reponds with the key lifetime that has been granted (either the requested lifetime, or a shorter one). Kniveton, Malinen Expires September 1, 2003 [Page 12] Internet Draft SIM Authentication over IPv6 March 1, 2003 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_KEY_LIFETIME| Length = 2 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: EAP Attribute / AT-KEY-LIFETIME Attribute Type 51 = AT_KEY_LIFETIME (This is a temporary value; not yet assigned by IANA) Length 2 = Length of attribute in WORDS Key Lifetime 1 = Requested, or granted, key lifetime (depending on message it appears in) 6. Protocol Messages This section shows the messages exchanged in a SIM6 authentication procedure. The messages are shown in their entirety with references to the documents describing the components. Section numbers for the messages are also shown in Figure 2. The messages shown are generic AAAv6 [2] (i.e. special ICMPv6 [7]) messages, and as such could be contained in Radius [11] messages, or could be sent over a secure channel as simple ICMPv6 packets. Access link can use non-secure channels, but with plain ICMPv6 packets, a secure communication channel is assumed from LA to AGW. 6.1. Router Advertisement / EAP Data option (Identity Request) When the mobile node arrives at the visited network, it receives a router advertisement as specified by Neighbor Discovery [17] and modified by Mobile IPv6 [14] from the local router. This router advertisement contains an ``EAP Data'' option which is defined in this Kniveton, Malinen Expires September 1, 2003 [Page 13] Internet Draft SIM Authentication over IPv6 March 1, 2003 document, and is essentially a indicator that EAP signaling is possible, and signals to the mobile node to begin the SIM Authentication dialog. The entire message appears as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| | | IPv6 Header... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}| Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {3}| Router Advertisement Options | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {4}| Type | Length | Code | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Router Advertisement / EAP Data Option {1} IPv6 Header [8] {2} Router Advertisement [8, 14] {3} Router Advertisement Options May include Target Link-layer address, Prefix Information Options,... {4} EAP Data Option This portion of the message is a newly-defined router advertisement option whose purpose is to hold an EAP message. The message contained is an EAP-Request/Identity, which signals the start of SIM6 signaling. Kniveton, Malinen Expires September 1, 2003 [Page 14] Internet Draft SIM Authentication over IPv6 March 1, 2003 This additional option is the only change from the normal router advertisements the access router/AAAv6 Attendant would already be sending. Type 10 = EAP Data Option (This is a temporary value; not yet assigned by IANA) Length 1 = Length in 8 octets including the type and length fields Code 1 = EAP Request (Note: the EAP-Request message starts with this field) Identifier 0 - The identifier field is one octet and aids in matching responses with requests [3], not used here. Length 5 = Number of octets in EAP data Type 1 = Identity Reserved 0 = Ignored on reception Kniveton, Malinen Expires September 1, 2003 [Page 15] Internet Draft SIM Authentication over IPv6 March 1, 2003 6.2. AAAv6 request/EAP-Response/Identity This section describes the message the mobile node sends to identify itself as having interest in the SIM authentication procedure. This message is a AAAv6 request containing an embedded data option, which is an EAP response packet. This EAP packet is a response to the Identity Request contained in a Router Advertisement's EAP Data option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| | | IPv6 Header... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}| Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {3}| Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {4}| Type |W|H| Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4b}| Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Identity . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: AAAv6 request/EAP response/SIM/Identity {1} IPv6 Header SRC = mobile node; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6) {2} ICMPv6 Header [7] Type 201 (C9h) [TBD] = AAAv6 Request Code 0 - For AAA request, not defined Kniveton, Malinen Expires September 1, 2003 [Page 16] Internet Draft SIM Authentication over IPv6 March 1, 2003 Checksum Calculated as defined in [7]. {3} AAA Client Identifier Option [2] Note: although the embedded EAP message contains the Identifier, it is also present throughout this and all subsequent messages in the AAAv6 ID option, to aid in message flow attribution and to allow proper AAAv6 message routing. Type 1 (unskippable) = Client Identifier Option. Subtype 0 = NAI Length Length of Identifier (NAI) in octets. Identifier The NAI [1, 12] is an ASCII field constructed by concatenating the character ``0'', the GSM's assigned 13-byte IMSI, and the special realm ``@GSMSIM_NAI_REALM''. Thus, the total length of the NAI is 31 bytes, and the null termination is not included in the protocol messages. This message includes a Pad1 option at the end (bytes with value 0), as necessary, so the following field is properly aligned to an even byte # (2N octets). {4} AAAv6 Embedded Data Option [2] Type 8 (unskippable) = Embedded Data Option WH binary 10 = scope is AAAv6 home server (AAAH) Subtype 3 = EAP Response Kniveton, Malinen Expires September 1, 2003 [Page 17] Internet Draft SIM Authentication over IPv6 March 1, 2003 Length 5 + size of NAI + padding = Length of Embedded Data {4b} in octets, plus one padding byte if option was odd length (must be 2-byte aligned). {4b} EAP-Response/Identity [12] Embedded in the AAAv6 option above is the EAP packet signifying an interest in the SIM authentication procedure. Code 2 = Response Identifier 0 - The identifier field is one octet and aids in matching responses with requests [3], not used here. Length 5 (+ size of NAI) = Length of the whole EAP extension in octets. Type 1 = Identity Identity This field (the Type-data field associated with the Identity type) holds the NAI of the mobile node. This should be the same as the identity in the AAAv6 Identity option earlier in this packet. 6.3. AAAv6 reply/EAP-Request/SIM/Start After receiving an Identity Response from the mobile node, the AAAH/Authentication Gateway sends a SIM/Start Request to the mobile node. The message is described as follows: {1} IPv6 Header SRC = AAAv6 Attendant; DEST = mobile node; NxtHDR = 58 (ICMPv6) {2} ICMPv6 Header [7] Kniveton, Malinen Expires September 1, 2003 [Page 18] Internet Draft SIM Authentication over IPv6 March 1, 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| | | IPv6 Header... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}| Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {3}| Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {4}| Type |W|H| Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4b}| Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Attribute Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer NAI (optional)... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: AAAv6 reply/EAP-Request/SIM/Start Type 203 (CBh) [TBD] = AAAv6 Reply Code 0 - Sucess Checksum Calculated as defined in [7]. {3} AAA Client Identifier Option [2] Type 1 (unskippable) = Client Identifier Option. Kniveton, Malinen Expires September 1, 2003 [Page 19] Internet Draft SIM Authentication over IPv6 March 1, 2003 Subtype 0 = NAI Length Length of Identifier (NAI) in octets. Identifier The NAI [1] is constructed using the GSM's assigned IMSI and a special realm as specified in Section 6.2. {4} AAAv6 Embedded Data Option [2] Type 8 (unskippable) = Embedded Data Option WH binary 00 = This means the recipient of AAA Protocol message (client or attendant) should process embedded data. In fact, the client (mobile node) should process this message. Subtype 2 = EAP Request Length 8 = Length of Embedded Data {4b} in octets. {4b} EAP-Request/SIM/Start [12] Embedded in the AAAv6 option above is the EAP packet requesting the start of the SIM authentication procedure. Code 1 = Request Identifier 0 - The identifier field is one octet and aids in matching responses with requests [3], not used here. Kniveton, Malinen Expires September 1, 2003 [Page 20] Internet Draft SIM Authentication over IPv6 March 1, 2003 Length 8 (+ 4 + size of Peer NAI, if used) = Length of the whole EAP extension in octets. Type 18 = EAP type for EAP/SIM authentication. Subtype 10 = SIM/Start. Reserved 0 Peer NAI Describes service to authorize. This attribute is optional. 6.4. AAAv6 request/EAP response/SIM/Start This message is a response to the EAP request for the SIM Start procedure. This signals the beginning the authentication process proper. {1} IPv6 Header SRC = mobile node; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6) {2} ICMPv6 Header [7] Type 201 (C9h) [TBD] = AAAv6 Request Code 0 - For AAA request, not defined Checksum Calculated as defined in [7]. {3} AAA Client Identifier Option [2] Kniveton, Malinen Expires September 1, 2003 [Page 21] Internet Draft SIM Authentication over IPv6 March 1, 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| | | IPv6 Header... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}| Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {3}| Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {4}| Type |W|H| Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4b}| Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Reserved | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Attribute Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NONCE_MT | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Attribute Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Lifetime Proposal | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Attribute Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer NAI (optional)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: AAAv6 request/EAP response/SIM/Start Type 1 (unskippable) = Client Identifier Option. Subtype 0 = NAI Kniveton, Malinen Expires September 1, 2003 [Page 22] Internet Draft SIM Authentication over IPv6 March 1, 2003 Length 31 = Length of Identifier (NAI) in octets. Identifier The NAI [1] is constructed using the GSM's assigned IMSI and a special realm as specified in Section refmessage:idresp. {4} AAAv6 Embedded Data Option [2] Type 8 (unskippable) = Embedded Data Option WH binary 10 = scope is AAAv6 home server (AAAH) Subtype 3 = EAP Response Length 36 (+ 4 + Size of Peer NAI, if Peer NAI Attribute is used) = Length of Embedded Data {4b} in octets. {4b} EAP-Response/SIM/Start [12] Embedded in the AAAv6 option above is the EAP packet signifying the start of the SIM authentication procedure. Code 2 = Response Identifier 0 - The identifier field is one octet and aids in matching responses with requests [3], not used here. Length 36 (+ 4 + size of Peer NAI) = Length of the whole EAP extension in octets. Kniveton, Malinen Expires September 1, 2003 [Page 23] Internet Draft SIM Authentication over IPv6 March 1, 2003 Type 18 = EAP type for EAP/SIM authentication. Subtype 10 = SIM/Start. Reason bitmask: 001 (Client-Attendant authentication), 010 (Client-Attendant encryption) , 100 (MN-HA authentication) , or any combination thereof, depending on the scope desired for the session key provided by SIM authentication. (see [12]). Attribute Type 7 = AT_NONCE_MT Length 5 = Number of words in attribute Reserved 0 NONCE_MT A random number generated by the client (20 bytes), which is used as a seed value for the new key. Attribute Type 50 [TBD] = AT_KEY_LIFETIME Length 2 = Number of words in attribute Reserved 0 Key Lifetime Proposal Client's key lifetime proposal in seconds (four bytes). Kniveton, Malinen Expires September 1, 2003 [Page 24] Internet Draft SIM Authentication over IPv6 March 1, 2003 Attribute Type 51 [TBD] = AT_PEER_NAI Length 1 + size of NAI = Number of words in attribute Peer NAI Describes service to authorize. This attribute is optional. Kniveton, Malinen Expires September 1, 2003 [Page 25] Internet Draft SIM Authentication over IPv6 March 1, 2003 6.5. AAAv6 reply/EAP request/SIM/Challenge This message is the SIM authentication challenge providing n random numbers to the mobile node, protected by message authentication code. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| | | IPv6 Header... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}| Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {3}| Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {4}| Type |W|H| Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4b}| Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Attribute Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n*RAND ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Attribute Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC_RAND | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Attribute Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: AAAv6 reply/EAP-Request/SIM/Challenge {1} IPv6 Header SRC = AAAv6 Attendant; DEST = mobile node; NxtHDR = 58 (ICMPv6) Kniveton, Malinen Expires September 1, 2003 [Page 26] Internet Draft SIM Authentication over IPv6 March 1, 2003 {2} ICMPv6 Header [7] Type 203 (CBh) [TBD] = AAAv6 Reply {3} AAA Client Identifier Option See Section 6.3. {4} AAAv6 Embedded Data Option Type 8 = Embedded Data Option WH binary 00 = Recipient of AAA Protocol message (client or attendant) should process embedded data. Subtype 2 = EAP Request Length 40 + size of n*Rand (see below) = Length of Embedded Data {4b} in octets. {4b} EAP-Request/SIM/Challenge [12] Code 1 = Request Identifier The identifier field is one octet and aids in matching responses with requests [3]. Length 40 + n*20 octets, where n is the number of RAND challenges given in this EAP Request, now 60. Type 18 = EAP type for EAP/SIM authentication. Kniveton, Malinen Expires September 1, 2003 [Page 27] Internet Draft SIM Authentication over IPv6 March 1, 2003 Subtype 11 = SIM/Challenge. Reserved 0 Attribute Type 1 = AT_RAND Length 1 + (4 * # of nRANDs) = Number of words in attribute N*RAND N GSM RANDs (20 bytes each), now n=2, 40 octets. Attribute Type 11 = AT_MAC Length 5 = Number of words in attribute MAC_RAND A message authentication code for n*RAND and Key Lifetime, defined by a pseudo-random function PRF(n*Kc, n*RAND | NONCE_MT | Lifetime) [12], 20 octets for HMAC-SHA1 (or 16 octets for HMAC-MD5), where n*Kc are the n session keys. Attribute Type 50 = AT_KEY_LIFETIME Length 2 = Number of words in attribute Lifetime Remaining key lifetime in seconds (4 bytes), decided by the AAA Server. The AAA Server may, but it doesn't have to, take into account the client's key lifetime proposal from EAP- Kniveton, Malinen Expires September 1, 2003 [Page 28] Internet Draft SIM Authentication over IPv6 March 1, 2003 Response/GSMSIM/Start. The key lifetime must be greater than zero. 6.6. AAAv6 request/EAP response/SIM/Challenge This message is a response to the SIM authentication challenge. Naming both as SIM/Challenge follows the convention of EAP to give same name to a request and its response. The response MAC_SRES is provided as a hash of the responses produced by the SIM module so the original responses are not explicit in the message. AGW can still take the same hash to check validity of the response. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| | | IPv6 Header... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}| Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {3}| Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {4}| Type |W|H| Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4b}| Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Attribute Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC_SRES | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: AAAv6 request/EAP response/SIM/Challenge {1} IPv6 Header SRC = mobile node; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6) Kniveton, Malinen Expires September 1, 2003 [Page 29] Internet Draft SIM Authentication over IPv6 March 1, 2003 {2} ICMPv6 Header [7] Type 201 (C9h) [TBD] = AAAv6 Request {3} AAA Client Identifier Option See Section 6.3. {4} AAAv6 Embedded Data Option Type 8 = Embedded Data Option WH binary 10 = scope is AAAv6 home server (AAAH) should process embedded data. Subtype 3 = EAP Response Length 28 (18h) = Length of Embedded Data {4b} in octets. {4b} EAP-Response/SIM/Challenge [12] Code 2 = Response Identifier The identifier field is one octet and aids in matching responses with requests [3]. Length 28 = Length of the whole EAP extension in octets. Type 18 = EAP type for EAP/SIM authentication. Kniveton, Malinen Expires September 1, 2003 [Page 30] Internet Draft SIM Authentication over IPv6 March 1, 2003 Subtype 11 = SIM/Challenge. Attribute Type 9 = AT_MAC_SRES Length 6 = Number of words in attribute MAC_SRES The response calculated by the client defined by a pseudo-random function PRF(n*Kc, n*SRES | IMSI | NONCE_MT) [12], 20 octets, where n*Kc are the n session keys, n*SRES the n system responses obtained from the SIM card in the mobile node, IMSI its identifier, and NONCE_MT the nonce randomized by the mobile node. Kniveton, Malinen Expires September 1, 2003 [Page 31] Internet Draft SIM Authentication over IPv6 March 1, 2003 6.7. AAAv6 reply with key SPI This message originates at the authentication gateway, but the AAA Attendant removes and keeps any key info distributed with this message. When this message arrives at the mobile node, it is used to indicate the success or failure of the SIM authentication session (for the indicated NAI), and the SPI which should be used in the mobile node's SPD. No session key is carried over the last hop since the mobile node already has the session key, generated locally by the SIM algorithm. AAAv6 key reply option thus has no key field, it only conveys the status to the mobile node. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {1}| | | IPv6 Header... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {2}| Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {3}| Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {4}| Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AAAH SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {5}| Type |W|H| Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5b}| Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: AAAv6 reply with key SPI {1} IPv6 Header SRC = AAAv6 Attendant; DEST = mobile node; NxtHDR = 58 (ICMPv6) {2} ICMPv6 Header [7] Kniveton, Malinen Expires September 1, 2003 [Page 32] Internet Draft SIM Authentication over IPv6 March 1, 2003 Type 203 (CBh) [TBD] = AAAv6 Reply Code Indicates success or failure of the protocol as specified in [2], Section 7.2. Currently, the following diagnostic states are used. SUCCESS: 0 - Authorization succeeded AAAV6_FAILURE: 3 - Received AAAv6 error during negotiation INVALID_CREDENTIAL: 50 - Bad MAC_SRES Checksum Calculated as defined in [7]. {3} AAA Client Identifier Option See Section 6.3. {4} AAA Generalized Key Reply Option [2] Type 4 (unskippable) = Generalized Key Reply Option. Subtype Depending on the scope of the key established, this field will contain a bitmask value; see Section 6.3, message part 4b, Reason codes. Length 12 = Length of the option in octets except the first four octets. Lifetime This is the key lifetime passed in the key reply back to the cmobile node as well as to the receiver of the network instance of the session key. AAAH SPI Not used. Ignored by mobile node. Kniveton, Malinen Expires September 1, 2003 [Page 33] Internet Draft SIM Authentication over IPv6 March 1, 2003 Key SPI This field indicates the security association between the mobile node and AAAH which should be used by the client to interpret the generated key. The following two fields (5 and 5b) are optional based on the result of authentication. If it was unsuccessful, these fields encapsulate a failure indicator. {5} AAAv6 Embedded Data Option Type 8 = Embedded Data Option WH binary 10 = scope is AAAv6 home server (AAAH) should process embedded data. Subtype 3 = EAP Response Length 4 = Length of Embedded Data {5b} in octets. {5b} EAP-Failure Code 4 = Failure Identifier 0 Length 4 = Length of the EAP extension in octets. Note that the Encoded Key field is not sent with this message, as the key has already been generated at the mobile node. Kniveton, Malinen Expires September 1, 2003 [Page 34] Internet Draft SIM Authentication over IPv6 March 1, 2003 7. Attendant Operation The attendant modifies its router advertisement to include an EAP option. Furthermore, it is involved in two message exchanges with the mobile node where it first receives an AAAv6 request and then replies with an AAAv6 reply. 7.1. Sending EAP Identity Request to the Mobile Node The attendant must include the EAP Data option as defined in Section refmessage:rtadv in each router advertisement it sends on any link it serves where mobile nodes may be visiting. 7.2. Receiving Identity Response from the Mobile Node When the attendant receives an AAAv6 request from the mobile node containing an Identity Response EAP object, it creates an AAAv6 context where it stores the identifier of the mobile node. The attendant then creates and attaches to the per-mobile node AAAv6 context a per-mobile node SIM6 context where it stores the following items: key lifetime proposal, reason for the key exchange, and the NONCE_MT created by the mobile node. If all the needed data elements were present in the message received, the attendant forwards the identifier and credentials of the mobile node towards an AGW. This AGW MAY be chosen from a priority list of AGWs, keyed by the realm part of the identifier. Configuration of this list is out of scope of the protocol, but may represent administratively configured cross-domain trust relationships, e.g. roaming agreements. The credentials in the message include elements in the EAP object. The core protocol SHOULD carry the unmodified EAP object, associated with the identifier, to the AGW. The attendant then waits for a reply from the AGW for SIM6_TIMEOUT_AGW seconds. If no reply is received in time, or an error is received, the attendant deletes the context for the mobile node. In case of failure, prior to deleting the context, the attendant SHOULD try to repeat sending the message SIM6_MAX_RETRIES times. It MAY repeat this for each member in the priority list of AGWs. In case a lower-priority AGW replies, its priority on the list MAY be temporarily elevated above those of the failed AGWs. Kniveton, Malinen Expires September 1, 2003 [Page 35] Internet Draft SIM Authentication over IPv6 March 1, 2003 7.3. Sending SIM/Start to the Mobile Node After receiving the Start message from AGW, the attendant searches for the mobile node's context based on the identifier received from the AGW. If no context is found, the packet is discarded. In case a context was found, the attendant creates a SIM/Start EAP packet and sends it to the mobile node in an AAAv6 reply. The AAAv6 reply first contains the identifier, after which it contains the EAP object with a start message. The attendant sets a timer SIM6_TIMEOUT_MOBILE for the mobile node's context in expectation of a second AAAv6 request with SIM/Challenge back from the mobile node. If no request is received in time, the mobile node's context is deleted. In case of failure, prior to deleting the context, the attendant SHOULD try repeat sending the message SIM6_MAX_RETRIES times. 7.4. Receiving SIM/Start from the Mobile Node After receiving an AAAv6 request with a SIM/Start from the mobile node, the attendant searches for the mobile node's context based on the identifier received from the mobile node. If no context is found, the packet is discarded. In case a context was found, the attendant creates a message to the AGW where it inserts the identifier and the information received in the EAP object, including the Nonce used in the GSM authentication process, and the key lifetime proposal. The Peer NAI may also be included, depending on whether the mobile node wishes to specify the service it is requesting authorization for. It then forwards this EAP Request to the AGW via its AAAv6 method. The attendant then waits for a reply from the AGW for SIM6_TIMEOUT_AGW seconds. If no reply is received in time, or an error is received, the attendant deletes the context for the mobile node. In case of failure, prior to deleting the context, the attendant SHOULD try repeat sending the message to the AGW SIM6_MAX_RETRIES times. If the attendant receives a message containing a key reply for the mobile node, it sends an AAAv6 Key Reply to the mobile node. 7.5. Sending SIM/Challenge to the Mobile Node After receiving the nRAND from AGW, the attendant searches for the mobile node's context based on the identifier received from the AGW. If no context is found, the packet is discarded. Kniveton, Malinen Expires September 1, 2003 [Page 36] Internet Draft SIM Authentication over IPv6 March 1, 2003 In case a context was found, the attendant creates a SIM/Challenge EAP packet and sends it to the mobile node in an AAAv6 reply. The AAAv6 reply first contains the identifier, after which it contains the EAP object with the nRAND and the key lifetime decided by the authorizing AGW. The EAP object is protected by the MAC_RAND field which covers the nRAND, the NONCE_MT in the mobile node's context, and the lifetime. The core protocol SHOULD get this EAP object unmodified, together with the identifier, from the AGW. The attendant sets a timer SIM6_TIMEOUT_MOBILE for the mobile node's context in expectation of a second AAAv6 request with SIM/Challenge back from the mobile node. If no request is received in time, the mobile node's context is deleted. In case of failure, prior to deleting the context, the attendant SHOULD try repeat sending the message SIM6_MAX_RETRIES times. 7.6. Receiving SIM/Challenge from the Mobile Node After receiving the second AAAv6 request with a SIM/Challenge from the mobile node, the attendant searches for the mobile node's context based on the identifier received from the mobile node. If no context is found, the packet is discarded. In case a context was found, the attendant creates a message to the AGW where it inserts the identifier and the information received in the EAP object. The attendant then waits for a reply from the AGW for SIM6_TIMEOUT_AGW seconds. If no reply is received in time, or an error is received, the attendant deletes the context for the mobile node. In case of failure, prior to deleting the context, the attendant SHOULD try repeat sending the message to the AGW SIM6_MAX_RETRIES times. If the attendant receives a message containing a key reply for the mobile node, it sends an AAAv6 Key Reply to the mobile node. In case the generic key reply also contained a session key for access link authentication or encryption, the attendant extracts this key and stores it to its security database. 7.7. Sending Key Reply to the Mobile Node The attendant finally sends an AAAv6 reply containing a Key Reply back to the mobile node inserting the success status into the Code ICMPv6 field, and the key SPI to the key field, as received from the AGW. After this, the authentication session is completed and the mobile node's context is deleted. Kniveton, Malinen Expires September 1, 2003 [Page 37] Internet Draft SIM Authentication over IPv6 March 1, 2003 8. Mobile Node Operation The mobile node receives a modified router advertisement from a SIM6 capable access router. Then it is involved in two message exchanges with the attendant and AGW where it first sends an AAAv6 request and then receives an AAAv6 reply. 8.1. Sending SIM/Identity to the Attendant When the mobile node starts a SIM6 authentication procedure, it creates a SIM6 context into which it extracts its IMSI from the SIM card hardware as a user part of a NAI identifier. The mobile node then gets an administratively configured realm part for the NAI by which an AGW, which understands the IMSI, can be reached. The mobile node then adds to the context a reason for the session key requested, a lifetime suggestion for it, and a NONCE_MT from a good random source. The mobile node then creates a SIM/Identity Response message, which contains its NAI identifier, and sends this to the attendant, which uses the realm information to route the response to the appropriate AGW. 8.2. Receiving SIM/Start from the Attendant After the AGW responds with a SIM/Start EAP packet, the mobile node can be sure that the authentication dialog has begun, and the AGW recognizes its NAI. The mobile node then proceeds to send a SIM/Start response with information extracted from the SIM card to begin authentication. 8.3. Sending SIM/Start to the Attendant The mobile node then creates a SIM/Start EAP packet and sends it to the attendant in an AAAv6 request. The AAAv6 request contains the identifier, and the EAP object with the key lifetime proposal and the NONCE_MT. The mobile then sets a timer SIM6_TIMEOUT_MOBILE for the context in expectation of the first AAAv6 reply with SIM/Challenge back from the attendant. If no request is received in time, the mobile node's context is deleted and the authentication is considered failed. Prior to deleting the context, the mobile node SHOULD try repeat the authentication SIM6_MAX_RETRIES times starting from the beginning of the procedure, that is, resetting the context, except an increased failure count, and sending a SIM/Start. Kniveton, Malinen Expires September 1, 2003 [Page 38] Internet Draft SIM Authentication over IPv6 March 1, 2003 8.4. Receiving SIM/Challenge from the Attendant The mobile node searches for the context based on the identifier received in the message from the attendant. If no context is found, the packet is discarded. If the context was found, the mobile node extracts the n RANDs from the received message, and applies these to the SIM hardware. It then stores the n session keys and SRES responses to n triplets into the context. 8.5. Sending SIM/Challenge to the Attendant The mobile node then creates a SIM/Challenge EAP packet and sends it to the attendant in an AAAv6 request. The AAAv6 request first contains the identifier, and then the EAP object with the MAC_SRES. The mobile then sets a timer SIM6_TIMEOUT_MOBILE for the context in expectation of the Key Reply back from the attendant. If no message is received in time, the mobile node's context is deleted and the authentication is considered failed. Prior to deleting the context, the mobile node SHOULD try repeat the authentication SIM6_MAX_RETRIES times starting from the beginning of the procedure, that is, resetting the context, except an increased failure count, and sending a SIM/Start. 8.6. Receiving Key Reply from the Attendant When receiving a key reply from the attendant, the mobile node searches for the context based on the identifier received in the message from the attendant. If no context is found, the packet is discarded. Also, if the status received in the ICMPv6 Code field is other than AAAV6_STATUS_SUCCESS, the authentication is considered failed. In case of failure, prior to deleting the context, the mobile node SHOULD try repeat the authentication SIM6_MAX_RETRIES times starting from the beginning of the procedure, that is, resetting the context, except an increased failure count, and sending a SIM/Start. 9. Authentication Gateway Operation The Authentication Gateway (AGW) is considered a proxy AGW if it communicates with another AGW, otherwise it is considered an authorizing AGW. The latter may communicate with an AAAH in the GSM network, or locally authorize the session making it also an AAAH. Kniveton, Malinen Expires September 1, 2003 [Page 39] Internet Draft SIM Authentication over IPv6 March 1, 2003 The AGW is involved in two message exchanges with the mobile node via the attendant. The AGW first receives a request message and then responds with a reply message. 9.1. Receiving SIM/Start from the mobile node via the Attendant When the AGW receives a message from the mobile node via the attendant containing a SIM/Start EAP object, it does the following. First, the AGW creates a per-mobile node context where it stores the IP address from which the message was received, the identifier of the mobile node, key lifetime proposal, reason for the key exchange, and the NONCE_MT created by the mobile node. If all the needed data elements were present in the message received, the authorizing AGW requests n triplets for the given IMSI from the GSM network or from a local database. If the triplets are succesfully received, the authorizing AGW stores them to the mobile node's context and sends a message with a SIM/Challenge to the mobile node. If all the needed data elements were present in the message received, the proxy AGW forwards the mobile node's identifier and credentials towards another AGW. This AGW MAY be chosen from a priority list of next level AGWs. Configuration of this list is out of scope of the protocol, but may represent administratively configured cross-domain trust relationships, e.g. roaming agreements. The credentials in the message include elements in the EAP object. The core protocol SHOULD carry the unmodified EAP object, associated with the identifier, to the next level AGW. The proxy AGW then waits for a reply from the AGW for SIM6_TIMEOUT_AGW seconds. If no reply is received in time, or an error is received, the proxy AGW deletes the context for the mobile node. In case of failure, prior to deleting the context, the proxy AGW SHOULD try repeat sending the message SIM6_MAX_RETRIES times. It MAY repeat this for each member in the priority list of next level AGWs. In case a lower-priority next-level AGW replies, its priority on the list MAY be temporarily elevated above those of the failed next-level AGWs. If the proxy AGW receives a reply containing nRAND for the mobile node, it sends a SIM/Challenge to the mobile node. 9.2. Sending SIM/Challenge to the mobile node via the Attendant First, the AGW creates a message with the identifier and a SIM/Challenge EAP packet. The AGW then sends it to the mobile node via the node whose Kniveton, Malinen Expires September 1, 2003 [Page 40] Internet Draft SIM Authentication over IPv6 March 1, 2003 IP address was stored to the context as sender of the request message with SIM/Start. The created message first contains the identifier, after which it contains the EAP object with the nRAND and the key lifetime decided by the AGW as a function of the key lifetime proposal received from the mobile node. The EAP object is protected by the MAC_RAND field which covers the nRAND, the NONCE_MT in the mobile node's context, and the lifetime. The AGW sets a timer SIM6_TIMEOUT_AGW for the mobile node's context in expectation of a second message with SIM/Challenge back from the mobile node. If no request is received in time, the mobile node's context is deleted. 9.3. Receiving SIM/Challenge from the mobile node via the Attendant After receiving the second request message with a SIM/Challenge from the mobile node via the attendant, the AGW searches for the mobile node's context based on user part of the identifier (NAI) received from the mobile node. If no context is found, the packet is discarded. The authorizing AGW then calculates the MAC_SRES locally based on the n session keys, SRES values, IMSI, and NONCE_MT, found in the mobile node's context. If the computed PRF-value matches that of the one received in the EAP object, a success status is stored to the context, otherwise, an invalid-credentials status is stored. A proxy AGW then forwards identifier of the mobile node together with its credentials towards another AGW. This AGW MAY be chosen from a priority list of next level AGWs. Configuration of this list is out of scope of the protocol, but may represent administratively configured cross-domain trust relationships, e.g. roaming agreements. The credentials in the message include elements in the EAP object. The core protocol SHOULD carry the unmodified EAP object, associated with the identifier, to the next level AGW. The proxy AGW then waits for a reply from the AGW for SIM6_TIMEOUT_AGW seconds. If no reply is received in time, or an error is received, the proxy AGW deletes the context for the mobile node. In case of failure, prior to deleting the context, the proxy AGW SHOULD try repeat sending the message SIM6_MAX_RETRIES times. It MAY repeat this for each member in the priority list of next level AGWs. In case a lower-priority next-level AGW replies, its priority on the list MAY be temporarily elevated above those of the failed next-level AGWs. Kniveton, Malinen Expires September 1, 2003 [Page 41] Internet Draft SIM Authentication over IPv6 March 1, 2003 9.4. Sending Key Reply to the mobile node via the Attendant The authorizing AGW finally sends a generic key reply back to the mobile node via the attendant inserting the success status into the message. After this, the authentication session is completed and the mobile node's context may be deleted. If the authentication and authorization process resulted in a rejection of the mobile node's credentials, the key reply's AAAv6 Code contains an INVALID_CREDENTIAL code. In case the mobile node's context also contained a reason for sending a key to the attendant, this key is added to the message as well as a generated key SPI. The proxy AGW propagates a key reply towards the IP address in the context. Finally, the context SHOULD be deleted after 2*TIMEOUT_AGW seconds. 10. Applications of SIM Authentication over AAAv6 Applications of SIM Authentication use the Reason Subtypes of the SIM Start and AAAv6 Key Reply extensions. Numbering of different reasons is such that any combination of reasons can be indicated in a single extension. This enables distribution of the same session key for multiple purposes with one authorization message exchange. 10.1. SIM Authentication for Network Access When using Reason Subtype 1 or 2, SIM Authentication distributes a session key for the access router to be used either for access authentication or access link encryption. 10.2. SIM Authentication for Services When using Reason Subtype 4, SIM Authentication distributes a session key to a peer. This signaling will make AGW/AAAH to distribute the network copy of the session key to the host and service identified in the Peer NAI. An example service would be authentication of Mobile IPv6 Home Registration. A service MAY be identified in a Peer NAI in a SIM Start option. The NAI encodes location of the peer node in the realm part, and the service in the user part. An example encoding would be ``HA@host.domain.com'' for identifying mobile-home security association creation to home agent at DNS name host.domain.com. Kniveton, Malinen Expires September 1, 2003 [Page 42] Internet Draft SIM Authentication over IPv6 March 1, 2003 Another example could be ``unlock@door101.company.com'' for providing authorization and a session key to securely use service ``unlock'' at host identified by DNS name door101.company.com. This way, only a light IPv6 protocol stack with ICMPv6 but without upper layers is needed e.g. in control devices implementing only a simple application such as opening and closing of a lock. When an authentication gateway sends a key reply message to the peer node, this key reply message contains the peer identifier option with the NAI, and the peer MUST respond to this key reply with a key acknowledgement. The authentication gateway MUST delay sending of the key reply towards the mobile node until it receives the key acknowledgement. The format and protection of the key reply and key acknowledgement are provided by the core network signaling protocol. With direct ICMPv6 messaging as the core network signaling, the key reply is an AAAv6 request message with an identifier and a key reply option. The identifier contains the Peer NAI sent by the mobile node. The key reply contains the encoded session key in a key field. The acknowledgement is an empty key reply back to the authentication gateway with the success status encoded into this message. The format is the same as in key reply specified in Section 6.7. The identifier for the acknowledgement would have a NAI encoding as in the Peer NAI. The acknowledgement could either get back to the AGW relying on IPv6 address stored in peer attendant or proxy AGW states, or alternatively, by using NAI-based routing back where the realm part would be one routing the packet back to the authorizing AGW. In the latter case, the acknowledgement routing would be more robust while not relying on session state in intermediate nodes. An example acknowledgement encoding could be ``user_peer%realm_peer@realm_AGW'', e.g. for the second example ``unlock%door101.company.com@AGW.domain.com''. Interpretation of this key reply is: door101 acknowledges to authorizing AGW that the authorization was received with success and door101 requests AGW to forward an ack to the requesting MN. Hence, this is a generalization of MN-HA temporary key push for an arbitrary NAI-encoded service. Revocation of services can be achieved from the authorizing AGW by sending the acknowledgement as in Section 6.7 any time to both the peer and the mobile node, with code AAAV6_INVALID_CREDENTIALS. The peer can also initiate revocation by sending this message to the mobile node via the authorizing AGW. The authorizer would either forward the peer-initiated revocation, or block it, depending on authorizing policy. Kniveton, Malinen Expires September 1, 2003 [Page 43] Internet Draft SIM Authentication over IPv6 March 1, 2003 The NAI encodings for the above messages would follow the rules above. The realm part of the NAI in a key reply MUST be the realm of the destination for it. 11. Protocol Constants The protocol uses the following constants SIM6_MAX_RETRIES 6 = maximum number of retries in case of various fault cases. SIM6_TIMEOUT_AGW 4 = timeout in seconds for core signaling problems. SIM6_TIMEOUT_MOBILE 2 = timeout in seconds for access link signaling problems. 12. Security Considerations The presented extension does not weaken the security provided by AAAv6 and cellular SIM authentication. The presented extension uses existing protocols so much that its security characteristics are directly inherited from those protocols. Secret algorithm or permanent key material for SIM authentication does not get distributed to the IP network. AGW controlled by an operator is assumed to have trust relationship with the authorizing operators via roaming agreements. 13. IPv4 Considerations This protocol applies to IPv4 by adding an EAP option to router advertisements in the same way they are described here for IPv6, so Identity Requests can be sent periodically. Additionally, we must reserve two ICMP types and simply replicate the protocol as is on IPv4. 14. Intellectual Property Right Considerations On IPR related issues, Nokia refers to its statement on patent licensing. Please see http://www.ietf.org/ietf/IPR/NOKIA. Kniveton, Malinen Expires September 1, 2003 [Page 44] Internet Draft SIM Authentication over IPv6 March 1, 2003 15. Acknowledgements Authors of the document would like to thank N. Asokan and Henry Haverinen, for their contributions to the ideas used in this draft, as well as Jarno Rajahalme and Vijay Devarapalli for comments. References [1] B. Aboba and M. Beadles. The Network Access Identifier. Request for Comments (Proposed Standard) 2486, Internet Engineering Task Force, January 1999. [2] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund. AAA for IPv6 Network Access (work in progress). Internet Draft, Internet Engineering Task Force, March 2000. [3] L. Blunk and J. Vollbrecht. PPP Extensible Authentication Protocol (EAP). Request for Comments (Proposed Standard) 2284, Internet Engineering Task Force, March 1998. [4] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [5] P. Calhoun, W. Bulley, A. Rubens, and J. Haag. DIAMETER NASREQ extensions (work in progress). Internet Draft, Internet Engineering Task Force, December 1999. [6] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER base protocol (work in progress). Internet Draft, Internet Engineering Task Force, December 1999. [7] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet protocol version 6 (ipv6) specification. Request for Comments (Draft Standard) 2463, Internet Engineering Task Force, December 1998. [8] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) Specification. Request for Comments (Draft Standard) 2460, Internet Engineering Task Force, December 1998. [9] GSM Technical Specification GSM 03.03 (ETS 300 523). Digital cellular telecommunication system (Phase 2); Numbering, addressing and identification. Technical report, European Telecommunications Standards Institute, April 1997. [10] GSM Technical Specification GSM 03.03 (ETS 300 534). Digital cellular telecommunication system (Phase 2); Security, Kniveton, Malinen Expires September 1, 2003 [Page 45] Internet Draft SIM Authentication over IPv6 March 1, 2003 related network functions. Technical report, European Telecommunications Standards Institute, August 1997. [11] T. Hastings and C. Manros. Internet Printing Protocol/1.0: Implementer's Guide. Request for Comments (Informational) 2639, Internet Engineering Task Force, July 1999. [12] H. Haverinen. EAP SIM Authentication (work in progress). Internet Draft, Internet Engineering Task Force, 2002. [13] R. Hinden, R. Fink, and J. Postel deceased). IPv6 Testing Address Allocation. Request for Comments (Experimental) 2471, Internet Engineering Task Force, December 1998. [14] D. Johnson and C. Perkins. Mobility support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, November 1998. [15] C. Madson and R. Glenn. The Use of HMAC-MD5-96 within ESP and AH. Request for Comments (Proposed Standard) 2403, Internet Engineering Task Force, November 1998. [16] C. Madson and R. Glenn. The Use of HMAC-SHA-1-96 within ESP and AH. Request for Comments (Proposed Standard) 2404, Internet Engineering Task Force, November 1998. [17] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (ipv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [18] J. Vollbrecht and L. Blunk. PPP extensible authentication protocol (EAP) (work in progress). Internet Draft, Internet Engineering Task Force, January 1998. Authors' Addresses Timothy J. Kniveton Jari T. Malinen Communication Systems Lab Communication Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1 650 625-2025 Phone: +1 650 625-2355 E-Mail: timothy.kniveton@nokia.com E-Mail: jmalinen@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Kniveton, Malinen Expires September 1, 2003 [Page 46] Internet Draft SIM Authentication over IPv6 March 1, 2003 Full Copyright Statement Copyright (C) The Internet Society (2001-2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Kniveton, Malinen Expires September 1, 2003 [Page 47]