Personal G. Tsirtsis Flarion Technologies Internet Draft Title:draft-tsirtsis-eap-over-icmp-00.txt Category: Informational January 2002 Expires : June 2002 EAP over ICMP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This specification describes a way to carry the Extensible Authentication Protocol (EAP) over the Internet Control Message Protocol (ICMP). This provides a generic mechanism for user/device authentication to access routers or other designated nodes. Tsirtsis 1 Internet Draft EAP over ICMP January 2002 INDEX 1. Introduction 3 1.1. Why don't we just use 802.1X? 1.2. Solution overview and scope 2. EAP over ICMP Message definition 4 3. Guidelines to implementation 5 3.1 IP addresses 3.2 Usage and guidelines 3.3. Broadcast-unicast 4. Security Considerations 6 5. IANA Considerations 6 6. Acknowledgements 7 7. References 7 Tsirtsis 2 Internet Draft EAP over ICMP January 2002 1. Introduction End nodes are connected to the Internet either in an unauthenticated or in an authenticated way. Typically, authenticated nodes connect to the Internet via PPP, which includes a number of authentication mechanisms and more recently EAP. With wireless and other always-on services now available, PPP is not always the default way of providing connectivity to end nodes and other alternatives for authentication are being developed. 1.1. Why don't we just use 802.1X? Some link layers (e.g.: 802 family) now provide their own authentication mechanisms implemented with EAP (e.g.: 802.1X). This is becoming increasingly popular but is not adequate in a number of deployment scenarios. For illustration take the case of an 802.11 based network connected to Internet Access Routers (IAR) via an Ethernet infrastructure. One may want to allow end nodes to gain connectivity via such infrastructure without the use of PPP and yet end node authentication may still be required. The use of something like 802.1X in this case is not adequate since this will only authenticate the end node/user to the 802.11 Access Points to which it associates, which may be multiple link layer hops away from the first Internet Access Router. Even worse, consider this same link layer infrastructure providing access to multiple Internet Service Providers (Figure 1). Link Layer authentication in this case is clearly inadequate when it comes to gaining access to one ISP over the other. End <===EAPwith802.1x==> Node ------------------X---X---X---X---IAR---ISP1 Multi-hop L2 | +---X---IAR---ISP2 IAR = Internet Access Router ISP = Internet Service Provider X = Link Layer device (e.g.: access point, switch) Figure 1: Link Layer authentication example 1.2. Solution overview and scope It is clear that an IP based mechanism (Figure 2) is required to allow the end node to authenticate itself to the Internet Access Router of its choice, irrespective of the underlying link layer infrastructure which may or may not require its own authentication. Tsirtsis 3 Internet Draft EAP over ICMP January 2002 End <==========EAPoverICMP============> Node -----------------X---X---X---X---IAR---ISP1 Multi-hop L2 | +---X---IAR---ISP2 Figure 2: Network Layer authentication example Furthermore, another type of authentication is also required that takes place between the end node and a designated node beyond the Internet Access Router but very likely before a firewall (Figure 3). This is typically useful in the context of access to the Internet via a Hotel or other such service. <=====EAPoverICMP========> End -------------------IAR----AuthServer---Firewall--Internet Node Figure 3: Authentication beyond the IAR example - EAP allows the authenticator to use a back end system to assist with the authentication. The details of such a mechanism are out of scope for this document. - Some interaction between the IAR or the Auth. Server and a firewall function is likely required for the policing of the authentication. The details of such a mechanism are also out of scope for this document. - EAP can perform authentication of users as well as devices, no restrictions are imposed to that effect by this specification. - EAP can be used to implement a number of different authentication, and key exchange mechanisms. The details of such mechanisms are outside the scope of this document. 2. EAP over ICMP Message definition ICMPv4/v6 EAP Message ICMPv4 and ICMPv6 protocols employ the same message structure and thus the message definition below is applicable to both protocols. Tsirtsis 4 Internet Draft EAP over ICMP January 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Header ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address The address of the node that composes the ICMP message Destination Address The address of the node to which this message should be sent ICMP Fields: Type TBA Code 0 Checksum The checksum is the 16-bit ones's complement of the one's complement sum of the ICMP message starting with the ICMP Type. For computing the checksum, the checksum field should be zero. This checksum may be replaced in the future. EAP Header As defined in [RFC2284bis] 3. Guidelines to implementation 3.1 IP addresses Depending on the deployment model, the end node involved in the authentication may or may not have a valid global IP address during the time this protocol is used. In this case a zero or a valid link local address may be used as source address in which case only authentication with the IAR is possible. Tsirtsis 5 Internet Draft EAP over ICMP January 2002 Authentication with an Authentication Server can only take place after the end node has a network address that is routable from that server. This could be a global address or a site local address if appropriate. Details on how this address may be acquired are outside the scope of this document and are IP version specific. 3.2 Usage and guidelines End nodes should quote unique identifiers that can be authenticated against. The Network Address Identifier (NAI) is ideal for this purpose since it provides maximum flexibility for the location of the node's authentication records in a multi-provider roaming environment. Still other identifiers may also be used according to the application in question (IMSIs, user names, phone numbers, etc). A number of draft proposals are already describing various authentication mechanisms implemented with EAP; such proposals also include details of the type of identifier to be used. 3.3. Broadcast-unicast If the end node does not know the address of the Access Router with which it should authenticate, an ICMP-EAP message may be sent to the subnet broadcast address or the all routers multicast address according to IPv4 and IPv6 rules. If the Authenticator does not know the IP address of the end node but knows its link layer address, an ICMP-EAP message may be sent to the all nodes on link network address while the IP packet can be encapsulated in a link layer frame with the unicast link layer address of that node as destination address. 4. Security Considerations This specification describes a way of carrying EAP over ICMP messages. All the EAP related security considerations described in RFC2284bis are also applicable here. QUESTION: Are there any more security issues relevant the specific environment we are looking at here? 5. IANA Considerations A Type value for both ICMPv4 and ICMPv6 is required to be assigned for EAP. Tsirtsis 6 Internet Draft EAP over ICMP January 2002 6. Acknowledgements The subject of this draft has been discussed at length with my colleagues Alan O'Neill, Scott Corson, Vincent Park and Matt Impett from Flarion Technologies. 7. References [RFC2284bis], L. Blunk et.al, Extensible Authentication Protocol (EAP), November 2001, Work in Progress. [ICMPv6], A. Conta, S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, draft-ietf-ipngwg-icmp-v3-02.txt, November 2001, Work in progress [ICMPv4], J. Postel, Internet Control Message Protocol, RFC792, September 1991 Author's Address George Tsirtsis Flarion Technologies +44 (0)20 88260073 G.Tsirtsis@Flarion.com gtsirt@hotmail.com Copyright Notice Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is Tsirtsis 7 Internet Draft EAP over ICMP January 2002 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Tsirtsis 8 ----------------------------------------------------------------------------