Subject: EAP over ICMP

From: George Tsirtsis <[email-masked]>
Date: Fri, 4 Jan 2002 19:49:48 -0500

Hi all,

Here is a draft that reflects some of the discussion in SLK meeting and
proposes a solution to the PANA problem. This will also appear on the IETF
directory as normal in a few days...

Let me know what you think

Thanks
George

-----------------------------------------------------------------------

Personal                                                    G. Tsirtsis 
                                                   Flarion Technologies 
Internet Draft                                                          
Title:draft-ietf-tsirtsis-eap-over-icmp-00.txt                          
Category: Informational                                    January 2002 
Expires : June 2002                                                     

                                EAP over ICMP 
                  <draft-ietf-tsirtsis-eap-over-icmp-00.txt> 
    
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), <draft-ietf-pppext-rfc2284bis-01.txt> 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 
      [email-masked]  
      [email-masked] 

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

---

From: "Carl Williams" <[email-masked]>
Date: Fri, 4 Jan 2002 17:07:45 -0800

Hi George,

     I have take a quick look at your draft.

    You don't explain why ICMP was choose as the
    carrier (vs other methods such as the one SNARD uses).

    I consider ICMP for control - allowing one to troubleshoot
    networks and other related uses.

   You might provide that with your design choice analysis.

   Carl