Internet Draft P. Engelstad Telenor R&D Expires: June 2002 December 2001 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. Copyright Notice Copyright (C) The Internet Society. All Rights Reserved. Abstract This document defines the Extensible Authentication Protocol over IP (EAPoIP), which basically is a variation of the Extensible Authentication Protocol (EAP). Unlike EAP, it runs over IP. EAPoIP is intended primarily for authentication of hosts in an access domain. EAPoIP assumes that the host has established a link-layer connection to an access router and has configured a valid IPv4 or IPv6 address for itself on the subnet by DHCP, by address auto- configuration, or by other means. Dynamically configurable firewalls may be used to shield unauthenticated and unauthorized hosts on the access subnets from resources in the inner parts of the access domain. A PANA Authentication Agent (PAA), which is an Authentication Server located somewhere in the access domain, authenticates the host. The host may also authenticate the PAA. P. Engelstad Expires June 2002 [Page 1] EAP over IP December 2001 Table of Contents 1. Introduction................................................. 2 1.1 Specification of Requirements 1.2 Terminology 2. EAPoIP Overview ............................................. 4 3. Extensions for EAPoIP Service Discovery ..................... 5 3.1 ICMPv4 Router Advertisement Extension 3.2 DHCPv4 Extension 3.3 ICMPv6 Router Advertisement Option 3.4 DHCPv6 Option 3.5 Sub-options for EAPoIP Service Discovery 3.5.1 PAA IPv4 Address Sub-option 3.5.2 PAA IPv6 Address Sub-option 3.5.3 PAA Identity Sub-option 3.5.4 Other Sub-options 4. EAPoIP Packet and Message Formats (Post-IKE) ................ 9 4.1 EAPoIP Transport Protocols 4.2 EAPoIP uses IKE and IPSec 4.3 EAPoIP message format 5. Initial EAPoIP Request/Response Types ....................... 12 5.1 Supported EAP-Types 6. Post-IKE EAPoIP Message Formats and Contents ................ 13 Security Considerations ........................................ 13 IANA Considerations ............................................ 13 References ..................................................... 13 Authors' Addresses ............................................. 14 Appendix A ..................................................... 15 A.1 Mandatory message codes and formats A.2 Request and Response A.3 Success and Failure Appendix B ..................................................... 17 B.1 Mandatory Initial Request/Response EAP-types (Post-IKE) B.2 Identity B.3 Notification B.4 NAK B.5 MD5-Challenge 1. Introduction This document defines the Extensible Authentication Protocol over IP (EAPoIP). EAPoIP is intended primarily for authentication of hosts that want to be authorized access to resources in the access domain. EAPoIP assumes that the host has established a link-layer connection to an access router and has configured a valid IPv4 or IPv6 address for itself on the subnet by DHCP, by address auto-configuration, or by other means. Dynamically configurable firewalls may be used to shield unauthenticated and unauthorized hosts on the access subnets from resources in the inner parts of the access domain. If the firewall and PAA are not co-located, PAA MAY use a MIDCOM protocol to P. Engelstad Expires June 2002 [Page 2] EAP over IP December 2001 dynamically configure the firewall and allow domain access to authenticated and authorized hosts. A MIDCOM protocol is currently under development in IETF. The MIDCOM Working Group of IETF has determined the requirements of the protocol. A PANA Authentication Agent (PAA), which is an Authentication Server located somewhere in the access domain, authenticates the host. The host may also want to authenticate the PAA. EAPoIP runs over IP and is link-layer agnostic; hosts may connect over either point-to-point or multi-access links. The authentication part of EAPoIP runs over UDP (or TCP or SCTP), which is also IP-agnostic; it may run over either IPv4 or IPv6. The EAPoIP protocol consists of four main elements: 1) PAA Discovery: Mobile nodes and other hosts discover IP-addresses and identities of PAAs located in the access domain. 2) "Pre-IKE" EAPoIP: Hosts and PAAs prepares for IKE (below) [17], e.g. they set up a trust relationship by using some back-end AAA Infrastructure (e.g. Radius or Diameter). Pre-IKE EAPoIP uses an IANA-assigned port number. It must be designed with security in mind, since there may not exist an initial trust relationship between PAA and the host. 3) Internet Key Exchange (IKE): The host initiates an IKE session with PAA over UDP port 500, to set up IPSec Security Associations in both directions. 4) "Post-IKE" EAPoIP: All applications and protocols may authenticate the peer using the same authentication methods that are defined for EAP. All messages use a IANA-assigned port number, and MUST be protected by IPSec AH and ESP. Post-IKE EAPoIP is basically a variation of the Extensible Authentication Protocol (EAP), although it runs over IP. Thus, significant parts of this document are VERBATIM cut-and-paste from RFC 2284 [7]. It reuses the extension formats for request-, response-, success-, and failure-messages defined for EAP, as well as the initial EAP request/response types. Unlike EAP, EAPoIP does not provide ways to negotiate non-EAPoIP authentication mechanisms. Pre-IKE EAPoIP is a request/response scheme that re-uses the Post- IKE message formats. EAPoIP is built around IPSec and IKE. Ideally IPSec and IKE could replace both Pre-IKE and Post-IKE EAPoIP: - Instead of using Pre-IKE EAPoIP, PAA may alternatively use the back-end AAA infrastructure between IKE message 5 and IKE message 6 of phase 1 - assuming Main Mode. With skillful use of IKE, e.g. by using signature keys or by revealing the FQDN of the host, one may argue that pre-IKE EAPoIP may not be required in any circumstances. This document, however, assumes that IKE alone P. Engelstad Expires June 2002 [Page 3] EAP over IP December 2001 will not be able to fulfill all requirements of all PANA scenarios. - The existence of valid IPSec Security Associations implies that the peer is already authenticated, and one may argue that Post- IKE EAPoIP authentication is redundant. On the other hand, Post- IKE EAPoIP allows any protocol or application to freely authenticate and re-authenticate the peer (i.e. an authenticated ping) at any time. Post-IKE EAPoIP will not be allowed unless appropriate IPSec Security Associations are in place. 1.1 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [6]. 1.2 Terminology This document uses the same terms as [7], except for: Peer: A node that is being authenticated by an authenticator. Authenticator: The node requiring the authentication. The following additional terms are used in this document: PANA Authentication Agent (PAA): The EAPoIP Authentication Server. It is also the authenticator that authenticates the host. Common Authentication Authority (CAA): An authority that has a trust relationships with both the peer and the authenticator. Both peer and authenticator can communicate with CAA using strong security mechanism. AAA protocols, such as Diameter or Radius, may be utilized to carry such communication. A mobile node that roams to a foreign access network may not share a secret with the PAA or there may not be an appropriate Public Key Infrastructure in place. The authenticator and peer may use the CAA to authenticate each other in a secure way. 2. EAPoIP Overview The Extensible Authentication Protocol over IP (EAPoIP) is a general protocol for IP-based authentication, which supports multiple authentication mechanisms. It is a uni-directional protocol that allows the authenticator to authenticate the peer. The uni-directional (Post-IKE) authentication process proceeds as follows: 1. The authenticator sends one or more Requests to authenticate the peer. The Request has a type field to indicate what is being P. Engelstad Expires June 2002 [Page 4] EAP over IP December 2001 requested. Examples of Request types include Identity, MD5- challenge, One-Time Passwords, Generic Token Card, etc. The MD5- challenge type corresponds closely to the CHAP authentication protocol [3]. Typically, the authenticator will send an initial Identity Request followed by one or more Requests for authentication information. However, an initial Identity Request is not required, and MAY be bypassed in cases where the identity is presumed. 2. The peer sends a Response message in reply to each Request. As with the Request message, the Response message contains a type field, which corresponds to the type field of the Request. 3. The authenticator ends the authentication phase with a Success or Failure message. The authenticator MAY authenticate the peer using a sequence of methods. Thus, the authentication process can loop through steps 1 and 2 a number of times until the authenticator finally moves to step 3. The authentication process may also fail because the authenticator or peer times out, possibly after a number of retransmission attempts. In most cases for which EAPoIP is intended bi-directional authentication is required. Two uni-directional authentication processes going in opposite directions comprise the bi-directional authentication. In one direction the host takes the role as the authenticator and authenticates the PAA as a peer. In the other direction the PAA takes the role as the authenticator and authenticates the host as a peer. In some cases for which EAPoIP is intended the host will be the first to start authenticating the other party by sending a Request to the PAA (e.g. when the host roams to a new access network an discovers the PAA or when an authentication time-out event occurs by the host). In other cases, the PAA will be the first to start authenticating the host (e.g. when the host acquires an IP address or attempts to access another resource or when an authentication time-out event occurs by the PAA.) An authentication request message from one party may trigger the other party to start authenticating the other way. An authenticator MAY even assume the identity of the peer from the Request message, or from previous communication, and use this information to skip the Identity Request phase. 3. Extensions for EAPoIP Service Discovery Router Advertisement Extensions and DHCP Extensions (or "options") are defined for both IPv4 and IPv6. These will inform a host that acquires an IPv4 or IPv6 address on how to get started with the authentication process in order to get access to the interior access P. Engelstad Expires June 2002 [Page 5] EAP over IP December 2001 domain. The extensions are expected to simplify PAA discovery, but they are not mandatory. Each extension conveys information about one particular PAA. If there are many PAAs in the access domain, the Router Advertisements or DHCP reply messages MAY include one extension for each PAA in the domain. 3.1 ICMPv4 Router Advertisement Extension for EAPoIP Service Discovery This document suggests that the following extension MAY be used with ICMPv4 [10]: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type EAPoIP-RAv4-EXTENSION (TBD) Length This value equals the number of octets of the extension, excluding the Type and Length fields, i.e. it only includes the length of the sub-option field. Sub-options Sub-options are specified in section 3.5. 3.2 DHCPv4 Extension for EAPoIP Service Discovery This document suggests that the following extension MAY be used with DHCPv4 [11]: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Len | Sub-options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code EAPoIP-DHCPv6-EXTENSION (TBD) Len This value equals the number of octets of the extension, excluding the Code and Len fields, i.e. it only includes the length of the sub-option field. P. Engelstad Expires June 2002 [Page 6] EAP over IP December 2001 Sub-options Sub-options are specified in section 3.5. 3.3 ICMPv6 Router Advertisement Option for EAPoIP Service Discovery This document suggests that the following option MAY be used with ICMPv6 [12]: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type EAPoIP-RAv6-OPTION (TBD) Length This value equals the number of octets of the option, excluding the Type and Length fields, i.e. it only includes the length of the sub-option field. Sub-options Sub-options are specified in section 3.5. 3.4 DHCPv6 Option for EAPoIP Service Discovery This document suggests that the following option MAY be used with DHCPv6 [13]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option code | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Option ... +-+-+-+-+-+-+-+ option code EAPoIP-DHCPv6-OPTION (TBD) option length This value equals the number of octets of the extension, excluding the option code and option-length fields, i.e. it only includes the length of the sub-option field. Sub-options P. Engelstad Expires June 2002 [Page 7] EAP over IP December 2001 Sub-options are specified in section 3.5. 3.5 Sub-options for EAPoIP Service Discovery 3.5.1 PAA IPv4 Address Sub-option This optional sub-option allows the host to discover the IPv4 address of a PAA present in the access domain. It is typically included in DHCPv4 Extensions and IPv4 Router Advertisement Extensions for EAPoIP Service Discovery. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-opt. Type | Length | IPv4 Address (4 octets)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Option Type TBD Length 4 IPv4 Address An IPv4 address of the PAA referred to in this extension. 3.5.2 PAA IPv6 Address Sub-option This optional sub-option allows the host to discover the IPv6 address of a PAA present in the access domain. It is typically included in DHCPv6 Extensions and IPv6 Router Advertisement Extensions for EAPoIP Service Discovery. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-opt. Type | Length | IPv6 Address (16 octets)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-option Type TBD Length 16 IPv6 Address An IPv6 address of the PAA referred to in this extension. P. Engelstad Expires June 2002 [Page 8] EAP over IP December 2001 Since EAPoIP is a stateful protocol, the IPv6 Address SHOULD NOT be an anycast addresses before the problems regarding anycast for stateful communication as described in RFC 1546 [8], have been solved for IPv6. One may in the future pre-assign to EAPoIP site-scoped IPv6 addresses that can be hard coded into the host. (E.g. the five site- scoped addresses fec0:0:0:ffff::4 - fec0:0:0:ffff::8 from the address space with SLA values of 'ffff' could be assigned to EAPoIP, similar to what is proposed for stateless IPv6 DNS discovery in [9]). This may facilitate the authentication process, reduce the fate sharing, and save the additional bandwidth of conveying the PAA addresses to the host. 3.5.3 PAA Identity Sub-option This optional sub-option allows the host to discover the identity of the PAA that the extension concerns. It allows the host to authenticate the PAA directly without sending an initial EAPoIP Identity request first. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-opt. Type | Length | PAA Identity ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-option Type TBD Length Length of the PAA Identity field. PAA Identity The identity of the PAA. 3.5.4 Other Sub-options Other sub-options may be specified at a later stage. 4. EAPoIP Packet and Message Formats 4.1 EAPoIP Transport Protocols This document suggests EAPoIP runs over UDP. (The alternative of running EAPoIP over TCP or SCTP is for further study. Experience from implementations may determine the best transport protocol for EAPoIP.) EAPoIP SHOULD run with IANA-assigned port numbers (TBD). P. Engelstad Expires June 2002 [Page 9] EAP over IP December 2001 4.2 EAPoIP uses IKE and IPSec Since the authentication session may be sent over shared medias, EAPoIP is more vulnerable to snooping and packet modification attacks than EAP is over a PPP links. This document proposes therefore that every EAPoIP packet (including IP header fields) MUST be protected by IPSec AH strong authentication, unless otherwise explicitly specified in this document. Furthermore, every EAPoIP payload MUST be protected by IPSec ESP strong encryption, unless otherwise explicitly specified in this document. IPSec is specified in [14] - [17]. Packet authentication is a security mechanism that comes in addition to the EAP-like authentication of the peer. As shown later in this document, applications and protocols may run EAP authentication methods over EAPoIP, using the given UDP-port number, and the same message-codes and type-values that the EAP method would use (because the message formats are the same). Such EAP-like authentication messages MUST NOT be sent or accepted without being strongly protected by IPSec AH and IPSec ESP. With this rule in mind, a protocol or application can safely substitute a PPP EAP authentication method with its EAPoIP counterpart, with assurance that this transition will not compromise the security of the authentication. When a host wants to use EAPoIP to gain access to a protected access domain, it may be in one of the following situations: 1) The host has not a trust relationship to any CAA that the PAA has a trust relationship to. In this case the host will not get access to the domain. 2) The host has a trust relationship to a CAA that the PAA also has a trust relationship to. In this case the host MAY get access to the domain in the following way: a) "Pre-IKE" EAPoIP: Some "pre-IKE" EAPoIP messaging between the host and the PAA may be a prerequisite to accommodate a subsequent session of The Internet Key Exchange (IKE) [17]. The PAA and host may use the CAA to exchange and verify public keys, to exchange certificates signed by the CAA, or to exchange pre- shared secrets. In the latter case, a roaming host may need to pass a binding between its IP-address and a temporary or encrypted identity, since the existing IKE specification requires such an address-identity binding. Pre-IKE EAPoIP messages between hosts and PAAs cannot be protected by IPSec, because there is no IPSec Security Association yet established between the host and the PAA. This calls for an exception to the IPSec-based security rule above, and such messages MUST utilize specific strong security mechanisms. Communication between PAAs and CAAs MUST be protected by strong authentication and encryption. Pre-IKE P. Engelstad Expires June 2002 [Page 10] EAP over IP December 2001 communication MAY result in maximum one round-trip-time worth of messaging between PAA and CAA. b) Internet Key Exchange (IKE): The host initiates an IKE-session with PAA on UDP port 500. If the Pre-IKE EAPoIP above was not necessary, the PAA MAY consult the CAA between message 5 and 6 (assuming that Main Mode is being used in phase 1, and that the host passes its identity to PAA in the 5th message). On the other hand, if the Pre-IKE EAPoIP resulted in one round-trip-time worth of messaging between PAA and CAA, PAA may not need to consult CAA during the IKE-session. After IKE phase 1, the host and PAA establishes the IPSec Security Associations in phase 2. c) Post-IKE EAPoIP: The peer and the host MAY authenticate and re-authenticate each other, using EAP-like authentication mechanisms that is protected by the IPSec security associations established by IKE. 3) If the host has a trust relationship to the PAA (or the CAA is co-located with the PAA), but the IPSec Security Associations are not yet established, the host uses IKE to establish the Security Associations which are used to protect subsequent post-IKE EAPoIP communication. 4) If the host and PAA already have established the required IPSec Security Associations they MAY start with post-IKE EAPoIP communication directly. 4.3 EAPoIP message format (Post-IKE) The EAPoIP message in the UDP packet uses the same format as the EAP packet. A summary of the EAPoIP 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 EAPoIP message. EAPoIP Codes are the same as the EAP Codes, and are assigned as follows: 1 Request 2 Response 3 Success 4 Failure P. Engelstad Expires June 2002 [Page 11] EAP over IP December 2001 Identifier The Identifier field is one octet and aids in matching 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. All EAPoIP implementations MUST support the same message codes and message formats that EAP supports, and EAPoIP MUST support message codes 1-4. The message codes and formats are described in Appendix A, with only minor modifications from the original text in RFC 2284 [7]. 5. Initial EAPoIP Request/Response Types This section defines the initial set of EAPoIP Types used in Request/Response exchanges. 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The Code-field is 1 for Request and 2 for Response. Refer to Appendix A for more details. The Type field is one octet and identifies the structure of an EAPoIP Request or Response message. Different request/response types are described below. 5.1 Supported EAP-Types The initial EAPoIP Request/Response Types include (a subset of) the initial EAP Request/Response Types, using the same Type values as EAP does [7]. These include the type values: 1 Identity 2 Notification P. Engelstad Expires June 2002 [Page 12] EAP over IP December 2001 3 NAK (Response only) 4 MD5-Challenge Every (Post-IKE) EAPoIP message that uses an EAP Type value MUST be strongly protected by IPSec AH and ESP: Authenticators or peers MUST NOT send such messages without IPSec AH and ESP, and they MUST be silently discarded upon reception. With this rule in mind, a protocol or application can safely substitute a PPP EAP authentication method with its EAPoIP counterpart, without compromising the security of the authentication. All EAPoIP implementations MUST support the same EAP-Types that EAP MUST support, and EAPoIP MUST support EAP-Types 1-4. These types are described in Appendix B, with only minor modifications from the original text in RFC 2284 [7]. Additional Types may be defined in follow-on documents. 6. Pre-IKE EAPoIP Message formats This document suggests that Pre-IKE EAPoIP messages use the same messaging format as the post-IKE (i.e. EAP-like) EAPoIP message format described above. However, since Pre-IKE EAPoIP messages require special security mechanisms, they should be clearly and easily distinguished from Post-IKE messages. One may for example use different ranges of Initial request/response types, or different message codes, or even different IANA-assigned UDP port numbers. One may define a set of generic Attribute-Length-Value (ALV) pairs that can be used in Pre-IKE messages. The formats of Pre-IKE EAPoIP messages and their contents are for further study. Security Considerations Security issues are the primary topic of this document... IANA Considerations TBD... Acknowledgements ... References [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. P. Engelstad Expires June 2002 [Page 13] EAP over IP December 2001 [3] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [4] Haller, N. and C. Metz, "A One-Time Password System", RFC 1938, May 1996. [5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [7] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Protocol", RFC 2284, March 1998. [8] Partridge, C., Mendez, T. and Milliken, W., "Host Anycasting Service", RFC 1546, November 1993. [9] Thaler, D., Hagino, J.I., "IPv6 Stateless DNS Discovery", Work in progress, November 2001. [10] Deering, S. "ICMP Router Discovery Messages", RFC 1256, September 1991. [11] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [12] Narten, T., Nordmark, E., Simpson, W. "Neighbor Discovery for IP Version 6", RFC 2461, December 1998. [13] Droms, R. (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in progress, November 2001. [14] Kent, S., Atkinson, R. "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [15] Kent, S., Atkinson, R. "IP Authentication Header", RFC 2402, November 1998. [16] Atkinson, R., Kent, S. "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [17] Harkins, D., Carrel, D. "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [18] IEEE Standard for Local and Metropolitan Networks: Port bases Network Access Control, IEEE Std 802.1X-2001, June 2001. Authors' Addresses Paal E. Engelstad Telenor R&D (California) 399 Sherman Ave. Suite #12 P. Engelstad Expires June 2002 [Page 14] EAP over IP December 2001 Palo Alto, CA 94306, USA Tel.: + 1-650- 714 7537 e-mail: paal@telenorisv.com Appendix A A.1 Mandatory message codes and formats All EAPoIP implementations MUST support the same message codes and message formats that EAP supports, and EAPoIP MUST support message codes 1-4. The message codes and formats are described in the following two sub-sections, with only minor modifications from the original text in RFC 2284 [7]. A.2 Request and Response Description The authenticator sends a Request message to the peer. Each Request has a type field which serves to indicate what is being requested. The authenticator MUST transmit an EAPoIP 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: The authentication process will in some cases involve user input. In other cases, on the other hand, it will not require user input, but run over an unreliable medium (e.g. wireless) and have strict timing constrains. Hence, some care must be taken when deciding upon retransmission strategies and authentication timeouts. One solution might be to set the retry counter to zero by default, which is also done for EAP over 802.1x [18]. In this case, retransmissions will never occur. Instead the peer times out and authentication is restarted. The identity value will be renewed, which makes the MD5-challenge authentication type more similar to CHAP [3]. However, this issue is for further study. Experience from implementations may determine the best retransmission strategy for EAPoIP.) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P. Engelstad Expires June 2002 [Page 15] EAP over IP December 2001 | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 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 EAPoIP 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 EAPoIP 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 that 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. A.3 Success and Failure Description The Success message is sent by the authenticator to the peer to acknowledge successful authentication. The authenticator MUST transmit an EAPoIP message with the Code field set to 3 (Success). P. Engelstad Expires June 2002 [Page 16] EAP over IP December 2001 If the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests) then the implementation MUST transmit an EAPoIP 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 messages are not acknowledged, they may be potentially lost. A peer MUST allow for this circumstance. By setting the retry counter to zero, as this document proposes as a default configuration, loss of a Success or Failure message will result in peer timeout, and restarting of the authentication process. A summary of the Success and Failure 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Appendix B B.1 Mandatory Initial Request/Response EAP-Types (Post-IKE) All EAPoIP implementations MUST support the same initial request/response EAP-Types that EAP MUST support, and EAPoIP MUST support EAP-Types 1-4. These types are described in the following four sub-sections, with only minor modifications from the original text in RFC 2284 [7]. A.2 Identity Description P. Engelstad Expires June 2002 [Page 17] EAP over IP December 2001 The Identity Type is used to query the identity of the peer. Generally, the authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the peer in the case where there expectation of interaction with a user. A Response MUST be sent to his Request with a Type of 1 (Identity). Implementation Note: The peer MAY obtain the Identity via user input. It is suggested that the authenticator retry the Identity Request in the case of an invalid Identity or authentication failure to allow for potential typos on the part of the user. It is suggested that the Identity Request be retried a minimum of 3 times before terminating the authentication phase with a Failure reply. The Notification Request MAY be used to indicate an invalid authentication attempt prior to transmitting a new Identity Request (optionally, the failure MAY be indicated within the message of the new Identity Request itself). Type 1 Type-Data This field MAY contain a displayable message in the Request. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response message and hence a null is not required. B.3 Notification Description The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. The peer SHOULD display this message to the user or log it if it cannot be displayed. It is intended to provide an acknowledged notification of some imperative nature. Examples include authentication failure warnings, and warnings that a password with an expiration time is about to expire. In most circumstances, notification should not be required. Type 2 Type-Data The Type-Data field in the Request contains a displayable message greater than zero octets in length. Length field of the Request message determines the length of the message. The message MUST not be null terminated. A Response MUST be sent in reply to the P. Engelstad Expires June 2002 [Page 18] EAP over IP December 2001 Request with a Type field of 2 (Notification). The Type-Data field of the Response is zero octets in length. The Response should be sent immediately (independent of how the message is displayed or logged). B.4 NAK Description The NAK Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains the authentication Type desired by the peer. Type 3 Type-Data This field MUST contain a single octet indicating the desired authentication type. B.5 MD5-Challenge Description The MD5-Challenge Type is analogous to the PPP CHAP protocol [3] (with MD5 as the specified algorithm). The PPP Challenge Handshake Authentication Protocol RFC [3] should be referred to for further implementation specifics. The Request contains a "challenge" message to the peer. A Response MUST be sent in reply to the Request. The Response MAY be either of Type 4 (MD5- Challenge) or Type 3 (NAK). The NAK reply indicates the peer's desired authentication mechanism Type. All EAPoIP implementations MUST support the MD5-Challenge mechanism. Type 4 Type-Data The content of the Type-Data field is summarized below. For reference on the use of this fields see the PPP Challenge Handshake Authentication Protocol [3]. 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-Size | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P. Engelstad Expires June 2002 [Page 19] EAP over IP December 2001 P. Engelstad Expires June 2002 [Page 20]