Internet Draft P. Engelstad Telenor R&D Expires July 2002 January 2002 A mechanism for Discovery of PANA Authentication Agents (PAA-discovery) 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 A PANA authentication protocol is under development in the PANA Working Group. It will allow hosts to authenticate with PANA Authentication Agents (PAAs). The protocol is expected to run over some IP-based transport protocol, such as ICMP, UDP, TCP or SCTP. Before a host can authenticate with a PAA, it must obtain an IP- address of the PAA. This document specifies such a "discovery" mechanism by defining extensions (or options) to Router Advertisements and DHCP messages for both IPv4 and IPv6. Hosts MAY also obtain an identity of a PAA and other information during the discovery process. The proposed discovery mechanism makes no assumptions about the location of a PAA, and more than one PAA may be discovered. P. Engelstad Expires July 2002 [Page 1] EAP over IP January 2002 Table of Contents 1 Introduction.....................................................2 2 Terminology......................................................3 3 Extensions for PAA Discovery.....................................3 3.1 ICMPv4 Router Advertisement Extension for PAA Discovery......4 3.2 DHCPv4 Extension for PAA Discovery...........................4 3.3 ICMPv6 Router Advertisement Option for PAA Discovery.........5 3.4 DHCPv6 Option for PAA Discovery..............................5 3.5 Sub-options for PAA Discovery................................6 3.5.1 PAA IPv4 Address Sub-option............................6 3.5.2 PAA IPv6 Address Sub-option............................6 3.5.3 PAA Identity Sub-option................................7 3.5.4 PANA Initiation Sub-option.............................8 3.5.5 Other Sub-option.......................................8 4 Security Considerations..........................................9 IANA Considerations................................................9 Acknowledgements..................................................10 References........................................................10 Authors' Addresses................................................11 1 Introduction A PANA authentication protocol is under development in the PANA Working Group. It will allow hosts to authenticate with PANA Authentication Agents (PAAs). The protocol is expected to run over some IP-based transport protocol, such as ICMP, UDP, TCP or SCTP. Before a host can authenticate with a PAA, it must obtain an IP- address of the PAA. This document specifies such a "discovery" mechanism by defining extensions (or options) to Router Advertisements and DHCP messages for both IPv4 and IPv6. These extensions (or options) are specified in Section 3 of this document. In situations where DHCP is not implemented, PAA-discovery relies on extensions to IPv4 and IPv6 Router Advertisements. However, such extensions MAY consume substantial bandwidth on the access subnet. Therefore, it is assumed that PAA-discovery should use DHCP extensions instead in situations where DHCP is implemented. (In this case the 'M'-bit or 'O' bit will be set in an IPv6 Router Advertisement [5], and the Router Advertisement will not contain any extensions for PAA-discovery.) In addition to discovering IP-addresses of PAAs, hosts MAY also obtain PAA Identifiers (e.g. in terms of Network Access Identifiers [9]) and other relevant information during the discovery process. Additional information MAY facilitate the subsequent authentication process. However, the benefits of these enhancements to the discovery mechanism may be ruled out by the bandwidth penalty that extra information imposes on the access subnet. P. Engelstad Expires July 2002 [Page 2] EAP over IP January 2002 The proposed discovery mechanism makes no assumption about the location of a PAA; it may be located on the Access Router or somewhere else in the access domain. Moreover, more than one PAA may be discovered. This flexibility assures that the discovery mechanism probably will be able to support the final PANA authentication protocol, when that specification is completed. Examples of PANA protocol proposals can be found in [1], [11] and [12]. A host SHOULD acquire an IP-address for itself, prior to authenticating with PAA. A good argument for this requirement is that the access network cannot enforce IP-address assignment anyway: A malicious host can easily configure any IP-address for itself, although it may encounter problems if the access network implements IP-address filtering (e.g. on the access router). The mechanism proposed in this document allows the host to discover IP-addresses of PAAs while acquiring an IP-address for itself, using either stateless address auto-configuration or DHCP. A PAA discovery mechanism for hosts that intend to authenticate without an IP- address, is outside the scope of this document. The host can actively initiate the discovery process by sending an ICMP Router Solicitation or a DHCP request. The discovery mechanism allows a host to discover IP-addresses of more than one PAA. If the host cannot reach one PAA, it may try to get in contact with another PAA of which it also has acquired an IP-address. There are a number of reasons why a host may not be able to get in contact with one of the PAAs of which it has acquired an IP-address: The PAA or the host could, for example, be subject to a security attack or an extension may have carried obsolate information about a PAA that is no longer present in the access domain. 2 Terminology 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 [2]. 3 Extensions for PAA Discovery Router Advertisement Extensions and DHCP Extensions (or "Options") are defined for both IPv4 and IPv6. Any of these extensions will inform a host that acquires an IPv4 or IPv6 address on how to initiate authentication with PAA. The extensions are intended to simplify PAA discovery, but they are not mandatory. P. Engelstad Expires July 2002 [Page 3] EAP over IP January 2002 Each extension conveys information about one particular PAA. If information about several PAAs needs to be conveyed to the host, the Router Advertisement or DHCP reply message MAY include multiple extensions, one for each PAA. 3.1 ICMPv4 Router Advertisement Extension for PAA Discovery The following extension is suggested for use with ICMPv4 [3]: 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 PANA-RAv4-EXTENSION (TBD) Length This value equals the number of octets of this extension, excluding the Type and Length fields, i.e. only the length of the sub-option field. Sub-options Sub-options are specified in section 3.5. 3.2 DHCPv4 Extension for PAA Discovery The following extension is suggested for use with DHCPv4 [4]: 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 PANA-DHCPv4-EXTENSION (TBD) Len This value equals the number of octets of this extension, excluding the Code and Len fields, i.e. only the length of the sub-option field. Sub-options P. Engelstad Expires July 2002 [Page 4] EAP over IP January 2002 Sub-options are specified in section 3.5. 3.3 ICMPv6 Router Advertisement Option for PAA Discovery The following option is suggested for use with ICMPv6 [5]: 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 PANA-RAv6-OPTION (TBD) Length This value equals the number of octets of this option, excluding the Type and Length fields, i.e. only the length of the sub- option field. Sub-options Sub-options are specified in section 3.5. 3.4 DHCPv6 Option for PAA Discovery The following option is suggested for use with DHCPv6 [6]: 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 PANA-DHCPv6-OPTION (TBD) option length This value equals the number of octets of this option, excluding the option code and option-length fields, i.e. only the length of the sub-option field. Sub-options P. Engelstad Expires July 2002 [Page 5] EAP over IP January 2002 Sub-options are specified in section 3.5. 3.5 Sub-options for PAA Discovery 3.5.1 PAA IPv4 Address Sub-option This sub-option provides the host with the IPv4 address of a PAA. It is typically appended to a DHCPv4 Extension or an IPv4 Router Advertisement Extension for PAA 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 sub-option provides the host with the IPv6 address of a PAA. It is typically appended to a DHCPv6 Option or an IPv6 Router Advertisement Option for PAA 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 P. Engelstad Expires July 2002 [Page 6] EAP over IP January 2002 An IPv6 address of the PAA referred to in this extension. For the time being, there are unsolved problems associated with using shared addresses for stateful communication (as described in RFC 1546 [7]). Since the PANA protocol will be required to accommodate re-authentication, PAA will be a stateful agent. Thus, an IPv6 anycast (or multicast) address SHOULD NOT be used in this sub-option, before resolution of these problems. In the future, one may pre-assign to PAA site-scoped IPv6 addresses that can be hard-coded into the host. (E.g. the range of five site- scoped addresses fec0:0:0:ffff::4 - fec0:0:0:ffff::8 from the address space with SLA value of 'ffff' could be assigned to PAAs in access domains. It is similar to what is proposed for stateless IPv6 DNS discovery in [8]). This may facilitate the authentication process, reduce the fate sharing, and save the additional bandwidth of conveying PAA addresses to the host. 3.5.3 PAA Identity Sub-option This sub-option may facilitate the authentication process by allowing a roaming host to discover an identity of a PAA. Thus, the host can easily determine the (re-) authentication procedure due to the type of handover - e.g. if it has: (1) roamed to a new access domain; (2) roamed to a subnet of the same access domain, but under a different PAA; or (3) roamed to a subnet under the same PAA. Furthermore, if the PANA protocol incorporates EAP the host MAY also authenticate the PAA directly without sending an initial EAP Identity request first. Note, however, that the additional bandwidth consumption on the access link MAY rule out the benefits of this sub-option. 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 P. Engelstad Expires July 2002 [Page 7] EAP over IP January 2002 Length of the PAA Identity field. PAA Identity The identity of the PAA. This identity SHOULD be represented in terms of a Network Access Identifier (NAI), as specified in [9]. 3.5.4 PANA Initiation Sub-option This sub-option informs the host on how to proceed with the PANA authentication process, after the PAA discovery process. It is likely that the roaming host is the one that should take the initial step in the PANA protocol after having completed PAA- discovery. If this is the case, the PANA Initiation Code in this sub-option gives the host directions on how to go on. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-opt. Type | Length | PANA Initiation Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-option Type TBD Length 2 PANA Initiation Code A code which informs hosts on how to proceed with the PANA protocol, after having discovered a PAA. It is likely that the PANA protocol be carried by messages with EAP format, and that the host will initiate the communication using a specific Request/Response Type. The PANA Initiation Code values in the range of 0 - 255 may therefore be reserved for EAP Request/Response Types. 3.5.5 Other Sub-option Other sub-options may be specified in follow-on documents. The final PANA protocol MAY for example find it useful to define a sub-option that allows hosts to obtain temporary MD-5 challenges from the access network during the discovery process. P. Engelstad Expires July 2002 [Page 8] EAP over IP January 2002 4 Security Considerations A malicious node MAY send to a host a Router Advertisement containing a valid PAA-discovery sub-option, although other information in the advertisement MAY be spoofed. Thus, a malicious node can easily become an intruder-in-the-middle that gets access to the domain by using the host as an oracle when authenticating with PAA. This is particularly easy when access control is based only on address filtering of userĘs data traffic without employing security gateways in the access domain. To allow for packet filtering as a means to enforce access control, the PANA protocol MUST let a PAA confirm to hosts that information related to the access domain (including Access Router addresses) are correct. Furthermore, the PANA protocol MUST let a host confirm to PAAs that the hostĘs IP-addresses and other information related to the host (e.g. L2-addresses, port numbers etc.) are correct. Although an Authentication Sub-Option MAY be able to address this issue during the PAA-discovery phase of the PANA protocol, it is assumed that it will be better addressed by other parts of the PANA protocol: a) Hosts and PAAs MAY validate each otherĘs network access information during the session key establishment phase of the PANA protocol. (Then, the session key MUST be re-established every time a host changes address or roams to a new access router.) b) Alternatively, the PANA protocol MAY allow an authenticator to validate network access information of peers during the (re-) authentication phase of the PANA protocol. (In this case, the session key establishment phase MUST be followed up by (re-) authentication.) c) Both a) and b) There are other unresolved security issues related to Neighbor Discovery. An overview is provided in [10]. Since such threats are not only specific to the PANA protocol, they are outside the scope of the PANA Working Group. They are also outside the scope of this document. IANA Considerations An ICMPv4 Router Advertisement Extension Type value need be assigned for PAA Discovery. (Please refer to the PANA-RAv4-EXTENSION value in sub-section 3.1.) A DHCPv4 Extension Code value need be assigned for PAA Discovery. (Please refer to the PANA-DHCPv4-EXTENSION value in sub-section 3.2.) P. Engelstad Expires July 2002 [Page 9] EAP over IP January 2002 AN ICMPv6 Router Advertisement Option Type value need be assigned for PAA Discovery. (Please refer to the PANA-ICMPv6-EXTENSION value in sub-section 3.3.) A DHCPv6 Option Code value need be assigned for PAA Discovery. (Please refer to the PANA-DHCPv6-OPTION value in sub-section 3.4.) Sub-option type values need be assigned to sub-options presented in sub-section 3.5. Acknowledgements ... References [1] Tsirtis, G., "EAP over ICMP", , Work in progress, January 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [3] Deering, S. "ICMP Router Discovery Messages", RFC 1256, September 1991. [4] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [5] Narten, T., Nordmark, E., Simpson, W. "Neighbor Discovery for IP Version 6", RFC 2461, December 1998. [6] Droms, R. (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in progress, November 2001. [7] Partridge, C., Mendez, T. and Milliken, W., "Host Anycasting Service", RFC 1546, November 1993. [8] Thaler, D., Hagino, J.I., "IPv6 Stateless DNS Discovery", Work in progress, November 2001. [9] Aboba, B., Beadles, M. "The Network Access Identifier", RFC 2486, January 1999. [10] Kempf, J., Nordmark, E. "Threat Analysis for IPv6 Public Multi-Access Links", , Work in progress. [11] Engelstad, P. "Extensible Authentication Protocol over IP (EAPoIP)", , Work in progress. P. Engelstad Expires July 2002 [Page 10] EAP over IP January 2002 [12] Yegin et al., "Secure Network Access Using Router Discovery and AAA", , Work in progress. 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 11]