Internet Draft P. Engelstad Telenor R&D Expires July 2002 January 2002 Extensible Authentication Protocol over IP (EAPoIP) 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 IP (EAPoIP) to be used as a carrier for network access authentication. An access domain is represented by one or many PANA Authentication Agents (PAAs). Before a host is granted access to the domain, a PAA can use EAPoIP to authenticate the host. The host can also use EAPoIP to authenticate the PAA. EAPoIP is essentially a variation of the Extensible Authentication Protocol (PPP EAP) [2] and runs over IP - either IPv4 or IPv6. Unlike PPP EAP, EAPoIP allows hosts and PAAs to authenticate over any link layer technology, and they do not need to be on the same link. Since EAPoIP is basically a client/server protocol, and since the PANA WG is opting for a lightweight solution, UDP is proposed as the transport protocol for EAPoIP. P. Engelstad Expires July 2002 [Page 1] EAP over IP February 2002 Table of Contents 1 Introduction.....................................................2 2 Terminology......................................................3 3 UDP as a transport protocol for EAPoIP...........................3 4 EAPoIP re-uses PPP EAP message formats...........................3 5 A simplified model of a "host-initiated" EAPoIP scheme...........4 6 A simplified model of a "network-initiated" EAPoIP scheme........6 7 Identity hiding..................................................6 8 Additional Security Requirements.................................7 9 Retransmission and timeout mechanisms............................7 10 Security Considerations.........................................7 IANA Considerations................................................7 Acknowledgements...................................................7 References.........................................................7 Authors' Addresses.................................................8 1 Introduction This document specifies the Extensible Authentication Protocol over IP (EAPoIP) to be used as a carrier for network access authentication. An access domain is represented by one or many PANA Authentication Agents (PAAs). Before a host is granted access to the domain, a PAA MAY use EAPoIP to authenticate the host. The host MAY also use EAPoIP to authenticate the PAA. EAPoIP MAY initially be used to establish a local security association (e.g. in terms of a session key) between a host and a PAA. A PAA MAY subsequently use EAPoIP to (re-) authenticate a host, and a host MAY also use EAPoIP to (re-) authenticate a PAA. EAPoIP is essentially a variation of the Extensible Authentication Protocol (PPP EAP) [2]. Unlike PPP EAP, EAPoIP runs over IP - either IPv4 or IPv6. Thus, it allows hosts and PAAs to authenticate over any link layer technology, and they do not need to be on the same link. EAPoIP need to use a transport protocol. Since EAPoIP is basically a client/server protocol, and since the PANA WG is opting for a lightweight solution, UDP is proposed. EAPoIP, as outlined in this document, MAY readily be modified to use TCP or SCTP as transport protocols. ICMP, on the other hand, seems inappropriate, since PAA is not concerned with routing. EAPoIP assumes that the host has configured a valid IPv4 or IPv6 address for itself. It MAY also have discovered IP-addresses of PAAs in the access domain. A PAA Discovery mechanism is proposed in [1]. P. Engelstad Expires July 2002 [Page 2] EAP over IP February 2002 Where to locate PAAs (e.g. with a PAA located on each access router or with a pool of PAAs located further "back" in the access domain) represents an architectural tradeoff. The PANA WG may leave up to the implementers and operators which architecture would best fit their needs. Alternatively, the PANA WG may mandate that PAAs are located on access routers. The scheme presented in this document does not mandate any particular architecture; it should accommodate all possible PAA configurations. 2 Terminology This document uses the following terms: Authenticator: A node requiring the authentication, like a PPP EAP authenticator ([2], [3]). Peer: A node that is being authenticated by an authenticator, like a PPP EAP peer ([2], [3]). PANA Authentication Agent (PAA): The authentication server function. It acts as an EAP Authenticator that authenticates a host, or as an EAP Peer that is authenticated by a host. 3 UDP as a transport protocol for EAPoIP This document suggests that EAPoIP uses UDP as a transport protocol. Considering PANA WG's preference for a lightweight solution UDP and ICMP are both attractive alternatives. Since EAPoIP is basically a stateful client/server protocol, UDP is thus proposed. (The intention of ICMP in the original IP architecture was to allow routers to send error and control messages to other routers and hosts. Since the PAA function is not concerned with routing of any sort, ICMP is ruled out as an alternative.) The EAPoIP protocol, as described in this document, can readily be modified to use more heavyweight transport protocols, such as TCP or SCTP. EAPoIP SHOULD use IANA-assigned port numbers (TBD). 4 EAPoIP re-uses PPP EAP message formats EAPoIP messages re-uses PPP EAP packet formats ([2], [3]). Thus, EAPoIP MUST support the four message types "Request", "Response", "Success" and "Failure" with the corresponding code values 1, 2, 3, and 4, respectively. P. Engelstad Expires July 2002 [Page 3] EAP over IP February 2002 Furthermore, EAPoIP MUST also support the initial EAPoIP Request/Response Types that MUST be supported by PPP EAP. These include the Request/Response Types "Identity", "Notification", "NAK" and "MD5-Challenge" - with the corresponding code values 1, 2, 3, and 4, respectively. 5 A simplified model of a "host-initiated" EAPoIP scheme The following diagram shows a simplified model of the message exchanges of an EAPoIP scheme where the host takes the initiative: Roaming host Access Router/DHCP server PAA | | | | | | | 1) PAA Discovery | | |<----------------------- | | | | | ....|.................................................|....... | | | 2a) Session Key Request | |------------------------------------------------>| | | | | AAA | |<----->TTP | | | 2b) Session Key Response | |<------------------------------------------------| | | ....|.................................................|....... | | | 3a) (Re-)authentication Challenge | |<------------------------------------------------| | | | 3b) (Re-)authentication Response | |------------------------------------------------>| | | ....|.................................................|....... | | | 4a) (Re-)authentication Challenge | |------------------------------------------------>| | | | 4b) (Re-)authentication Response | |<------------------------------------------------| | | ....|.................................................|....... The PAA may be co-located with the Access Router or DHCP server. The messages are described as follows: 1) PAA discovery: P. Engelstad Expires July 2002 [Page 4] EAP over IP February 2002 A roaming host discovers the IP-address (and identity) of a PAA in an extension to a Router Advertisement or by means of DHCP. A PAA Discovery mechanism is proposed in [1]. It allows the host to discover the IP-address and identity of the PAA, as well as the session key establishment method to be used in the subsequent message exchange. This scheme assumes that it is the host that sends the first message after having discovered a PAA. 2) Session Key Distribution: Assuming, for simplicity, that a session key establishment algorithm uses only 2 local passes between host and PAA: 2a) The host initiates the Session Key Establishment phase (as an EAP Authenticator) by sending an EAP Session Key Request to the PAA. 2b) PAA acts as an EAP peer and sends an EAP Session Key Response. PAA MAY use a back-end AAA infrastructure, a Certificate Authority or another kind of Trusted Third Party (TTP) to intercept and validate the Session Key Request and/or to formulate the Session Key Response. The Session Key Establishment phase may naturally use more message passes. If the host did not discover PAA's identity during the PAA Discovery phase, it may initially send an Identity Request. (This Request may alternatively trigger the PAA to initiate the Session Key Establishment process going in the opposite direction, i.e. with PAA acting as the EAP Authenticator.) A PAA or host MAY re-authenticate the other party at any time, using message exchange 3 or 4 (respectively) in the figure above. It should be noted that some session key establishment algorithms do not incorporate proof of freshness/liveliness of one or both parties. If this is the case, the session key establishment algorithm SHOULD be followed up by (re-) authentication. 3) PAA (re-) authenticates host 3a) PAA acts as an EAP authenticator and sends a challenge to the host. 3b) The host responds to the challenge (e.g. by computing a MD-5 hash over the challenge), using the session key that was established during the Session Key message exchange (above). 4) Host (re-) authenticates PAA P. Engelstad Expires July 2002 [Page 5] EAP over IP February 2002 As in 3 above, but the roles of host and PAA are reversed. EAPoIP Success and Failure messages have been omitted for simplicity. 6 A simplified model of a "network-initiated" EAPoIP scheme The following diagram shows a simplified model of the message exchanges of an EAPoIP scheme where the network takes the initiative: Roaming host Access Router/DHCP server PAA | | | | | | | | 1)Some trigger | | |---------------------->| | | | ....|.................................................|....... | | | 2a) Identity Request | |<------------------------------------------------| | 2b) Identity Response | |------------------------------------------------>| | | | 2c) Session Key Establishment | AAA |<----------------------------------------------->|<----->TTP | | ....|.................................................|....... The PAA may be co-located with the Access Router or DHCP server. This scheme assumes that the PAA receives some triggers indicating arrival of a new host. PAA MAY for example be triggered by stateful address configuration, e.g. the DHCP server signals to PAA that there is a new host at the IP-address it has just handed out. PAA will first reveal the identity of a host, by sending an EAPoIP Identity Request, before continuing with the Session Key Establishment. 7 Identity hiding Some Session Key Establishment algorithms MAY help conceal the host's identity. Identity hiding MAY alternatively be addressed by other protocols, e.g. a host MAY use temporary user names and/or temporary IP-addresses. The use of temporary IPv6 addresses is specified in [5]. P. Engelstad Expires July 2002 [Page 6] EAP over IP February 2002 8 Additional Security Requirements Since PPP EAP makes assumptions about the characteristics of the underlying point-to-point link, a PPP EAP method cannot blindly be substituted with its EAPoIP counterpart without taking security threats into account. EAP methods that are vulnerable to attacks likely on multi-access links (including eavesdropping, address spoofing, replay attacks and man-in-the-middle attacks) MUST NOT be used with EAPoIP. EAPoIP may instead pose additional requirements to existing EAP methods. Furthermore, EAPoIP-specific methods that are designed for multi- access environments MAY also be developed. These issues should be addressed in follow-on documents. 9 Retransmission and timeout mechanisms The EAPoIP protocol may require specific retransmission and timeout mechanisms based the possibility of multi-access wireless subnets. These mechanisms also depend on whether a user is expected to type in a password with long latency and possibility of typos, or whether a software or hardware module is expected to handle this part on behalf of the user (i.e. user authentication versus device authentication). 10 Security Considerations An important issue is how to secure the EAPoIP protocol. Authenticators and peers MAY validate their lower-layer identifiers, such as IP- and MAC- addresses, in addition to their NAIs, during either the initial session key establishment or during subsequent (re-) authentication. EAPoIP will then be better secured against address spoofing and man- in-the-middle attacks. It also facilitates use of address filtering as one (of possibly many) means to enforce network access control. IANA Considerations IANA-assigned port numbers need be assigned to EAPoIP. Acknowledgements ... References P. Engelstad Expires July 2002 [Page 7] EAP over IP 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. Authors' Addresses 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 July 2002 [Page 8]