Subject: Another draft: EAP over IP

From: Paal Engelstad <[email-masked]>
Date: Sat, 5 Jan 2002 4:38:23 +0100

> Hi all,

Hi George - and others,

FYI: I also did some analyses that resulted in a draft that I submitted after the SLC meeting. The I-D administrator has returned to office and promised to announce it January 4th, but I have not seen it. Since I hope for some comment before I soon leave for a weeks vacation, I allow myself to attach my draft in this e-mail.  Others not interested: Please excuse me for filling your mail-boxes.

George: I had a little difficulty with reading your draft in the format I got it, but I will soon return with some comments based on what I understood of it.

I do not intend to push the discussion on the list too much into solution-space. On the contrary, I hope my draft may trigger some discussions regarding basic principles that might be useful for the requirements-team. 

Please take a look at the attached EAP-over-IP draft. Comments are welcome. Thanks.

Paal

Internet Draft                                       P. Engelstad 
                                                      Telenor R&D 
Expires: June 2002                                  December 2001 
 
          Extensible Authentication Protocol over IP (EAPoIP) 
    
               <draft-engelstad-pana-eap-over-ip-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. 
    
   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 [email-masked]. 
     
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: [email-masked] 
 
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]

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Mon, 7 Jan 2002 17:11:11 -0600

> 
> Raj,
> 
> >
> > However I think we are jumping the gun here to some extent by
> > beginning to look at solutions already. If we can wait till we get
> > some more discussion on requirements, models and frameworks done,
> > we will be better able to design or choose an appropriate solution.
> >
> 
> Sorry to sound like a broken record, but do you really think
> there is a need for an extensive requirments phase if we
> already know that EAP is part of the solution? It seems
> like a simple problem statement that clarifies what
> the constraints are from existing deployment and
> where the open issues are might be enough.
> 

I have no intention of having an extensive requirements phase. The
PANA charter is quite clear and detailed and as a result the problem
for the most part is well understood. The requirements/termonology I-D
will be ready in about a couple of weeks at which time we can close on
the few requirements that exist and start work on the solutions. The
advantage I see with having a terminology/requirements I-D is that it
will allow everyone to be on the same page and also make it easier
when it comes to selecting a protocol that meets the PANA goals
(charter). 

>             jak

-Basavaraj