Network Working Group Timothy J. Kniveton Internet Draft Jari T. Malinen Expires: May 2002 Nokia Research Center Informational November 2001 SIM Authentication EAP extension over AAAv6 (SIM6) draft-kniveton-aaa-sim6-01.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) 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 May 2002 [Page 1] Internet Draft SIM Authentication over AAAv6 November 2001 Contents Status of This Memo 1 Abstract 1 1. Introduction 3 2. Terms 5 3. Protocol Operation 6 3.1. Access Link Signaling . . . . . . . . . . . . . . . . . . 6 3.2. Core Network Signaling . . . . . . . . . . . . . . . . . 7 3.3. Signaling diagram of SIM authentication over AAAv6 . . . 9 4. New requirements for IPv6 Nodes 10 4.1. Mobile node requirements . . . . . . . . . . . . . . . . 10 4.2. Attendant requirements . . . . . . . . . . . . . . . . . 11 4.3. Authentication Gateway requirements . . . . . . . . . . . 11 5. Protocol Messages 11 5.1. Router Advertisement / AAAv6 local challenge . . . . . . 11 5.2. AAAv6 request/EAP response/SIM/Start . . . . . . . . . . 14 5.3. AAAv6 reply/EAP request/SIM/Challenge . . . . . . . . . . 19 5.4. AAAv6 request/EAP response/SIM/Challenge . . . . . . . . 22 5.5. AAAv6 reply with key SPI . . . . . . . . . . . . . . . . 25 6. Attendant Operation 27 6.1. Sending Local Challenge to the Mobile Node . . . . . . . 27 6.2. Receiving SIM/Start from the Mobile Node . . . . . . . . 27 6.3. Sending SIM/Challenge to the Mobile Node . . . . . . . . 28 6.4. Receiving SIM/Challenge from the Mobile Node . . . . . . 28 6.5. Sending Key Reply to the Mobile Node . . . . . . . . . . 29 7. Mobile Node Operation 29 7.1. Receiving Local Challenge from the Attendant . . . . . . 29 7.2. Sending SIM/Start to the Attendant . . . . . . . . . . . 30 7.3. Receiving SIM/Challenge from the Attendant . . . . . . . 30 7.4. Sending SIM/Challenge to the Attendant . . . . . . . . . 30 7.5. Receiving Key Reply from the Attendant . . . . . . . . . 31 8. Authentication Gateway Operation 31 8.1. Receiving SIM/Start from the mobile node via the Attendant 31 8.2. Sending SIM/Challenge to the mobile node via the Attendant 32 8.3. Receiving SIM/Challenge from the mobile node via the Attendant . . . . . . . . . . . . . . . . . . . . . . . . 33 Kniveton, Malinen Expires May 2002 [Page 2] Internet Draft SIM Authentication over AAAv6 November 2001 8.4. Sending Key Reply to the mobile node via the Attendant . 33 9. Applications of SIM Authentication over AAAv6 34 9.1. SIM Authentication for Network Access . . . . . . . . . . 34 9.2. SIM Authentication for Services . . . . . . . . . . . . . 34 10. Protocol Constants 35 11. Security Considerations 36 12. IPv4 Considerations 36 13. Intellectual Property Right Considerations 36 14. Acknowledgements 36 Authors' Addresses 38 Full Copyright Statement 38 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 9. 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 [15] can benefit from such a mechanism in that, for example, no static mobile-home security association configuration is needed. The presented protocol is 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. 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. Kniveton, Malinen Expires May 2002 [Page 3] Internet Draft SIM Authentication over AAAv6 November 2001 +-------------------------+ | [A] | | +--------+ | | | | | | +-----+ AAAH | | | | | | | | | +--------+ | | +--------+ | | | | | +---| AGW |------------+ | | +---+----+ | +------|-------+ | +---+----+ | | | | | | | AAAL | | | | | | | +---+----+ | | [B] | | +--------+ | +---+----+ | +--------+ | | | | | | | [C] | | MN |---------| AR/LA |------------+ Peer | | | | | | | |e.g. HA | +--------+ | +--------+ | +--------+ +--------------+ Figure 1: Network Reference for SIM Authentication over AAAv6 The protocol does not require changes to network entities neither in the IPv6 network nor in the cellular network nor 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 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 provides a local challenge which is returned by the mobile node in the first key request. Then, a mobile Kniveton, Malinen Expires May 2002 [Page 4] Internet Draft SIM Authentication over AAAv6 November 2001 node transmits its International Mobile Subscriber Identifier (IMSI) [9] in a key request to an authentication gateway (AGW). It returns a SIM challenge to the mobile node which responds with a SIM response in the second message, computed locally by the SIM module. The 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 [15] home agent (Section 9), 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 [16] and HMAC-SHA-1-96 [17] are the suggested pseudo-random functions used. Protocol version 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 5. 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: Challenge A random number provided by the initiator to verify that Kniveton, Malinen Expires May 2002 [Page 5] Internet Draft SIM Authentication over AAAv6 November 2001 a message containing the returned challenge is sent by recipient of the challenge. Randomness in the challenge provide freshness to ensure that the returned message cannot be replayed. 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 [19], an authentication protocol used with PPP[14] 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. This terminology is intended to conform to those that have been used in IPv6, Mobile IPv6, AAA, and other Internet protocols [8, 15, 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 [13]. The protocol signaling is illustrated in Figure 2. 3.1. Access Link Signaling The access router sends a local challenge 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. A local challenge is used for replay protection in the first request by the mobile node. After receiving a router advertisement with a local challenge, the mobile node returns an AAAv6 request. This contains the challenge, together with a registration identity of the mobile node and a SIM key request. The identity is an ID option of AAAv6. The ID contains a Network Access Identifier (NAI) in a 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 Kniveton, Malinen Expires May 2002 [Page 6] Internet Draft SIM Authentication over AAAv6 November 2001 authentication gateway (AGW/AAAH). A special realm GSMSIM_NAI_REALM is used to find the first available authentication gateway. 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 a SIM challenge (nRAND) from the authentication gateway, it sends an AAAv6 reply back to the mobile node with the SIM challenge embedded to an EAP Request/SIM/Challenge. 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. 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. 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 8) provides for multi-hop core network signaling as a fallback or for interoperation. Each Kniveton, Malinen Expires May 2002 [Page 7] Internet Draft SIM Authentication over AAAv6 November 2001 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 May 2002 [Page 8] Internet Draft SIM Authentication over AAAv6 November 2001 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. Client Router System AAAL AAAH Peer (e.g.MN) +........+ | (AGW) (e.g.HA) | .UCP CP . | | | | LC,aID . | | . | | | 5.1.|<--------------------| | . | | | | . | | . | | | | ARq#1:LC,cID,Start. | | . | | | 5.2.|-------------------->| AHR#1:aID,cID,Start | | | | . |-------------------->| AHR#1 | | | . | | . |------>| | | . | | . | | | | . | | . | AHA#1 | | | . | AHA#1:cID,nRAND |<------| | | ARp#1:LC,cID,nRAND. |<--------------------| | | 5.3.|<--------------------| | . | | | GKm | . | | . | | | | ARq#2:LC,cID,mSRES. | | . | | | 5.4.|-------------------->| | . | | | | . | AHR#2:aID,cID,mSRES | | | | . |-------------------->| AHR#2 | | | . | | . |------>| | | . | | . | | (KR) | | . | | . | |---------->| | . | | . | | SKn| | . | | . | | (KR) | | . | | . | AHA#2 |<----------| | . | | . |<------| | | . | AHA#2:cID,KR | | | | . |<--------------------| | | | . | | . | | | | . |UPD | . | | | | ARp#2:status,KR . |--->| . | | | 5.5.|<--------------------| | . | | | | . | | . | | | +........+ Figure 2: Signaling of SIM Authentication EAP extension over AAAv6 and core network AAA signaling Kniveton, Malinen Expires May 2002 [Page 9] Internet Draft SIM Authentication over AAAv6 November 2001 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 [15] AAAL - Local AAA Server [2] AGW/AAAH - Authentication Gateway/AAA Home Server [2] HA - Mobile IPv6 Home Agent [15] CN - Mobile IPv6 Correspondent Node [15] CP - Controlled part of a router system [2] RTSOL - ICMPv6 Router Solicitation [18] LC - Local Challenge [2] cID - Client (MN) Network Access Identifier [1] CR - Credentials (EAP/SIM Start) [2] nRAND - EAP/SIM Challenge [13] mSRES - EAP/SIM Response [13] Start - EAP/SIM Start [13] 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 a 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 need 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 key reply extension. 4.1. Mobile node requirements The mobile node is required to have an extension to its router discovery understanding the local challenge, and an extension to AAAv6 signaling which recognizes the SIM6 EAP types and protocol stages. Mobile node maintains an autentication session context state. Kniveton, Malinen Expires May 2002 [Page 10] Internet Draft SIM Authentication over AAAv6 November 2001 4.2. Attendant requirements The attendant is required to be able to extend a local challenge to 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 as well as a most recently sent local challenge cache for replay protection. 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 authetication 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. 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. 5.1. Router Advertisement / AAAv6 local challenge When the mobile node arrives at the visited network, it receives a router advertisement as specified by Neighbor Discovery [18] and modified by Mobile IPv6 [15] from the local router. This router advertisement contains a ``challenge,'' which is essentially a random number used as a nonce for replay protection. The entire message appears as follows: {1} IPv6 Header [8] {2} Router Advertisement [8, 15] {3} Router Advertisement Options Kniveton, Malinen Expires May 2002 [Page 11] Internet Draft SIM Authentication over AAAv6 November 2001 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Router Advertisement / AAAv6 local challenge May include Target Link-layer address, Prefix Information Options,... {4} AAAv6 Challenge Option in the router advertisement This additional option is the only change from the normal router advertisements the access router/AAAv6 Attendant would already be sending. Type 9 = ICMPv6 Router Advertisement Local Challenge Option Length 1 = Length in 8 octets including the type and length fields Reserved 0 = Ignored on reception Kniveton, Malinen Expires May 2002 [Page 12] Internet Draft SIM Authentication over AAAv6 November 2001 Challenge This is a 32-bit random number generated by the access router and used to prevent replay attacks. Kniveton, Malinen Expires May 2002 [Page 13] Internet Draft SIM Authentication over AAAv6 November 2001 5.2. AAAv6 request/EAP response/SIM/Start This section describes the message the mobile node sends to initiate 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'' because this SIM authentication procedure is extracted from a larger Kniveton, Malinen Expires May 2002 [Page 14] Internet Draft SIM Authentication over AAAv6 November 2001 message flow which would include the PPP-EAP signaling sending an earlier message. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {5}| Type |WH |Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5b}| Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Lifetime Proposal | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NONCE_MT | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer NAI (optional)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: AAAv6 request/EAP response/SIM/Start {1} IPv6 Header SRC = mobile node; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6) {2} ICMPv6 Header [7] Kniveton, Malinen Expires May 2002 [Page 15] Internet Draft SIM Authentication over AAAv6 November 2001 Type 151 (97h) [TBD] = AAAv6 Request Code 0 - For AAA request, not defined Checksum Calculated as defined in [7]. {3} AAA Client Identifier Option [2] Type 1 (unskippable) = Client Identifier Option. 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 3.2 of [12]. {4} AAAv6 Challenge Option [2] Type 3 (unskippable) = Challenge option. Subtype 0 = Local Challenge Length 4 = Length of the challenge in octets. Challenge The actual challenge data, as picked from the router advertisement (Section 5.1). Kniveton, Malinen Expires May 2002 [Page 16] Internet Draft SIM Authentication over AAAv6 November 2001 {5} AAAv6 Embedded Data Option [2] Type 8 (unskippable) = Embedded Data Option WH binary 10 = AAAH Subtype 3 = EAP Response Length 28 (+ size of Peer NAI) = Length of Embedded Data {5b} in octets. {5b} EAP-Response/SIM/Start [13] 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 28 (+ size of Peer NAI) = Length of the whole EAP extension in octets. Type 18 = EAP type for EAP/SIM authentication. Subtype 1 = SIM/Start. Version 1 = The EAP/SIM protocol version. Kniveton, Malinen Expires May 2002 [Page 17] Internet Draft SIM Authentication over AAAv6 November 2001 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 [13]). Key Lifetime Proposal Client's key lifetime proposal in seconds (four bytes). NONCE_MT A random number generated by the client (16 bytes), which is used as a seed value for the new key. 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. Kniveton, Malinen Expires May 2002 [Page 18] Internet Draft SIM Authentication over AAAv6 November 2001 5.3. 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {5}| Type |WH |Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5b}| Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC_RAND | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n*RAND ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: AAAv6 reply/EAP request/SIM/Challenge {1} IPv6 Header SRC = AAAv6 Attendant; DEST = mobile node; NxtHDR = 58 (ICMPv6) {2} ICMPv6 Header [7] Kniveton, Malinen Expires May 2002 [Page 19] Internet Draft SIM Authentication over AAAv6 November 2001 Type 153 (99h) [TBD] = AAAv6 Reply {3} AAA Client Identifier Option See Section 5.2. {4} AAAv6 Challenge Option [2] Type 3 (unskippable) = Challenge option. Subtype 0 = Local Challenge Length 4 = Length of the challenge in octets. Challenge The actual challenge data, randomized in the router from the same generator as for router advertisement (Section 5.1). {5} 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 60 (3ch) = Length of Embedded Data {4b} in octets. {5b} EAP-Request/SIM/Challenge [13] Kniveton, Malinen Expires May 2002 [Page 20] Internet Draft SIM Authentication over AAAv6 November 2001 Code 1 = Request Identifier The identifier field is one octet and aids in matching responses with requests [3]. Length 28 + n*16 octets, where n is the number of RAND challenges given in this EAP Request, now 60. Type 18 = EAP type for EAP/SIM authentication. Subtype 2 = SIM/Challenge. Version 1 = the EAP/SIM protocol version. 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- Response/GSMSIM/Start. The key lifetime must be greater than zero. 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) [13], 16 octets, where n*Kc are the n session keys. N*RAND N GSM RANDs (16 bytes each), now n=2, 32 octets. Kniveton, Malinen Expires May 2002 [Page 21] Internet Draft SIM Authentication over AAAv6 November 2001 5.4. 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ {5}| Type |WH |Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5b}| Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Version | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC_SRES | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: AAAv6 request/EAP response/SIM/Challenge {1} IPv6 Header SRC = mobile node; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6) {2} ICMPv6 Header [7] Kniveton, Malinen Expires May 2002 [Page 22] Internet Draft SIM Authentication over AAAv6 November 2001 Type 151 (97h) [TBD] = AAAv6 Request {3} AAA Client Identifier Option See Section 5.2. {4} AAAv6 Challenge Option [2] Type 3 (unskippable) = Challenge option. Subtype 0 = Local Challenge Length 4 = Length of the challenge in octets. Challenge The actual challenge data, as received in the first AAAv6 reply (Section 5.3). {5} AAAv6 Embedded Data Option Type 8 = Embedded Data Option WH binary 10 = AAAH should process embedded data. Subtype 3 = EAP Response Length 24 (18h) = Length of Embedded Data {4b} in octets. {5b} EAP-Response/SIM/Challenge [13] Kniveton, Malinen Expires May 2002 [Page 23] Internet Draft SIM Authentication over AAAv6 November 2001 Code 2 = Response Identifier The identifier field is one octet and aids in matching responses with requests [3]. Length 24 = Length of the whole EAP extension in octets. Type 18 = EAP type for EAP/SIM authentication. Subtype 2 = SIM/Challenge. Version 1 = the EAP/SIM protocol version. MAC_SRES The response calculated by the client defined by a pseudo-random function PRF(n*Kc, n*SRES | IMSI | NONCE_MT) [13], 16 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 May 2002 [Page 24] Internet Draft SIM Authentication over AAAv6 November 2001 5.5. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: AAAv6 reply with key SPI {1} IPv6 Header SRC = AAAv6 Attendant; DEST = mobile node; NxtHDR = 58 (ICMPv6) {2} ICMPv6 Header [7] Type 153 (99h) [TBD] = AAAv6 Reply Kniveton, Malinen Expires May 2002 [Page 25] Internet Draft SIM Authentication over AAAv6 November 2001 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 INVALID_CREDENTIAL: 50 - Bad MAC_SRES Checksum Calculated as defined in [7]. {3} AAA Client Identifier Option See Section 5.2. {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 5.2, message part 5b, 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. 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. Kniveton, Malinen Expires May 2002 [Page 26] Internet Draft SIM Authentication over AAAv6 November 2001 Note that the Encoded Key field is not sent with this message, as the key has already been generated at the mobile node. 6. Attendant Operation The attendant modifies its router advertisement. Further, 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. 6.1. Sending Local Challenge to the Mobile Node The attendant randomizes a local challenge as a value extracted from a good random generator. It then attaches that to each router advertisement and stores the sent local challenge. The attendant SHOULD maintain a local challenge cache of three recently advertised challenges. When the local challenge cache has reached its size three first router advertisements after initialization, the attendant starts to delete oldest challenges together with their associated state from the local challenge cache each time a new challenge is stored. 6.2. Receiving SIM/Start from the Mobile Node When the attendant receives an AAAv6 request from the mobile node containing a SIM/Start EAP object, it does the following. First, the attendant creates an AAAv6 context where it stores the identifier of the mobile node as well as the local challenge. Then it compares the received challenge against those in the set of recently sent challenges to see if a mobile node already has used the challenge. If the challenge is not found or has already been used by the mobile node, the attendant silently drops the packet and deletes the context, to counter a possible replay attack. If the challenge was found and still unused for this mobile node, the attendant marks the challenge as used and proceeds. 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: version of the protocol, 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 Kniveton, Malinen Expires May 2002 [Page 27] Internet Draft SIM Authentication over AAAv6 November 2001 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. If the attendant receives a reply containing nRAND for the mobile node, it sends a SIM/Challenge to the mobile node. 6.3. 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. 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, then a fresh local challenge, 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. 6.4. Receiving SIM/Challenge from the Mobile Node After receiving the second AAAv6 request with a SIM/Challenge from the mobile node, the attendant checks validity of the local challenge the same way as when receiving a SIM/Start. Then, the attendant searches Kniveton, Malinen Expires May 2002 [Page 28] Internet Draft SIM Authentication over AAAv6 November 2001 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. 6.5. 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. 7. 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. 7.1. Receiving Local Challenge from the Attendant When the randomized local challenge is recognized in a router advertisement, the mobile node recognizes that the router supports the attendant functionality. The mobile node can then at any suitable time start a SIM6 authentication procedure, e.g. when network access authorization is needed. Recognition when such a need exists is out of scope of this document, but this may be triggered e.g. by some capability flag in the router advertisement combined with mobile node's internal state. Kniveton, Malinen Expires May 2002 [Page 29] Internet Draft SIM Authentication over AAAv6 November 2001 7.2. Sending SIM/Start 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/Start EAP packet and sends it to the attendant in an AAAv6 request. The AAAv6 request first contains the returned local challenge, 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. In the repeated attempts, a new local challenge MUST be obtained every time. If the router advertisement frequency is too low, a router solicitation SHOULD be issued prior to every repeated attempt. 7.3. Receiving SIM/Challenge from the Attendant After receiving the first AAAv6 reply with a SIM/Challenge from the attendant, the mobile node stores the local challenge just like when receiving a router advertisement with such a challenge. Then, the mobile node searches for the contex 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. 7.4. 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 Kniveton, Malinen Expires May 2002 [Page 30] Internet Draft SIM Authentication over AAAv6 November 2001 the identifier, after which it contains the previously stored local challenge, 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. 7.5. Receiving Key Reply from the Attendant When receiving a key reply from the attendant, the mobile node searches for the contex 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. 8. 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. 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. 8.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, version of the protocol, 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 Kniveton, Malinen Expires May 2002 [Page 31] Internet Draft SIM Authentication over AAAv6 November 2001 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. 8.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 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. Kniveton, Malinen Expires May 2002 [Page 32] Internet Draft SIM Authentication over AAAv6 November 2001 8.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. 8.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. 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. Kniveton, Malinen Expires May 2002 [Page 33] Internet Draft SIM Authentication over AAAv6 November 2001 9. 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 differen 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. 9.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. 9.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. 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. Kniveton, Malinen Expires May 2002 [Page 34] Internet Draft SIM Authentication over AAAv6 November 2001 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 5.5. 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 5.5 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. 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. 10. 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. Kniveton, Malinen Expires May 2002 [Page 35] Internet Draft SIM Authentication over AAAv6 November 2001 11. 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. 12. IPv4 Considerations This protocol applies to IPv4 by simply reserving two ICMP types and replicating the protocol as is on IPv4. A specification for local challenges in IPv4 router advertisements exist among AAA proposals. 13. 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. 14. 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. Kniveton, Malinen Expires May 2002 [Page 36] Internet Draft SIM Authentication over AAAv6 November 2001 [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, 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. GSM SIM Authentication and Key Generation for Mobile IP (work in progress). Internet Draft, Internet Engineering Task Force, November 2000. [13] H. Haverinen. EAP SIM Authentication (Version 1) (work in progress). Internet Draft, Internet Engineering Task Force, February 2001. [14] R. Hinden, R. Fink, and J. Postel deceased). IPv6 Testing Address Allocation. Request for Comments (Experimental) 2471, Internet Engineering Task Force, December 1998. Kniveton, Malinen Expires May 2002 [Page 37] Internet Draft SIM Authentication over AAAv6 November 2001 [15] D. Johnson and C. Perkins. Mobility support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, November 1998. [16] 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. [17] 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. [18] 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. [19] 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 Communications Systems Lab Communications 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 EMail: Timothy.Kniveton@Nokia.com EMail: jmalinen@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Full Copyright Statement Copyright (C) The Internet Society (2000). 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, Kniveton, Malinen Expires May 2002 [Page 38] Internet Draft SIM Authentication over AAAv6 November 2001 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 May 2002 [Page 39]