Internet Draft Paal Engelstad Telenor R&D, California Expires August 2002 February 2002 EAP over UDP (EAPoUDP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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. This document is an individual submission for the PANA Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mailing list pana@research.telcordia.com. Abstract This document specifies the Extensible Authentication Protocol over UDP (EAPoUDP) to be used for network access authentication. An access domain is represented by one or many PANA Authentication Agents (PAAs). Before a PANA Client (PaC) is granted access to the domain, a PAA and a PaC MAY use EAPoUDP to authenticate each other. EAPoUDP is a variation of the Extensible Authentication Protocol (PPP EAP) [2], but runs instead over IP - either IPv4 or IPv6. Unlike PPP EAP, EAPoUDP allows authentication over any link layer technology. Furthermore, the PAA and the PaC need not be on the same link. EAPoUDP uses UDP as its transport protocol. P. Engelstad Expires August 2002 [Page 1] EAP over UDP February 2002 Table of Contents 1 Introduction.....................................................2 2 Terminology......................................................3 3 UDP as transport protocol........................................4 4 EAPoUDP reuses PPP EAP message formats...........................4 4.1 EAPoUDP message format.......................................4 4.2 Types for Request/Response messages..........................6 4.3 MD-5 Challenge for Re-Authentication.........................6 5 EAPoUDP authentication schemes...................................9 5.1 Starting the authentication session..........................9 5.2 Initial Authentication......................................11 5.3 Re-authentication...........................................12 5.4 Disconnect..................................................13 5.5 Back-end communication......................................13 6 Further work....................................................14 6.1 Selection of remaining methods..............................14 6.2 Retransmission and timeout mechanisms.......................14 7 Security Considerations.........................................14 IANA Considerations...............................................14 Acknowledgements..................................................14 References........................................................14 Author's Address..................................................15 1 Introduction This document specifies the Extensible Authentication Protocol over UDP (EAPoUDP) to be used for network access authentication. An access domain is represented by one or many PANA Authentication Agents (PAAs). Before a PANA Client (PaC) is granted access to the domain, a PAA and a PaC MAY use EAPoUDP to authenticate each other. EAPoUDP calls for methods for Initial Authentication (I-A), Re- Authentication (R-A) and Disconnect Notification (D-N). I-A is for mutual authentication, which a PaC and a PAA are expected to perform before the PaC is granted access to an access domain. A product of the I-A method is a session key established between PaC and PAA. This session key can be used for R-A, when a PAA or a PaC wants to re-authenticate the other party and validate that it is still present and alive. After successful authentication, either the PAA or the PaC MAY want to terminate the authentication relationship by sending a (D-N) to the other party. EAPoUDP is a variation of the Extensible Authentication Protocol (PPP EAP) [2]. Unlike PPP EAP, EAPoUDP runs over IP - either IPv4 or IPv6. Thus, it allows PaCs and PAAs to authenticate each other over any link layer technology, and they do not need to be on the same link. For a lightweight solution, UDP is chosen as transport protocol. P. Engelstad Expires August 2002 [Page 2] EAP over UDP February 2002 EAPoUDP assumes that prior to authentication the PaC has configured a valid IPv4 or IPv6 address for itself. It MAY also have discovered an IP-address for at least one PAA in the access domain. PAA Discovery mechanisms are proposed and detailed in [1]. Where to locate PAAs (e.g. with a PAA located on each access router or with a pool of PAAs located anywhere in the access domain) represents an architectural tradeoff. The PANA WG may leave to implementers and operators to decide which architecture best fits their needs. Alternatively, the PANA WG may mandate that PAAs are located on access routers. The scheme presented in this document should accommodate all alternative PAA configurations. 2 Terminology This document uses the following terminology same as in [10]: Device Identifier (DI) This is the identifier used by the network as a handle to control and police the network access of a client. Depending on the access technology, identifier might contain any of IP address, link-layer address, switch port number, etc. of a device. PANA authentication agent keeps a table for binding device identifiers to the PANA clients. PANA Client (PaC) This is the entity wishing to obtain network access from a PANA authentication agent within a network. A PANA client is associated with a network device and a set of credentials to prove its identity within the scope of PANA. PANA Authentication Agent (PAA) This is the entity whose responsibility is to authenticate the credentials provided by a PANA client and grant network access service to the device associated with the client and identified by a DI. In addition, the following terms are introduced: Initiator The Initiator (i.e. like a PPP EAP Authenticator [2], [3]) of an EAPoUDP authentication method is the entity (i.e. a PaC or a PAA) that sends the EAPoUDP Request(s) to a Peer. Peer P. Engelstad Expires August 2002 [Page 3] EAP over UDP February 2002 The Peer of an EAP-based authentication method is the entity (i.e. a PaC or a PAA) that sends the EAPoUDP Response(s) back to an Initiator. Initial Authentication (I-A) Initial Authentication is the method for mutual authentication, that a PaC and a PAA are expected to perform before the PaC is granted access to an access domain. A product of I-A is a session key is established between PaC and PAA, which is used for Re- Authentication (below). Re-Authentication (R-A) After Initial Authentication (I-A), a PAA or a PaC MAY want to re-authenticate the other party and validate that it is still present and alive. A common method for R-A is that the Initiator sends a challenge to the Peer. The Peer computes a hash over the challenge, keyed by a session key, and returns the result to the Initiator. The Peer and Initiator use the session key established during the Initial Authentication to key the hash. This document specifies a method for re-authentication (R-A). Disconnect Notification (D-N) After successful authentication, either the PAA or the PaC MAY want to explicitly terminate the authentication relationship by sending a Disconnect-Notification (D-N) to the other party. D-Ns alone cannot guarantee disconnect. Due to Denial-of-Service (DoS) threats, D-N cannot be guaranteed to reach the other party. Disconnect can only be guaranteed by mandatory timeout mechanisms implemented in I-A and R-A. Thus, D-N is a function to optimize EAPoUDP. D-Ns MUST be integrity protected to avoid being a tool for DoS attacks. 3 UDP as transport protocol This document suggests that EAPoUDP uses UDP as its transport protocol. For a lightweight solution, UDP and ICMP are both attractive alternatives. UDP is chosen here to allow for application layer implementations. EAPoUDP SHOULD use IANA-assigned port numbers (TBD). 4 EAPoUDP reuses PPP EAP message formats 4.1 EAPoUDP message format P. Engelstad Expires August 2002 [Page 4] EAP over UDP February 2002 The EAPoUDP specification follows that of PPP EAP ([2], [3]) unless otherwise specified in this document. The EAPoUDP packet reuses the PPP EAP format ([2], [3]). An EAPoUDP packet will be sent as follows: +-----------+------------+-------------+ | IP header | UDP header | EAP message | +-----------+------------+-------------+ All messages begins with a 32-bit header following the UDP header: 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 EAPoUDP message. EAPoUDP Codes reuse the following EAP Codes: 1 Request 2 Response 3 Success 4 Failure Identifier The Identifier field is one octet and is used - together with source and destination IP-addresses (i.e. IP-addresses of Initiator and Peer) - to match responses with requests. Length The Length field is two octets and indicates the length (in octets) of the EAPoIP message including the Code, Identifier, Length and Data fields. Data The Data field is zero or more octets. The Code field determines the format of the Data field. The Data field of Request and Response messages consists of an additional Type field of 1 octet followed by Type-Data: 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 P. Engelstad Expires August 2002 [Page 5] EAP over UDP February 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type (Request/Response messages) This Type field of Request/Response messages indicates which authentication method is carried in Type-Data. Type-Data The Type-Data field is zero or more octets and carries information associated with the authentication method. The Type field determines the format of the Type-Data field. 4.2 Types for Request/Response messages EAPoUDP reuses some selected PPP EAP methods. However, PPP EAP methods cannot blindly be ported into EAPoUDP without taking security threats into account. On multi-access links, PPP EAP methods that are vulnerable to attacks (including eavesdropping, address spoofing, replay attacks and man-in-the-middle attacks), MUST NOT be used with EAPoUDP. EAPoUDP will explicitly specify which PPP EAP methods to be used, and assign a type value to the selected method. Other PPP EAP methods MUST NOT be used with EAPoUDP. The following EAPoUDP Types are supported in EAPoUDP: Type 1 Identity 2 Notification 3 NAK 4 MD-5 Challenge for Re-Authentication TBD Selected method for Initial Authentication TBD Selected method for Disconnect-Notification Other Types MUST NOT be used. To ensure correct and secure operation in a multi-access environment, EAPoUDP imposes additional requirements on the operation of selected PPP EAP methods. Next sub-section summarizes the additional requirements imposed on the MD-5 Challenge method selected for EAPoUDP re-authentication. 4.3 MD-5 Challenge for Re-Authentication P. Engelstad Expires August 2002 [Page 6] EAP over UDP February 2002 4.3.1 MD-5 Challenge/Response format This document proposes to reuse the PPP EAP MD-5 Challenge/Response authentication method for EAPoUDP re-authentication ([2], [3]). However, we have modified the Type-Data format of challenges and responses to incorporate an optional Device Identifier. The content of the Type-Data field is summarized 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value-Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Name-Length | Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | DI-Length | Device Identifier of Peer ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Value-Length This is the length, in octets, of the Value field, which MUST be at least one octet. Value The Value field contains a challenge in Request messages, and a calculated MD-5 hash (Section 4.3.2) in Response messages. Name-Length This is the length, in octets, of the Name field, which SHOULD be at least one octet. Name The Name field contains the Network Access Identifier (NAI) of the sender of the message. A request message, for example, would contain a NAI of the Initiator, and a response message would contain a NAI of the Peer. This field MAY contain a temporary NAI, which MAY have been derived during Initial Authentication. DI-Length This is the length, in octets, of the Device Identifier field. If a Device Identifier is not present in the message, the value is set to zero. Device Identifier This field contains a Device Identifier of the Peer. The Initiator MAY include a Device Identifier in a challenge request to confirm that the IP (or MAC) source addresses of packets P. Engelstad Expires August 2002 [Page 7] EAP over UDP February 2002 received from the Peer is correct. The Initiator incorporates the address(es) into the Device Identifier, generates a random challenge, and sends the challenge request message to the Peer. The Peer MUST copy the Device Identifier field from the Challenge message into the same field of the response message. (Later versions of this document MAY open for more extensive negotiations of Device Identifier values.) The Peer MUST validate that the information in the Device Identifier is correct. The Peer MUST NOT return a valid Response message if the information is not correct. The format of the Device Identifier will be specified in a follow-on document. 4.3.2 MD-5 Hash Calculation To ensure correct and secure operation in a multi-access environment, EAPoUDP imposes requirements on how the MD-5 hash is calculated: The MD-5 hash MUST be calculated over a stream of octets in sequence consisting of the Network Access Identifier (NAI) of Peer, followed by (concatenated with) Device Identifier of Peer (if present), followed by (concatenated with) the Identifier octet, followed by (concatenated with) the session key for re- authentication, and followed by (concatenated with) the Challenge Value. The Device Identifier is copied from the Device Identifier field in the MD-5 Response message. Since the MD-5 hash is calculated over the NAI of the Peer, it will protect against reflection attacks, even when Initiator and Peer use the same session key for re-authentication in both directions. In comparison, the original PPP EAP MD-5 hash is only calculated over the Identifier, session key, and Challenge, and requires different session keys in each direction. An Initiator can protect against address spoofing attacks of a Peer's IP-address (or MAC-address) by sending a challenge to the Peer with the Peer's addresses incorporated into the Device Identifier field. The Peer confirms the validity of the addresses by returning the hash calculated over both challenge and device identifier. 4.3.3 Validation of Device Identifier of a Peer The Initial Authentication method sets up a cache consisting of the other party's identifier, session keys and IP-address (and/or MAC address). Upon receiving an EAPoUDP packet, a PAA or PaC checks the source address, and consults the cache to find the sender's identity and session keys. P. Engelstad Expires August 2002 [Page 8] EAP over UDP February 2002 However, the selected Initial Authentication method may not be capable of ensuring that the addresses in the cache are correct, and have not been subject to a IP-spoofing attack by a malicious Man-In- The-Middle (MITM). In that case, the Initial Authentication MAY be followed by Re-authentication where the IP- (and/or MAC-) address(es) are incorporated in the Device Identifier. Thus, the re- authentication method can be used as a means to verify the correctness of addresses in the cache. After one successful re- authentication, PAA can safely grant PaC access to the domain. 5 EAPoUDP authentication schemes 5.1 Starting the authentication session The specification of EAPoUDP should determine the ways in which Initial Authentication (I-A) can be started. There are a number of possibilities, and the following three sub-sections describe some alternatives. Without loss of generality, we assume in the following discussion that the EAPoUDP I-A method is carried out with PAA as the Initiator. 5.1.1 Alternative 1: I-A triggered by the access network The following diagram shows a model, but not details, describing the message exchange where the access network triggers PAA to start Initial Authentication: PaC AP/AR/DHCP/DAD/etc. PAA | | | | | | | | 1a) A trigger | | |----------------->| | | (PaC IP-address) | | | | | | 1b) Identity Request | |<------------------------------------| | 1c) Idenity Response (PaC-ID) | |------------------------------------>| | | | | | 2a) Initial-Auth.: First Request | |<------------------------------------| In this alternative, PAA should be co-located with the entity that sends the trigger, e.g. with the Access Router or DHCP server. The messages are described as follows: P. Engelstad Expires August 2002 [Page 9] EAP over UDP February 2002 PaC Discovery: 1a) Trigger Initially, PAA receives a trigger indicating the arrival of a new and un-authenticated PaC. The trigger may come from DHCP (e.g. the DHCP server sends a signal to PAA after having assigned an IP-address to a new PaC), or from another protocol entity. The trigger SHOULD provide PAA with the IP-address of the PaC. 1b) Identity Request PAA sends an EAPoUDP Identity Request to the given IP-address of the PaC to find out the identity of the PaC. 1c) Identity Response PaC returns its identity in an EAPoUDP Identity Response. Initial Authentication: 2a) After having obtained PaC's identity, the PAA starts Initial Authentication (Section 5.2). 5.1.2 Alternative 2: I-A triggered by unsolicited Identity Response The following diagram shows a model describing the message exchange where the I-A is triggered by a PaC. After having discovered a PAA, the PaC sends it an unsolicited Identity Request, which triggers the PAA to start Initial Authentication: PaC AR/DHCP server PAA | | | | | | |1a) PAA Discovery | | |<---------------->| | | | | | | | | |1b) (Unsolicited) Identity Response | |------------------------------------>| | | | | | 2a) Initial-Auth.: First Request | |<------------------------------------| The messages are described as follows: 1a) PAA discovery [1]: P. Engelstad Expires August 2002 [Page 10] EAP over UDP February 2002 A PaC discovers the IP-address and identity of a PAA (e.g. in a DHCP option). PAA Discovery mechanisms are proposed and detailed in [1]. 1b) (Unsolicited) Identity Response: If the client can positively determine that it has to authenticate, e.g. through successful PAA discovery, it MAY send an unsolicited Identity Response to the PAA, containing the PaC's Identifier. The PaC is free to pick the Identifier octet value. The client MUST NOT send an unsolicited Identity Response if it has already received an Identity Request. (The same method has been proposed in [7].) Initial Authentication: 2a) The unsolicited Identity Request triggers the PAA to start Initial Authentication (Section 5.2). 5.1.3 Alternative 3: I-A triggered by anycasted PAA discovery The following diagram shows the message exchange where a PaC uses anycast to discover PAA. This triggers PAA to start Initial Authentication: PaC PAA | | | | | | | 1a) (Anycasted) Identity Request | |------------------------------------>| | 1b) (Unicasted) Identity Response | |<------------------------------------| | | | 1c) Identity Request | |<------------------------------------| | 1d) Identity Response (PaC-ID) | |------------------------------------>| | | | | | 2a) Initial-Auth.: First Request | |<------------------------------------| The anycasted Identity Request triggers PAA to discover PaC's Identity (message 1c and 1d), before starting Initial Authentication (Section 5.2). 5.2 Initial Authentication PAA is assumed to be the Initiator of Initial Authentication. P. Engelstad Expires August 2002 [Page 11] EAP over UDP February 2002 PaC PAA | | | 2a) Initial-Auth.: First Request | |<------------------------------------| | | | Possible additional Requests and | +--------+ | Responses: | |Local | |------------------------------------>|lookup credent.| storage| |<------------------------------------|-------------->| or | |------------------------------------>|return credent.|AAA- | |<------------------------------------|<--------------| infra- | | | | struct.| | | +--------+ | 2n) Initial-Auth.: Last Response | |------------------------------------>| | | The messages are described as follows: 2a) The PAA initiates the Initial Authentication (I-A) by sending an I-A-Request to the PaC. The I-A method eventually selected by PANA WG may call for additional Request/Response exchanges. 2n) PaC returns the last I-A-Response. For Initial Authentication, PAA MAY use a local storage, a back-end AAA infrastructure, a Certificate Authority or some other kind of Trusted Third Party (TTP) to verify credentials of a PaC, and to obtain credentials that can be verified by the PaC. The actual process for obtaining and verifying credentials is out of scope for the EAPoUDP specification. EAPoUDP Success and Failure messages, which parallel those of PPP EAP ([2], [3]), have been omitted here for simplicity. 5.3 Re-authentication A PAA or PaC MAY re-authenticate the other party at any time after Initial Authentication. Initiator Peer (PAA/PaC) (PaC/PAA) | | | 3a) Re-authentication Challenge | |------------------------------------>| | | | 3b) Re-authentication Response | |<------------------------------------| | | P. Engelstad Expires August 2002 [Page 12] EAP over UDP February 2002 PAA MAY act as an Initiator when re-authenticating PaC as a Peer, or PaC MAY act as an Initiator when re-authenticating the PAA as a Peer. 5.4 Disconnect A PAA or PaC MAY terminate the authentication relationship by sending a Disconnect Notification to the other party any time after Initial Authentication. Initiator Peer (PAA/PaC) (PaC/PAA) | | | 5) Disconnect Notification | |------------------------------------>| | | One way of ensuring the integrity of a Disconnect Notification is to require the Initial Authentication method generate a separate Disconnect One-time Password (D-OTP) to integrity-protect the Disconnect Notification message. 5.5 Back-end communication There are a number of different ways that a PAA may interact with the back-end for authentication to verify credentials of PaCs and to obtain credentials that can be used by PaC to authenticate PAA. The examples above provide one possible scenario: PaC PAA | | +--------+ | EAPoUDP msg. | |Local | |------------->|lookup credentials & verifiers | storage| | |------------------------------>| or | | |return credentials & verifiers |AAA- | | |<------------------------------| infra- | | EAPoUDP msg. | | struct.| |<-------------| +--------+ | | Another scenario may call for the use of PAA as a pass-through as follows: PaC PAA | | | EAPoUDP msg. | +--------+ |------------->| Forwarded EAPoUDP message | | | |---------------------------->| Auth.- | | | Returned EAPoUDP message | | | |<----------------------------| server | | EAPoUDP msg. | (+ master session keys) | | P. Engelstad Expires August 2002 [Page 13] EAP over UDP February 2002 |<-------------| +--------+ | | There might be other possible scenarios. This issue is implementation dependent and is out of scope for EAPoUDP. 6 Further work 6.1 Selection of remaining methods PANA WG MUST select the specific methods used for Initial Authentication and Disconnect Notification. Both EAP AKA [7] and EAP SRP-SHA1 [8] are methods that may be considered for Initial Authentication. Algorithms to derive session keys from Initial Authentication should also be specified. EAP-independent key-derivation algorithms are under development [9]. 6.2 Retransmission and timeout mechanisms The EAPoUDP protocol may require specific retransmission and timeout mechanisms being used as default for all messages. Specific (i.e. non-default) time-out and re-transmission mechanisms MAY be specified for selected EAPoUDP message types where user input (e.g. a password) is expected. 7 Security Considerations EAPoUDP reuses existing EAP methods, but the multi-access, multi-hop environment it MAY operate in raises additional security threats. The final EAPoUDP specification MUST therefore further ensure that each EAPoUDP method can be used securely in this environment [10]. IANA Considerations IANA need to assign a UDP port number for EAPoUDP. Acknowledgements ... References P. Engelstad Expires August 2002 [Page 14] EAP over UDP February 2002 [1] Engelstad, P., "Discovery Mechanism for PANA Authentication Agents (PAA-discovery)", , January 2002, Work in Progress. [2] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Protocol", RFC 2284, March 1998. [3] Blunk, L., Vollbrecht, J., and Aboba, B., "Extensible Authentication Protocol (EAP)", (RFC2284bis), November 2001, Work in Progress. [4] Aboba, B., Beadles, M. "The Network Access Identifier", RFC 2486, January 1999. [5] Narten, T., and Draves, R., "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [6] Tsirtis, G., "EAP over ICMP", , January 2002, Work in Progress. [7] Arkko, J., Haverinen, H., "EAP AKA Authentication", , November 2001, Work in Progress. [8] Carlson, J., Aboba, B., Haverinen, H.,"EAP SRP-SHA1 Authentication Protocol", , July 2001, Work in Progress. [9] Aboba, B., Simon, D. "The EAP Keying Problem", , February 2002, Work in Progress. [10] Yegin (ed.) et al., "Protocol for Carrying Authentication for Network Access (PANA) Requirements and Terminology", , February 2002, Work in Progress. Author's Address Paal E. Engelstad Telenor R&D (California) 399 Sherman Ave. Suite #12 Palo Alto, CA 94306, USA Tel.: + 1-650- 714 7537 e-mail: paal@telenorisv.com P. Engelstad Expires August 2002 [Page 15]