Internet Draft P. Agashe, F. Quick Document: draft-pagashe-eapcdma2000-00.txt QUALCOMM, Incorporated Expires: June 2003 December 2002 EAP over CDMA2000 (EAPoCDMA2000) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 document specifies the Extensible Authentication Protocol over CDMA2000 (EAPoCDMA2000) to be used for service access authentication. Before a CDMA2000 access terminal is granted access to a service provided by a service provider in a CDMA2000 access network, the service provider may use EAPoCDMA2000 to authenticate the access terminal. EAPoCDMA2000 is a variation of the Extensible Authentication Protocol (PPP EAP) [2]. EAPoCDMA2000 allows authentication over CDMA2000 link layer technology. EAPoCDMA2000 uses UDP as its transport protocol. Conventions used in this document 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 [3]. Table of Contents Agashe Expires - June 2003 [Page 1] EAP over CDMA2000 December 2002 1. Introduction...................................................2 2. Terminology....................................................2 3. UDP as transport protocol......................................4 4. EAPoCDMA2000 messages..........................................4 4.1 EAPoCDMA2000 message formats...............................4 4.2 Types for EAPoCDMA2000 Request/Response messages...........7 5. Further work...................................................8 5.1 Selection of remaining methods.............................8 6. Security Considerations........................................8 References........................................................9 Acknowledgments...................................................9 Author's Addresses................................................9 1. Introduction This document specifies the Extensible Authentication Protocol over CDMA2000 (EAPoCDMA2000) to be used for service access authentication. Before a CDMA2000 access terminal is granted access to a service provided by a service provider in the CDMA2000 access network, the service provider may use EAPoCDMA2000 to authenticate the access terminal. EAPoCDMA2000 provides methods for authentication, which an access terminal and service provider are expected to perform before the access terminal is granted access to a service provided by the service provider. EAPoCDMA2000 is a variation of the Extensible Authentication Protocol (PPP EAP) [2]. EAPoCDMA2000 allows a service provider to authenticate an access terminal over CDMA2000 link layer technology. UDP is chosen as a transport protocol. EAPoCDMA2000 assumes that prior to authentication the access terminal has configured a valid IPv4 or IPv6 address for itself. EAPoCDMA2000 also assumes that prior to authentication the access terminal has discovered the IP-address for the service provider from which the access terminal intends to request the service. EAPoCDMA2000 authentication is analogous to the authentication phase of PPP [2]. After the service provider authenticates the access terminal, the service provider may ensure that the access terminal is authorized to receive the requested service. Messages exchanged as part of providing the service might be encrypted to ensure that only the authorized access terminal receives the service. 2. Terminology This document uses the following terminology: Agashe Expires - June 2003 [Page 2] EAP over CDMA2000 December 2002 Access network The network equipment providing data connectivity between a packet switched data network (typically the Internet) and the access terminals. An access network is also referred to as a base station. Access terminal A device providing data connectivity to a user. An access terminal may be connected to a computing device such as a laptop personal computer or it mat be a self contained data device such as a personal digital assistant. An access terminal is also referred to as a mobile station. This is the entity wishing to obtain service from a service provider within an access network. An access terminal is associated with a network device and a set of credentials to prove its identity. Initiator The Initiator (i.e. like a PPP EAP Authenticator [2]) of an EAPoCDMA2000 authentication method is the entity (i.e. an access terminal or a service provider) that sends the EAPoCDMA2000 Request(s) to a Peer. Peer The Peer of an EAPoCDMA2000 authentication method is the entity (i.e. an access terminal or a service provider) that sends the EAPoCDMA2000 Response(s) back to an Initiator. Service Provider Equipment in the access network that provides a certain service to the access terminal. The service provider may authenticate the credentials provided by an access terminal before granting access to the requested service (i.e. like a PPP EAP Authenticator [2]). Silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. Displayable message This is interpreted to be a human readable string of characters, and MUST NOT affect operation of the protocol. The message encoding MUST follow the UTF-8 transformation format [4]. Agashe Expires - June 2003 [Page 3] EAP over CDMA2000 December 2002 3. UDP as transport protocol This document suggests that EAPoCDMA2000 uses UDP as its transport protocol. EAPoCDMA2000 SHOULD use IANA-assigned port numbers (TBD). 4. EAPoCDMA2000 messages 4.1 EAPoCDMA2000 message formats EAP0CDMA2000 reuses PPP EAP message formats. The EAPoCDMA2000 specification follows that of PPP EAP ([2]) unless otherwise specified in this document. An EAPoCDMA2000 packet will be sent as follows: +-----------+---------------+-----------------+ | IP header | UDP header | EAP message | +-----------+---------------+-----------------+ All EAPoCDMA2000 messages reuse the packet format specified in [2]. The summary of the EAPoCDMA2000 message format is shown below. The fields are transmitted from 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code The Code field is one octet and identifies the type of EAPoCDMA2000 message. EAPoCDMA2000 Codes reuse the following EAP Codes: 1 Request 2 Response 3 Success 4 Failure Identifier Agashe Expires - June 2003 [Page 4] EAP over CDMA2000 December 2002 The Identifier field is one octet and is used û together with source and destination IP-addresses (i.e. IP-addresses of service provider and access terminal) û to match responses with requests. Length The Length field is two octets and indicates the length of the EAPoCDMA2000 message including the Code, Identifier, Length and Data fields. Data The Data field is zero or more octets. The format of the Data field is determined by the Code field. 4.1.1. Request and Response Description The Request message is sent by the authenticator to the peer. Each Request has a type field which serves to indicate what is being requested. The authenticator MUST transmit an EAPoCDMA2000 message with the Code field set to 1 (Request). Additional Request messages MUST be sent until a valid Response message is received, or an optional retry counter expires. Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The contents of the data field is dependent on the Request type. The peer MUST send a Response message in reply to a Request message. Responses MUST only be sent in reply to a received Request and never retransmitted on a timer. The Identifier field of the Response MUST match that of the Request. Implementation Note: Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. Additionally, the peer must be prepared to silently discard received retransmissions while waiting for user input. A summary of the Request and Response message format is shown below. The fields are transmitted from 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Agashe Expires - June 2003 [Page 5] EAP over CDMA2000 December 2002 Code 1 for Request; 2 for Response. Identifier The Identifier field is one octet. The Identifier field MUST be the same if a Request message is retransmitted due to a timeout while waiting for a Response. Any new (non-retransmission) Requests MUST modify the Identifier field. If a peer receives a duplicate Request for which it has already sent a Response, it MUST resend its Response. If a peer receives a duplicate Request before it has sent a Response to the initial Request (i.e. it's waiting for user input), it MUST silently discard the duplicate Request. Length The Length field is two octets and indicates the length of the EAPoCDMA2000 message including the Code, Identifier, Length, Type, and Type-Data fields. Type The Type field is one octet. This field indicates the Type of Request or Response. Only one Type MUST be specified per EAP Request or Response. Normally, the Type field of the Response will be the same as the Type of the Request. However, there is also a Nak Response Type for indicating that a Request type is unacceptable to the peer. When sending a Nak in response to a Request, the peer MAY indicate an alternative desired authentication Type which it supports. An initial specification of Types follows in a later section of this document. Type-Data The Type-Data field varies with the Type of Request and the associated Response. 4.1.2. Success and Failure Description The Success packet is sent by the authenticator to the peer to acknowledge successful authentication. The authenticator MUST Agashe Expires - June 2003 [Page 6] EAP over CDMA2000 December 2002 transmit an EAPoCDMA2000 message with the Code field set to 3 (Success). If the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests) then the implementation MUST transmit an EAPoCDMA2000 message with the Code field set to 4 (Failure). An authenticator MAY wish to issue multiple Requests before sending a Failure response in order to allow for human typing mistakes. Implementation Note: Because the Success and Failure packets are not acknowledged, they may be potentially lost. A peer MUST allow for this circumstance. A summary of the Success and Failure packet format is shown below. The fields are transmitted from 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 3 for Success; 4 for Failure. Identifier The Identifier field is one octet and aids in matching replies to Responses. The Identifier field MUST match the Identifier field of the Response message that it is sent in response to. Length 4 4.2 Types for EAPoCDMA2000 Request/Response messages This section defines the initial set of EAP Types used in EAPoCDMA2000 Request/Response exchanges. The Type field is one octet and identifies the structure of an EAP Request or Response message. EAPoCDMA2000 reuses some selected PPP EAP methods. However, PPP EAP methods cannot blindly be ported into EAPoCDMA2000 without taking security threats into account. On multi-access links, PPP EAP methods that are vulnerable to attacks (including eavesdropping, address Agashe Expires - June 2003 [Page 7] EAP over CDMA2000 December 2002 spoofing, replay attacks and man-in-the-middle attacks), MUST NOT be used with EAPoCDMA2000. EAPoCDMA2000 will explicitly specify which PPP EAP methods may be used, and assign a type value to the selected method. Other PPP EAP methods MUST NOT be used with EAPoCDMA2000. The first 3 Types are considered special case Types. The remaining Types define authentication exchanges. The Nak Type is valid only for Response packets, it MUST NOT be sent in a Request. The Nak Type MUST only be sent in response to a Request which uses an authentication Type code. The following EAPoCDMA2000 Types are supported in EAPoCDMA2000. All EAPoCDMA2000 implementations MUST support Types 1-4. These Types are defined in [2]. More types may be defined in follow-on documents. Type 1 Identity 2 Notification 3 NAK 4 MD-5 Challenge Other Types MUST NOT be used. 5. Further work 5.1 Selection of remaining methods In the future, EAP AKA [5] may be considered as an authentication mechanism besides MD-5 Challenge. 6. Security Considerations EAPoCDMA2000 reuses existing EAP methods, but the multi-access environment it will operate in raises additional security threats. Security threats such as eavesdropping, address spoofing, replay attacks and man-in-the-middle attacks must be considered before adding other PPP EAP methods to EAPoCDMA2000. EAPoCDMA2000 provides a method for authentication before providing a requested service to an access terminal. After the service provider authenticates the access terminal, the service provider may ensure that the access terminal is authorized to receive the requested service. Messages exchanged as part of providing the service might be encrypted to ensure that only the authorized access terminal receives the service. IANA Considerations Agashe Expires - June 2003 [Page 8] EAP over CDMA2000 December 2002 IANA needs to assign a UDP port number for EAPoCDMA2000. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Protocol", RFC 2284, March 1998. 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 4 Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. 5 Arkko, J., Haverinen, H., "EAP AKA Authentication", , November 2001, Work in Progress. Acknowledgments This internet draft derives much of its inspiration from P. EngelstadÆs EAP over UDP internet draft as well as the PPP EAP protocol [2]. Author's Addresses Parag Agashe QUALCOMM, Incorporated 5775 Morehouse Drive San Diego, CA 92121 Phone: 858-658-5076 Email: pagashe@qualcomm.com Frank Quick QUALCOMM, Incorporated 5775 Morehouse Drive San Diego, CA 92121 Phone: 858-658-3608 Email: fquick@qualcomm.com Agashe Expires - June 2003 [Page 9]