Subject: RE: EAP over ICMP

From: George Tsirtsis <[email-masked]>
Date: Mon, 7 Jan 2002 05:06:04 -0500

Hi Carl,

First of all I thought SNARD also used ICMP (Router adverts and
solicitations)! The only difference is that I do not like the idea of
piggybacking the PANA protocol on RS/RAs. The reason is that an
authentication challenge should be possible to be sent at any time from any
of the parties involved and as many time as the specific authentication
protocol requires...

Note that SNARD has not demonstrated that EAP can be carried over it, and
EAP seems to be gaining support in this area.

On the other hand I do not like the idea of running PANA over UDP/TCP either
due to the overhead involved. Straight forward ICMP seems to me to be
ideal...

George

-----Original Message-----
From: Carl Williams [mailto:[email-masked]]
Sent: Saturday, January 05, 2002 1:08 AM
To: George Tsirtsis; Pana (E-mail)
Subject: Re: EAP over ICMP 

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

----- Original Message -----
From: "George Tsirtsis" <[email-masked]>
To: "Pana (E-mail)" <[email-masked]>
Sent: Friday, January 04, 2002 4:49 PM
Subject: EAP over ICMP

> 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: Mon, 7 Jan 2002 11:04:55 -0800

Hi George,

   Yes, i thought about that after I sent my email.

    George, I think at one time you (to some degree) advocated the use of
    ND as a carrier.  Recall your previously email sent on August 21, 2001
in which you
    propose that Neighbor Discovery (ND) as a carrier for the AAA parameters
    when discussing communication between the end node and the access
router.
    (your email is attached below).

     But maybe your thinking has evolved since we got into the details of
the discussion.

     fyi...

     Carl

<!--StartFragment-->Old-Return-Path: <[email-masked]>
From: George Tsirtsis <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>,
   Charlie Perkins
	 <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
   [email-masked]
Subject: RE: [AAA-WG]: AAA for IPv6
Date: Tue, 21 Aug 2001 08:06:30 -0400
Resent-Message-ID: <8j5cmB.A.e-C.g7kg7@thumper>
Resent-From: [email-masked]
Resent-Sender: [email-masked]

It seams to me that the subject of "AAA for IPv6" has at least two
components that may potentially belong to different WGs. One is the
communication between the end node and the access router and the other is
the communication between the AAA client in the Access Router and the rest
of the AAA infrastructure.

The latter is all about IPv6 support in the AAA protocol (Radius, diameter,
cops)...and thus belongs to the AAA/COPS WGs...

The former is about challenging the end node and transporting the
identification and authentication parameters over the access link. This is
not part of the AAA protocol (e.g.: typically Radius does not run over the
access link). What is needed is a "carrier" mechanism for the parameters
that need to be fed to the AAA protocol. PPPv6 for example provides such a
carrier. MIPv4 also provides such a carrier to IPv4 nodes that use Mobile IP
but, MIPv6, due to the lack of FAs, does not provide such an obvious
carrier...hence Charlie's work. Now, there are a couple of things that can
be done IMO.

1. Use Neighbor Discovery (ND) as a carrier for the AAA parameters. e.g.:
extend Neighbor Advertisements and Router Advertisements to carry
challenge/response messages....this to me is the job of IPv6 WG and could be
the start of a much bigger fish called authenticated ND or

2. Create a new carrier, independent from ND and with the specific task of
carrying the appropriate challenge/response parameters...this to me belongs
to URP WG.

...my two drachma

Regards
George

---

From: "James Kempf" <[email-masked]>
Date: Mon, 7 Jan 2002 11:27:01 -0800

George,

I believe the idea in SNARD is that a challenge can be issued at any
time by sending out another RA. Sending
an RS can be used by the host to challenge the router.

            jak

----- Original Message -----
From: "George Tsirtsis" <[email-masked]>
To: "'Carl Williams'" <[email-masked]>; "George Tsirtsis"
<[email-masked]>; "Pana (E-mail)" <[email-masked]>
Sent: Monday, January 07, 2002 2:06 AM
Subject: RE: EAP over ICMP

> > Personal                                                    G.
Tsirtsis
> >                                                    Flarion
Technologies
> > Tsirtsis
1
> > Internet Draft              EAP over ICMP                January
2002
3
> >    2. EAP over ICMP Message definition
4
> >    3. Guidelines to implementation
5
> >    4. Security Considerations
6
> >    5. IANA Considerations
6
> >    6. Acknowledgements
7
> >    7. References
7
> > Tsirtsis
2
> > Tsirtsis
3
> > Tsirtsis
4
> > Tsirtsis
5
> > Tsirtsis
6
> > Tsirtsis
7
> > Tsirtsis
8