Internet Engineering Task Force INTERNET-DRAFT L. Salgarelli, draft-salgarelli-pppext-eap-ske-01.txt M. Buddhikot, J. Garay, Date: April 2002 S. Miller, U. Blumenthal, Expires: October 2002 S. Patel, P. Dahl, D. Stanley, C. Carroll EAP SKE authentication and key exchange protocol Status of this memo This document is an individual contribution for consideration by the PPPEXT Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. 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 This note describes EAP Shared Key Exchange (SKE), a method for authentication of Mobile Nodes (MN) and generation of a per session, per node EAP Master Secret. The method applies to scenarios where a Mobile Node (MN) is in a foreign network such as a public 802.11 or 802.3 network that uses Home-AAA and Foreign-AAA services. The method requires presence of a pre-deployed cryptographically secure shared key on the MN and its Home-AAA server, and use of the 802.1x standard [1], Extensible Authentication Protocol (EAP) [2] messages, and RADIUS [3] authentication servers. The protocol can easily be extended to support the migration from RADIUS to DIAMETER [4]. Salgarelli et al. Expires 10/02 [Page 1] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 Contents 1 Introduction 2 2 Terminology 3 2.1 Notation ................................................. 3 3 EAP-SKE authentication and dynamic key exchange 5 3.1 Assumptions .............................................. 5 3.2 Protocol requirements .................................... 7 3.3 Protocol description ..................................... 8 4 Security Considerations 11 4.1 Considerations on misbehaving nodes in foreign access networks 12 5 Alternate network scenarios 13 6 Recommendation for MAC and PRF algorithms 13 7 Message formats 14 7.1 EAP-SKE message formats .................................. 14 7.1.1 EAP-Request/SKE-AS-Challenge....................... 14 7.1.2 EAP-Response/SKE-MN-Challenge...................... 16 7.1.3 EAP-Request/SKE-AS-Verify.......................... 17 7.1.4 EAP-Response/SKE-Success........................... 18 7.1.5 EAP-Response/SKE-Failure........................... 19 7.2 RADIUS messages .......................................... 20 7.2.1 RADIUS SKE attribute............................... 21 8 IANA and Protocol Numbering Considerations 23 9 Migration to DIAMETER 23 10 Open Issues 24 Salgarelli et al. Expires 10/02 [Page 2] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 1 Introduction In this document, we describe a new EAP authentication and key exchange method, EAP-Shared Key Exchange (EAP-SKE), which (1) supports mutual authentication between the MN and a Home-AAA (H-AAA); (2) provides for the generation of the EAP Master Secret necessary to derive per-user, per-session EAP Master Session Keys [5, 6]; and (3) supports efficient roaming across multiple network provider networks by significantly reducing the number of messages required to perform steps (1) and (2) above. This is particularly important in roaming scenarios, where the delay involved in exchanging messages with a distant H-AAA has a critical impact on the latency of the overall authentication procedure. Finally, (4) the protocol is stateless and therefore it realizes the aforementioned goals without requiring state to be maintained at the AAA servers in between sessions. 2 Terminology 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 [7]. 2.1 Notation The following notation is used throughout this document: A_(A,B) A security association between nodes A and B, as defined in [8], which includes a shared secret key known to A and B, and allows the secure exchange of information between nodes A and B. AAA Authentication, Authorization and Accounting (server). Same as the Authentication Server in the IEEE 802.1x terminology. For simplicity, we will use the term AAA server throughout this document. H-AAA: Home AAA; F-AAA: Foreign AAA. Salgarelli et al. Expires 10/02 [Page 3] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 Authenticator System (AS) An IEEE 802 LAN entity that uses port based network access control. For example, in case of an IEEE 802.11 LAN, an Access Point (AP) may be an authenticator system. An AS consists of (1) a Port Access Entity (PAE) that plays the role of an authenticator to authenticate a user, and (2) an entity that provides the network access service offered by the AS. In the remaining document, we will refer to the PAE entity as AS-PAE. AS-PAE See Authenticator System above. K_(A,B) A shared secret key known to nodes A and B. K_EMS The negotiated EAP Master Secret as defined in [5, 6]. K_EMS can then be used to derive Master Session Keys described in [6]. Example methods of such key derivation are specified in section 3.5 of [9] and in [10]. MAC(K,.) Message Authentication Code (or integrity check function), which is applied to a piece of information for authentication using a key K. Examples include keyed cryptographic hash functions (e.g., keyed-MD5 [11], keyed-SHA-1 [12, 13], HMAC [14, 15], etc.), and block ciphers (e.g., AES in CBC-MAC mode [16]). MN Mobile Node. NSP Network Service Provider. N_1/2/3 A nonce, in this case a freshly generated (unstructured) random number. Nonces are typically implemented as pseudo-random bit strings of length 64-128. In EAP-SKE, N_2 and N_3 can optionally be implemented as non-repeating and non-synchronized counters. PRF(K,.) A pseudo-random function with key K. Pseudo-random functions [17] are characterized by the pseudo-randomness of their output, namely, each bit in the output of the function is unpredictable if K is unknown. We use pseudo-random functions for the derivation of the EAP master secret given the shared key K. In practice, pseudo-random functions are Salgarelli et al. Expires 10/02 [Page 4] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 realized using AES in CBC-MAC mode (and other block ciphers), or keyed one-way hash functions (see examples of MAC functions above). Supplicant A 802 LAN port that wishes to obtain (network) services offered by the AS. The mobile node (MN) in an 802.1x network will contain an entity that serves as a supplicant. For brevity, we refer to such an entity as MN-SUP. 3 EAP-SKE authentication and dynamic key exchange It is desirable that when a MN roams into a foreign 802 network, its supplicant should be able to establish credentials with the NSP of the foreign network to obtain network access. One example of this is as follows: user John Doe who has an account with, say, carrier.com roams into a public network in a mall or airport run by an NSP such as (hypothetical) airport-mall.net. It is desirable that John be able to present his credentials with carrier.com to airport-mall.net to authenticate himself and obtain network access. The access charge for this service is later posted to John's monthly access bill with his carrier via a revenue settlement agreement between the two NSPs. This requires (a) that the AAA services employed by carrier.com and airport-mall.net peer with each other using pre-established secure channels and (b) that a database of AAA services be exchanged among the providers. Such a scenario already exists between providers which provide network access to roaming dial-up customers. 3.1 Assumptions We assume that as a part of a service contract with a network provider (say carrier.com), the supplicant has (1) a pre-configured network access identifier (NAI) (e.g., john.doe@carrier.com), and (2) a pre-configured security association with its Home AAA server (H-AAA), which includes a sufficiently long (say, 128 bit) key K_(MN,H-AAA), as shown in Figure 1. At the same time, we assume that each AS-PAE in the foreign domain has a pre-configured security association A_(AS-PAE,F-AAA) with the F-AAA, which allows the F-AAA and the AS-PAE to authenticate and encrypt the messages that they exchange. The mechanism by which these security associations are setup is outside the scope of this document. We also assume that a security association A_(F-AAA,H-AAA) exists between the F-AAA and H-AAA, which allows the F-AAA and H-AAA to Salgarelli et al. Expires 10/02 [Page 5] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 |<.............K_(MN,H-AAA)............>| . . +--------+ . NAI...> | MN-SUP | . +--------+ . |<...A_(F-AAA,H-AAA)..>| . . |<.A_(AS-PAE,F-AAA).>| . . . . . +-------+ +-------+ . | F-AAA | | H-AAA | . +-------+ +-------+ . | | +--------+ | | | AS-PAE | | /\/\/\/\/\/\/\/\/\/\/\ +--------+ | \ / | +--------+ / Internet \ ----------------| Router |---\ / +--------+ \/\/\/\/\/\/\/\/\/\/\/ Figure 1: Entities in the proposed 802.1x architecture authenticate and encrypt each other's messages. This association is setup as part of the roaming agreement between the foreign and home domains, and allows the home domain to trust the AAA servers and the AS-PAEs of the foreign domain. The mechanism by which this security association is setup is outside the scope of this document. Furthermore, we assume that the F-AAA and the AS-PAE are trusted network elements, and that they will not deviate from the execution of the protocol. Note that a number of proxy AAA servers MAY be present in the path between the AS-PAE and the F-AAA and between the F-AAA and the H-AAA. In this case we assume that a pre-set security association exists between any pair of adjacent nodes on the network path between the AS-PAE and the H-AAA. Clearly, in this scenario, roaming clients might find themselves logging on to foreign networks that are distant -- in terms of number of hops -- from the their H-AAA and therefore may experience long authentication delays. Minimizing the number of messages that the client has to Salgarelli et al. Expires 10/02 [Page 6] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 exchange with its H-AAA is critical to minimizing such authentication delay. Given the objectives of minimizing latency and complexity of the authentication procedure, protocols that do not require state to be kept synchronized between the client and the AAA servers are preferred to protocols that do require such state maintainance across sessions. Finally, Figure 1 only represents logical network elements. In actual implementations the F-AAA and H-AAA might be a single server, with a chain of trusted AAA proxy servers between it and the AS-PAE. More details on this will be given in section 5. 3.2 Protocol requirements Given the assumptions and conditions outlined above, our protocol must meet the following objectives: Network Efficiency: Keep both the number of messages exchanged between the parties and the computational overhead to a minimum. This means also that the latency of the authentication process must be kept to a minimum. Ideally, only one message exchange should take place between the Foreign network and the H-AAA to perform authentication and Session Master Key distribution. Secrecy and Authenticity: Guarantee the participating entities that only the intended parties learn the Master Session Keys exchanged, and that these keys are fresh, random and unique. Specifically, the scheme should support the following: o Requirement 1 (Authenticate MN-SUP): Allow H-AAA to authenticate and authorize that the MN-SUP has rights to establish a security association with, and receive service from the AS in a foreign domain with which the home domain has a roaming agreement. o Requirement 2 (Authenticate H-AAA): Allow the MN-SUP to establish that it is authenticating to a trusted H-AAA that is in possession of K_(MN-SUP,H-AAA); o Requirement 3 (Master Session Key Establishment): generate the EAP Master Secret K_EMS necessary to derive the EAP Master Session Keys [6]. Guarantee both MN supplicant and H-AAA that K_EMS is fresh, random and unique. Salgarelli et al. Expires 10/02 [Page 7] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 Forward Secrecy: When used in this document forward secrecy refers to the notion that compromise of the Master Session Keys will permit access only to data protected by those keys. In other words, even if an attacker is eventually able to derive the Master Session Keys for one session, future (and past) session keys (and, of course, the pre-shared key K_(MN-SUP,H-AAA)) are not compromised. EAP-SKE only defines the mechanism by which the EAP Master Secret K_EMS is derived, and relies on mechanisms specified elsewhere (for example section 3.5 of [9] and [10]) to derive the Master Session Keys. Therefore, forward secrecy of the Master Session Keys derives from forward secrecy of K_EMS, assuming that the key explosion mechanism used preserves this property. See, e.g., [18, 19, 10] for more general notions of forward secrecy. Simplicity: The scheme must be amenable to analysis and formal security proof. Statelessness: The scheme must not require state to be maintained at the AAA servers and at the clients in between sessions. This requirement eliminates the state re-synchronization overheads incurred by stateful protocols. 3.3 Protocol description Figure 2 describes a successful EAP-SKE authentication and key exchange procedure, involving a client (MN-SUP), an 802.1x Port Access Entity (AS-PAE), a Foreign and a Home AAA (F-AAA and H-AAA). The EAP-SKE exchange proceeds as follows: Phase 1: F-AAA obtains identity and realm of user. The AS-PAE issues an EAP-Request/ID frame. The MN responds with an EAP-Response/ID message that includes its NAI. The AS-PAE forwards the EAP-Response in a RADIUS Access-Request message to the F-AAA. Salgarelli et al. Expires 10/02 [Page 8] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 +------+ +------+ +-----+ +-----+ |MN-SUP| |AS-PAE| |F-AAA| |H-AAA| +------+ +------+ +-----+ +-----+ | | | | / | EAP-Rqst/ID | | | | |<---------------| | | 1:| | EAP-Resp/ID | RAD-Acc-Rqst | | | |--------------->| EAP-Resp PassThr | | \ | |----------------->| | | | | | / | | RAD-Acc-Chal | | | | |EAP-Rqst/SKE w/N_1| | | |EAP-Rqst PassThr|<-----------------| | | |<---------------| | | 2:| | | | | | | EAP-Resp/SKE w/| | | | | N_2, AUTH1 | RAD-Acc-Rqst | | | |--------------->| EAP-Resp PassThr | | \ | |----------------->| RAD-Acc-Rqst w/ | / | | | NAI, N_1, N_2, AUTH1 | | | | |---------------------->| | | | | | 3:| | | | | | | | | RAD-Acc-Accept w/ | | | | RAD-Acc-Chal |N_3, MastSessKey, AUTH2| \ | | EAP/SKE-Vrfy w/ |<----------------------| / | | N_3, AUTH2 | | | |EAP/SKE PassThr |<-----------------| | | |<---------------| | | | | | RAD-Acc-Rqst | | 4:| | EAP/SKE-Success| EAP/SKE PassThr | | | |--------------->|----------------->| | | | | | | | | | RAD-Acc-Accept w/| | | | | MastSessKey | | | | EAP PassThr | EAP-Success | | \ |<---------------|<-----------------| | Figure 2: Successful SKE authentication and key exchange Salgarelli et al. Expires 10/02 [Page 9] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 Phase 2: F-AAA challenges MN and obtains MN's challenge and authenticator AUTH1. The F-AAA generates a random challenge N_1. The F-AAA then issues an EAP-Request/SKE-AS-Challenge message with N_1, and sends it to the AS-PAE encapsulated in a RADIUS Access-Challenge message. The AS-PAE forwards the EAP-Request to MN. Reception of this packet signals to the MN-SUP that the F-AAA is requesting authentication scheme EAP-SKE. In the event MN-SUP does not support the scheme, it will send EAP-Response of type NAK. Otherwise, MN-SUP generates a nonce N_2 and computes the authenticator AUTH1 = MAC(K_(MN-SUP,H-AAA), N_1 | N_2 | NAI). The MN-SUP sends N_2 with the authenticator AUTH1 back to the AS-PAE in an EAP-Response/SKE-MN-Challenge packet. The AS-PAE forwards this EAP-Response to the F-AAA in a RADIUS Access-Request message. Phase 3: H-AAA authenticates the user, generates its own authentication information and generates the Master Session Keys. The F-AAA forwards the user's NAI, N_1, N_2 and AUTH1 to H-AAA in a RADIUS Access-Request message. On receipt of the Access-Request, the H-AAA server does the following: 1. Looks up K_(MN-SUP,H-AAA), the key for user `NAI'; 2. Calculates the Authenticator AUTH1' = MAC(K_(MN-SUP,H-AAA), N_1 | N_2 | NAI) as explained in Phase 2 above. 3. Compares AUTH1' with the received AUTH1. If the two do not match, authentication fails and the H-AAA server will send a RADIUS Access-Reject. If the authentication succeeds, the H-AAA undertakes the following steps: 4. Computes the authenticator AUTH2 = MAC(K_(MN-SUP,H-AAA), N_2 | N_1 | NAI). (Note change in the order of arguments with respect to AUTH1.) 5. Generates nonce N_3. Salgarelli et al. Expires 10/02 [Page 10] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 6. Computes the EAP Master Secret K_EMS as K_EMS = PRF(K_(MN-SUP,H-AAA), N_3 | AUTH2). 7. Derives the Master Session Keys from K_EMS. 8. Forwards AUTH2, N_3 and the Master Session Keys to F-AAA in a RADIUS Access-Accept. Phase 4: MN authenticates H-AAA, AS-PAE receives session keys. Upon receipt of the RADIUS Access-Accept message, the F-AAA sends AUTH2 and N_3 in an EAP-Request/SKE-AS-Verify message encapsulated in a RADIUS Access-Challenge message to the AS-PAE. The AS-PAE relays the EAP-Request/SKE-AS-Verify message to the MN. The MN first uses N_1 and N_2 to compute AUTH2' as in Phase 3 above and compares it with the supplied AUTH2. If the two match, it concludes that its request was processed by a valid H-AAA, and concludes the SKE exchange with an EAP-Response/SKE-Success message. If the two do not match, the MN MUST send a EAP-Response/SKE-Failure message. After receiving the EAP-Response/SKE-Success, the F-AAA issues an EAP-Success message and the Master Session Keys in a RADIUS Access-Accept message. The AS-PAE receives this message, extracts the Master Session Keys from the RADIUS message for its local use and forwards the decapsulated EAP-Sucess message to MN. At this point MN concludes that the EAP authentication has succeeded and then, using K_(MN-SUP,H-AAA), N_3 and AUTH2, it generates K_EMS and the Master Session Keys following the exact same procedure used at the H-AAA server. Note that the Master Session Keys are not transmitted from the AS-PAE to the MN but are locally computed. 4 Security Considerations Let us recall the assumptions we made in section 3.1. In particular, we assume that AS-PAE and F-AAA are network elements which are trusted by the H-AAA, by virtue of the existence of A_(H-AAA,F-AAA) and A_(AS-PAE,F-AAA), and do not misbehave. Consider authenticators AUTH1 and AUTH2 in Phases 2 and 3, respectively. The nonces N_1 and N_2 in the authenticators act as challenges to H-AAA and MN to "prove" to each other the possession of the pre-shared key K_(MN-SUP,H-AAA). Moreover, including N_1 Salgarelli et al. Expires 10/02 [Page 11] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 (respectively, N_2) assures the H-AAA (resp., the MN) that the authenticator is fresh for every session. The fact that N_1 is generated by the F-AAA and not by the H-AAA does not invalidate this claim, since the F-AAA is trusted by the H-AAA by virtue of A_(H-AAA,F-AAA). The included identities (i.e., the username and realm parts of the NAI) serve to reassure the parties of the correct binding between the shared key and their identities. The authenticity, freshness and randomness of the EAP Master Secret follow from the authenticity and freshness of AUTH2, and the properties of pseudo-random functions; specifically, the value PRF(K_(MN-SUP,H-AAA), N_3 | AUTH2) is (computationally) independent of any other value output by the function. Thus, the protocol reveals no information to an adversary on the value of the EAP Master Secret K_EMS, as well as the Master Session Keys subsequently derived from it (forward secrecy), assuming that the mechanism used to explode K_EMS into the Master Session Keys preserves forward secrecy. Replay attacks by illegitimate network elements are detected by the MN and the H-AAA by the application of MAC functions to N_1 and N_2, given that both nonces are freshly generated every time by the F-AAA and MN. Denial Of Service (DOS) attacks are alleviated, because if they are mounted by replaying these authentication messages, they would be detected as described above. 4.1 Considerations on misbehaving nodes in foreign access networks A full adversarial model can also be considered, where the trusted AS-PAEs and F-AAAs might misbehave. In particular, since both N_1 and N_2 are sent in clear between the MN-SUP and the AS-PAE, a misbehaving AS-PAE could replay an access-request with the same N_1 and N_2 as a previous request. The objectives of this attack, and their effects on EAP-SKE are two-fold: o A misbehaving node might replay a successful registration to get access to the Master Session Keys that a legitimate user has obtained. In this case, the inclusion of a fresh value for N_3 (Phase 3, Section 3.3) would counteract the replay, by guaranteeing that each generated EAP Master Secret and subsequently Master Session Keys are different even in cases where N_1 and N_2 are replayed. Salgarelli et al. Expires 10/02 [Page 12] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 o A misbehaving node might replay a successful registration to make the H-AAA believe that a legitimate user is initiating a session with the foreign network. In this case EAP-SKE does not offer any direct protection. However, a brief analysis of the possible motivations behind this attack should clarify that such protection is indeed not necessary. In fact, the effects of such attack would be that the Foreign Network could overcharge the Home Network, or could otherwise apply malicious charging schemes where it would permit the use of its infrastructure to unauthorized clients at the expense of the Home Network. In this case, given the trust relationship that exists between the foreign and home networks, misbehaving nodes in the foreign network could always perpetrate such attacks without the needs of breaking the authentication protocol at all. For example, they could simply overstate the amount of traffic that legitimate users generate and receive. Or they could allow access to unauthorized users charging their traffic to the bill of authorized customers. In summary, we feel that this issue must be regulated through the application of business contract agreements, rather than through authentication protocols per se. The prevention of attacks pertaining to a full adversarial model other than the one mentioned above is outside the scope of this document. 5 Alternate network scenarios As mentioned in section 3.1, depending on how operators decide to implement EAP-SKE in their networks, the two logical entities F-AAA and H-AAA MAY be combined. In this case, EAP-SKE would be terminated at the MN-SUP and H-AAA, without the need of an additional RADIUS exchange to convey SKE-specific information to the H-AAA. However this would come at the expense of network efficiency and added latency, since three roundtrips with the H-AAA would be required to complete the SKE exchange. 6 Recommendation for MAC and PRF algorithms EAP-SKE implementations compliant with this document MUST implement HMAC-SHA1 [15] as MAC function and as PRF, as a minimum. HMAC-MD5 MAY be also implemented, in particular where compatibility with existing RADIUS servers that are already Salgarelli et al. Expires 10/02 [Page 13] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 compliant with the requirements of dynamic key distribution for Mobile IP [20] is a concern. In addition, EAP-SKE implementations can optionally implement other MAC and/or PRF algorithms. 7 Message formats In the following, we discuss the detailed packet formats of the EAP SKE and RADIUS messages. 7.1 EAP-SKE message formats EAP SKE messages are of the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | ------- | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All EAP SKE packets must carry the same value X (TBD) in the Type field. The Subtype field identifies specific SKE packets. At present, only Subtype= 1, 2, 3, 4 are defined. The SKE packets with Subtypes other than these MUST BE silently discarded. The detailed message formats are described in the following: 7.1.1 EAP-Request/SKE-AS-Challenge The format of the packet EAP-Request/SKE-AS-Challenge is shown below. Salgarelli et al. Expires 10/02 [Page 14] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS-Chal-Length | Msg-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . AS-Challenge (N_1) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Optional Message . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The semantic of the fields is described below: Code 1 for Request Identifier See [2] Length The length of the EAP-Request packet. Type TBD for EAP-SKE Subtype 1 for SKE-AS-Challenge Reserved This field must be set to zero. AS-Chal-Length >=1 and <=28. Length of AS challenge (N_1) in 4-byte words. The challenge size must be at least 4-bytes. Msg-Length Length of optional message in 4-bytes words (0 or more words). Salgarelli et al. Expires 10/02 [Page 15] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 AS-Challenge Challenge from the F-AAA (N_1). Optional Message Optional message must be null terminated and padded to ensure it length is multiple of 4 bytes. 7.1.2 EAP-Response/SKE-MN-Challenge The format of the packet EAP-Response/SKE-MN-Challenge shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | MAC-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AUTH1-Length | MN-Chal-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . AUTH1 . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . MN-Chal (N_2) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The semantic of the fields is described below: Code 2 for response Identifier See [2] Length The length of the EAP-Response packet. Type TBD for EAP-SKE Subtype 2 for SKE-MN-Challenge Salgarelli et al. Expires 10/02 [Page 16] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 MAC-Type The MAC algorithm used by the MN-SUP to calculate AUTH1. It MUST be one of the codes listed in section 8. Reserved This field MUST be set to 0. AUTH1-Length Length of AUTH1, in 4-byte words. MN-Chal-Length >=1 and <=28. Length of MN Challenge (N_2), in 4-byte words. AUTH1 The value AUTH1, computed by MN-SUP as described in section 3.3. MN-Challenge The MN Challenge (N_2). 7.1.3 EAP-Request/SKE-AS-Verify The format of the packet EAP-Request/SKE-AS-Verify shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | MAC-Type | PRF-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AUTH2-Length | AS-N_3-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . AUTH2 . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . AS-N_3 (N_3) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The semantic of the fields is described below: Code 1 for Request Salgarelli et al. Expires 10/02 [Page 17] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 Identifier See [2] Length The length of the EAP-Request packet. Type TBD for EAP-SKE Subtype 3 for SKE-AS-Verify MAC-Type The MAC algorithm used by the AS to calculate AUTH2. It MUST be one of the codes listed in section 8. PRF-Type The PRF algorithm used by the AS to calculate the EAP Master Secret K_EMS. It MUST be one of the codes listed in section 8. AUTH2-Length Length of AUTH2, in 4-byte words. AS-N_3-Length >=1 and <= 28. Length of AS N_3 nonce, in 4-byte words. AUTH2 The value AUTH2, computed by AS as described in section 3.3. AS-N_3 The AS N_3 nonce. 7.1.4 EAP-Response/SKE-Success The format of the packet EAP-Response/SKE-Success shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Msg-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Optional Message . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Salgarelli et al. Expires 10/02 [Page 18] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 The semantic of the fields is described below: Code 2 for Response Identifier See [2] Length The length of the EAP-Response packet. Type TBD for EAP-SKE. Subtype 4 for SKE-Success. Msg-Length Length of optional message in words (0 or more words). Optional Message The optional message must be null terminated and padded to ensure its length is multiple of 4 bytes. 7.1.5 EAP-Response/SKE-Failure The format of the packet EAP-Response/SKE-Failure shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Msg-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Optional Message . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The semantic of the fields is described below: Code 2 for Response Salgarelli et al. Expires 10/02 [Page 19] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 Identifier See [2] Length The length of the EAP-Response packet. Type TBD for EAP-SKE. Subtype 5 for SKE-Failure. Msg-Length Length of optional message in words (0 or more words). Optional Message The optional message must be null terminated and padded to ensure its length is multiple of 4 bytes. 7.2 RADIUS messages SKE parameters are exchanged between the F-AAA and the H-AAA using a RADIUS Access-Request and a RADIUS Access-Accept (in case of successful authentication at the H-AAA), or a RADIUS Access-Reject (in case of unsuccessful authentication). The RADIUS Access-Request from the F-AAA to the H-AAA MUST contain the following attributes: o User-Name: containing the user's NAI, copied from the EAP-Response/ID message. o One Lucent Vendor Specific SKE Attribute: containing N_1, as generated by the F-AAA, AUTH1 and MAC-Type, as copied from the EAP-Response/SKE-MN-Challenge message. The field PRF-Type MUST be '0' in this attribute. o One Lucent Vendor Specific SKE Attribute: containing N_2, as copied from the EAP-Response/SKE-MN-Challenge message. The fields MAC-Type, PRF-Type and Auth-Length MUST be '0' in this attribute. Salgarelli et al. Expires 10/02 [Page 20] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 The RADIUS Access-Accept from the H-AAA to the F-AAA MUST contain the following attributes: o One Lucent Vendor Specific SKE Attribute: containing N_3 and AUTH2, as generated by the H-AAA. This attribute also contains the MAC-Type that was used by the H-AAA to generate AUTH2, as well as the PRF-Type that was used by the H-AAA to generate K_EMS. o Master-Session-Key: as defined in [5], containing the Master Session Keys generated by the H-AAA. The format of the standard attributes used above may be found in [3] or in the relevant documents referenced above. We now define the format of the Lucent Vendor Specific SKE Attribute. 7.2.1 RADIUS SKE attribute The Lucent Vendor Specific SKE attribute is used to carry SKE information elements between the F-AAA and the H-AAA. A summary of the SKE Attribute format is given below. The fields are transmitted left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | MAC-Type | PRF-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chal-Type | Auth-Type | Chal-Length | Auth-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge | . .... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator | . .... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type TBD for SKE-Request. Vendor-Length > 8. The length of the message in octets. Salgarelli et al. Expires 10/02 [Page 21] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 MAC-Type 0, or one of the MAC-Type codes listed in section 8. PRF-Type 0, or one of the PRF-Type codes listed in section 8. Chal-Type 1 for N_1 2 for N_2 3 for N_3 Auth-Type 0 for NONE 1 for AUTH1 2 for AUTH2 Chal-Length >= 8. Length of the 'Challenge' field, in octets. Auth-Length >= 0. Length of the 'Authenticator' field, in octects. Challenge The challenge of the type identified by the field 'Chal-Type'. Authenticator The authenticator of the type identified by the field 'Auth-Type'. Salgarelli et al. Expires 10/02 [Page 22] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 8 IANA and Protocol Numbering Considerations IANA has assigned the number TBD for EAP SKE authentication. EAP SKE messages include a Subtype field. The following Subtypes are specified: SKE-AS-Challenge 1 SKE-MN-Challenge 2 SKE-AS-Verify 3 SKE-Success 4 SKE-Failure 5 EAP SKE Subtypes 6-255 are reserved and MUST NOT BE used. The following codes are defined for the values of the MAC-Type and PRF-Type fields in EAP-SKE messages and in the Lucent Vendor Specific SKE RADIUS Attribute. Other values for these codes MAY be defined in the future. MAC-Type: This represents the MAC algorithm that is used by the MN-SUP to generate AUTH1, and by the H-AAA to generate AUTH2. Possible values are: HMAC-SHA1 1 HMAC-MD5 2 PRF-Type: This represents the PRF algorithm that is used by the H-AAA to generate K_EMS. Possible values are: HMAC-SHA1 1 HMAC-MD5 2 9 Migration to DIAMETER In this document the protocol used to transfer the authentication information and the key material from AS-PAE to F-AAA to H-AAA and back is RADIUS, given its wide installed base. Migration to DIAMETER [4] should not present any difficulties, since DIAMETER already provisions mechanisms to collect the same authentication information as RADIUS, and to distribute key material to interested parties. The details of such mechanisms, and how they would be applied to EAP-SKE are outside the scope of this document. Salgarelli et al. Expires 10/02 [Page 23] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 10 Open Issues The scheme as it is described in this document would require the MN to re-authenticate to its H-AAA every time a handoff occurs. The protocol does minimize the number of messages that the MN and H-AAA have to exchange, therefore minimizing the latency of the authentication procedure. However, even 1 RTT to the H-AAA to perform re-authentication could represent a too large latency for certain environments. In such cases, one possible solution would be for the F-AAA, MN and H-AAA to generate arrays of (N_1, N_2, N_3) nonces, and arrays of corresponding (AUTH, K). Such arrays could be cached at the F-AAA and at the MN, so that authentications subsequent to the first one could be performed without the involvement of the H-AAA. Another possible solution would be to perform subsequent authentications between the MN and the F-AAA by using a MAC function applied to random numbers and the Master Session Keys, which would get transferred among AS-PAEs by means of a context-transfer protocol such as the one being defined in the SeaMoby IETF working-group [21]. Appendix B - Patent Issues This is to inform you that Lucent Technologies has applied for and/or has patent(s) that relates to the attached submission. This submission is being made pursuant to the provisions of IETF IPR Policy, RFC 2026, Sections 10.3.1 and 10.3.2. Lucent Technologies Inc. will offer patent licenses for submissions made by it which are adopted as a standard by your organization as follows: If part(s) of a submission by Lucent is included in a standard and Lucent has patents and/or pending applications that are essential to implementation of the included part(s) in said standard, Lucent is prepared to grant - on the basis of reciprocity (grant back) - a license on such included part(s) on reasonable, non-discriminatory terms and conditions. Acknowledgments We would like to thank Peretz Feder, Pete McCann, Simon Mizikovsky and Reuven Shapira from Lucent Technologies for useful discussions on this topic and comments on this draft. Salgarelli et al. Expires 10/02 [Page 24] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 References [1] Local and Metropolitan Area Networks: Standard for Port Based Network Access Control. Technical report, IEEE P802.1x, 2001. [2] L. Blunk and J. Volbrecht. PPP Extensible Authentication Protocol (EAP). RFC 2284, IETF, March 1998. [3] C. Rigney, S. Willens, A. Rubens, and W. Simpson. Remote Authentication Dial In User Service (RADIUS). RFC 2865, IETF, June 2000. [4] Pat R. Calhoun, Haseeb Akhtar, Jari Arkko, Erik Guttman, Allan C. Rubens, and Glen Zorn. Diameter Base Protocol. Work in progress - Internet Draft, IETF, July 2001. draft-ietf-aaa-diameter-07.txt. [5] D. Simon. RADIUS Master Session Key Attribute. Work in progress - Internet Draft, IETF, January 2002. draft-simon-radius-key-attr-00.txt. [6] B. Aboba and D. Simon. The EAP Keying Problem. Work in progress - Internet Draft, IETF, February 2002. draft-aboba-pppext-key-problem-01.txt. [7] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF, March 1997. [8] R. Shirey. Internet Security Glossary. RFC 2828, IETF, May 2000. [9] B. Aboba and D. Simon. PPP EAP TLS Authentication Protocol. RFC 2716, IETF, October 1999. [10] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). RFC 2409, IETF, November 1998. [11] G. Tsudik. Message authentication with one-way hash functions. In Proc. INFOCOM'92, 1992. [12] National Institute of Standards and Technology (NIST). Announcing the Secure Hash Standard. FIPS 180-1, U.S. Department of Commerce, April 1995. [13] U. Blumenthal. Secure Session Key Generation. Work in progress - Internet Draft, IETF, January 2001. draft-blumenthal- keygen-01. Salgarelli et al. Expires 10/02 [Page 25] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 [14] M. Bellare, R.Canetti, and H. Krawczyk. Keying hash functions for message authentication. In Advances in Cryptology---CRYPTO '96, volume 1109 of Lecture Notes in Computer Science, pages 1--15. Springer-Verlag, 18--22 August 1996. [15] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. RFC 2104, IETF, February 1997. [16] National Institute of Standards and Technology (NIST). Announcing the Advanced Encryption Standard. FIPS ZZZ, U.S. Department of Commerce, February 2001. [17] O. Goldreich, S. Goldwasser, and Silvio Micali. How to construct random functions. Journal of the ACM, 33(169):210--217, 1986. [18] W. Diffie, P. van Oorshot, and M. Wiener. Authentication and authenticated key exchange. Designs, Codes and Cryptography, 2(169):107--125, 1992. [19] H. Krawczyk. Skeme: A versatile secure key exchange mechanism for the internet. In Proc. 1996 Internet Society Symposium on Network and Distributed System Security, pages 114--127, Feb. 1996. [20] Charles Perkins and Pat Calhoun. AAA Registration Keys for Mobile IP. Work in progress - Internet Draft, IETF, July 2001. draft-ietf-mobileip-aaa-key-08.txt. [21] H. Syed, G. Kenward, P. Calhoun, M. Nakhjiri, R. Koodli, K. Atwal, M. Smith, and G. Krishnamurthi. General Requirements for a Context Transfer Framework. Work in progress - Internet Draft, IETF, May 2001. draft-ietf-seamoby-ct-reqs-00.txt. Salgarelli et al. Expires 10/02 [Page 26] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 Authors' Addresses Luca Salgarelli, Milind M. Buddhikot, Juan Garay, Scott Miller, Uri Blumenthal, Sarvar Patel Bell Laboratories - Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733, USA Voice: +1-732-332-6870 Fax: +1-732-949-7397 E-mail: {salga,mbuddhikot,garay,scm,uri,sarvar}@lucent.com Dorothy Stanley Agere Systems 2000 North Naperville Rd, Room 5B-441 Naperville, IL 60566, USA Voice: +1 630 979 1572 Fax: +1 630 979 1572 E-mail: dstanley@agere.com Peter Dahl, Christopher Carroll Verizon Wireless 2785 Mitchell Drive, MS 9-2, Walnut Creek, CA 94598, USA Voice: +1-925-279-6790 E-mail: {peter.dahl, christopher.carroll}@verizonwireless.com Salgarelli et al. Expires 10/02 [Page 27] INTERNET-DRAFT draft-salgarelli-pppext-eap-ske-01.txt 4/02 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, 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. Salgarelli et al. Expires 10/02 [Page 28]