Subject: RE: EAP over ICMP

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

Hi Paal,

comments inline...

-----Original Message-----
From: Paal Engelstad [mailto:[email-masked]]
Sent: Saturday, January 05, 2002 4:51 AM
To: [email-masked]; [email-masked]
Subject: Re: EAP over ICMP

Hi George

I have a few comments on your draft. I could not easily read it in the
format I got it, especially not the illustrations, so excuse me if I have
missed important points: 

1) Your draft (or how I understood it) seems to suggest that the
EAP-over-ICMP authenticator must reside on the access router. Right? 

GT> Nop! read again...The authenticator can be the AR or a box between the
AR and the site firewall. (i.e.: any box)...check figures 2 & 3.

2) Locating the PAA on the access router naturally makes it easier for a
mobile node to be authenticated before it aqcuires an IP-address. But then
again, L2 EAP may be just as fine to fulfill such requirements. Furthermore,
I think the requirement of authenticating without an IP address may rule out
IKE. For roaming nodes, it will be difficult enough to run IKE *with* an
IP-address...;-)

GT> EAP over ICMP can run with or without an IP address (i.e.: before or
after autoconfiguration)...clearly if the client does not have an address
then the authenticator has to be the AR but if the client does have an IP
address the authenticator can be anywhere.

3) In the EAP-over-IP draft, on the contrary, I assumed the most generic
usage scenario presented in SLC: The PAA can be located anywhere on the
access domain. (This scenario should probably allow many PAAs to exist in
the domain, to reduce fate-sharing). However, in this scenario it might be
difficult to fulfil the requirement of authentication without an IP address
of some sort. 

GT> As I said...same here...I am just doing it over ICMP...UDP is too
wasteful and PANA to me should become a fundamental part of the Internet
architecture...so it has to be both simple and efficient.

4)I assume that you chose ICMP to streamline ND with authentication. It fits
well if the PAA is located on the AR. I cannot see other reasons for using
ICMP...Comments?

GT> ICMP can clearly run between any two nodes in the Internet so it does
what you try to do over UDP (figure 3 in my draft)  but it does it more
efficiently. So, while it fulfills the requirements for authentication to a
server inside a network, it does so more efficiently and thus is equally
applicable to authentication to ARs over potentially expensive connections
(e.g.:wireless) in which case efficiency is very important.

5) Your solution needs to address that EAP-like authentication mechanisms
might be subject to different types of attacks than the mechanisms used to
secure the communication channel. These two different sets vulnerabilities
may therefore require orthogonal security mechanisms. (An example from top
of my mind: EAP-authentication is targeted at authentication over PPP, and a
password-based challenge/response mechanism may be sufficient against replay
attacks for some protocols/applications.  The PANA-EAP communication
channel, on the other hand, may be inherently vulnerable to packet snooping,
and packet modification attacks. Dictionary attacks may also turn out to be
easier to launch over IP. Thus, although weak security mechanisms might be
sufficient for an EAP-authentication in some cases, strong security might be
required to secure the PANA-EAP communication channel.) I think the best way
to address this issue is to port the EAP-protocol to IP, and combine it with
IKE and IPSec. Otherwise, I think the WG will get a lot to do. The main
security requirement here is that an application or protocol that wants to
port its authentication mechanism from PPP EAP to some PANA-EAP, should be
confident that the authentication is not less secure than over PPP.   

GT> I need to think about this more but as an initial thought EAP over ICMP
is more or less as secure as the actual authentication mechanism used...PAP,
CHAP, AKA and many other mechanisms are possible over EAP but they provide
very different security levels. You need to pick one according to the
environment you operate on. 

6) BTW: Does <draft-ieft-...> indicate that it should be considered a
working group document?

GT> Names are irrelevant...it is up to the WG and its chairs to decide what
becomes a WG doc.

George
P.S: Paal, I think a number of elements from you draft can be reused
here...e.g.: using DHCP to give the Authenticator's address to the client
when that is inside the network or extending RAs to indicate EAP support,
fit right in the ICMP solution...I am not as convinced about your IKE
arguments yet though :-)

> 
> Fra: George Tsirtsis <[email-masked]>
> Dato: 2002/01/05 Sat AM 01:49:48 CET
> Til: "Pana (E-mail)" <[email-masked]>
> Tema: 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
>

---

From: "Wang, Cliff" <[email-masked]>
Date: Tue, 8 Jan 2002 18:39:38 -0000

Most of the times, the RADIUS server is stand-alone. NAS would serve as the
RADIUS client.
However, this doesn't prevent the NAS from using some local authentication
mechanism in certain setups, such as using the local user authentication
store in the box. This is needed when the box is used to support a small
group of users, and without the overburden of running a separate
authentication server. 

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Tuesday, January 08, 2002 11:55 AM
To: George Tsirtsis; 'Carl Williams'; Pana (E-mail)
Subject: Re: EAP over ICMP 

George,

Re. reusing RA/RS, one could look at it as a hack, or as a way to save
bandwidth on the radio connection by reusing an existing message.

I agree with your comment about requiring
5-6 messages, this must be accommodated.
But does broadening out the container
to an as yet undefined ICMP message
help here? It seems you still need to define
how that transaction will occur, and I don't
believe you are proposing that it be done
over ICMP are you?

With respect to having an arbitrary server
do the authentication, I actually think this
is less important than your point about
making sure the EAP transaction can be
accommodated. The router can backend
into a server, and I would expect that
it would do that with something like
a Radius server anyway. Is anybody
on the list familiar enough with current
practice to comment whether current
NAS products typically combine router function
and Radius, or are they typically separated?

        jak

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

> James,
>
> I understand but then it looks like a hack to me...You use a messages
with
> specific functions (RS/RA) just because they are their...If the PANA 
> protocol required messages exactly at the same instance with RS/RAs
then
> maybe it would have been possible but this is not the case. One EAP
session
> may require 5-6 messages back and forth...using RS/RAs to carry these 
> messages maybe be slightly convenient but it also kind of ugly and a
bit of
> a hack.
>
> Also, and this is more important, SNARD can not deal with the
authenticator
> being anything other than the Access Router since a server in the
network
> can not receive RS or send RAs.
>
> I discussed this with Alper in SLC. I actually liked SNARD initially
due to
> its simplicity and I was happy to see someone suggesting something
concrete
> rather than having discussions in the air; Still I quickly identified
its
> limitations and I think Alper understood although he also reserved the
right
> to disagree  again later :-)
>
> I hope you guys see it too and we can move on. EAP over ICMP has the 
> simplicity and efficiency of SNARD since it is also based on ICMP but
it
> does not depend on other ICMP messages and can run between the end
node and
> an authenticator in the AR or behind it.
>
> Regards
> George
> P.S: BTW, Carl, I actually never advocated ND for PANA in the e-mail
you
> attached on an earlier message of yours was attempting to argue about
where
> different work belonged in the IETF (ND work in IPv6 WG, new transport
for
> authentication in PANA WG). In fact I was supporting the idea of PANA
being
> implemented with DHCP messages (I presented this in the BURP BOF)
until I
> realized very similar limitations with that of SNARD...
>
> From: James Kempf [mailto:[email-masked]]
> Sent: Monday, January 07, 2002 7:27 PM
> To: George Tsirtsis; 'Carl Williams'; Pana (E-mail)
> 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
>
>
> > 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...
> > From: Carl Williams [mailto:[email-masked]]
> > Sent: Saturday, January 05, 2002 1:08 AM
> > To: George Tsirtsis; Pana (E-mail)
> > 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
> ----------------------------------------------------------------------
> -
> > >
> > >
> > > 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
tha
> n
> > >    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: "Wang, Cliff" <[email-masked]>
Date: Tue, 8 Jan 2002 18:47:15 -0000

I agree to the comment that router discovery is disabled by practice due to
its security risk. For example, Cisco has its own proprietary discovery
protocol (CDP), but they suggest turning it off if you do care about
security in their security documentation, especially for those boxes at the
network perimeter.

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Tuesday, January 08, 2002 12:38 PM
To: James Kempf; George Tsirtsis; 'Carl Williams'; Pana (E-mail)
Subject: Re: EAP over ICMP 

> and Radius, or are they typically separated?

A NAS usually has very limited router funcionality
compared to a "real router" and does not implement
Radius Server funcionalities (it usually has a Radius Client/Proxy).

As a real-world comment (I already said this on the
meeting), ICMP router discovery comes disabled by
default on every single router/NAS that I know of.
Some knew router vendors actually do not even
implement it. It is considered a security leak. All
router "discovery" on backbones are done trough manual configuration. 

Actually some protocols like OSPF have their own
"discovery" based on well-known multicast addresses.

Moreover, windows (desktop) does not implement ICMP
router discovery. If we are trying to "investigate
protocols already established or that we might think
are going to be ubiquitous", ICMP RA is not the way to
go.

my 2 cents.

thanks,

Reinaldo

> <[email-masked]>; "'Carl Williams'" 
> <[email-masked]>; "Pana (E-mail)" 
> > time by sending out another RA. Sending
> > an RS can be used by the host to challenge the
> router.
> >
> >             jak
> >
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 9 Jan 2002 12:34:36 -0500

-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]]
Sent: Wednesday, January 09, 2002 4:56 PM
To: George Tsirtsis
Cc: 'James Kempf'; 'Carl Williams'; Pana (E-mail)
Subject: Re: EAP over ICMP 

...
> George, I think first you need to define how EAPoverICMP can deal with an
> authenticator behind the ARs. What would be the destination address of the
> request packets, and a discovery protocol might be needed for that.
>
>
> GT> No I do not have do that really. One thing I do not like in the IETF
> these days is that we tend to confuse protocols with system designs. I
wrote
> a simple draft on how one can do EAP over ICMP. Address assignment is
> irrelevant. Now, one can go and develop a DHCP option that provides the
end
> system with the address of the Authenticator or create another extension
to
> RAs that advertises the same address. This has nothing to do with the EAP
> over ICMP protocol and yet is clearly feasible and if you twist my arm a
bit
> more I will add a paragraph in the draft to mention it.

George, without that bit, I'd say your "protocol" is incomplete. If you
leave
that part out, your protocol will have a dependency on some other protocol
that doesn't even exist.

GT> OK, I will add something in the next version
George

---

From: Paal Engelstad <[email-masked]>
Date: Tue, 15 Jan 2002 20:13:35 +0100

George,

This response comes late because I have been on vacation and I am trying to catch up. Thanks for your clarifications. However:

- What I question is the necessity of locating an authenticator at the AR at all. Would not some equipment on the AR (e.g. a firewall) to enforce access control be sufficient, and one would not need to locate an authenticator at each AR. I have recently sent another e-mail to the list (in response to Erik's message) to clarify this issue.

- I still don't agree to your arguments of using ICMP in favor of f.ex. UDP. We are talking about sending a few authentication messages back an forth. Wouldn't the extra overhead of using UDP be only an extremely small fraction of the users total bandwidth usage?

- I agree you have to choose a security mechanism that is fit for your environment. My main point is that EAP-over-ICMP will be more prone to attacks in a multiaccess IP subnet than its PPP EAP counterpart. For example, by snooping a challenge and a MD5 response (assuming the use of a user password), wouldn't it be pretty simple to launch a brute-force dictionary attack, and find the password? If so, EAP mehtods can not be ported directly to be used over ICMP without compromising the security.

- I hope that in your next version of your draft you will replace "It is clear that..." and "it is most likely that" with a few sentences of explanation that would be helpful for people at my own level. For example, for me it is not obvious that the PAA most likely will be located in front of the firewall. Why? I can think of many security arguments against it.

Paal

> Dato: 2002/01/07 Mon AM 11:28:49 CET
> Til: "'Paal Engelstad'" <[email-masked]>,  [email-masked]
> Tema: RE: EAP over ICMP
> 
> Hi Paal,
> 
> comments inline...
>

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 15 Jan 2002 15:22:23 -0500

-----Original Message-----
From: Paal Engelstad [mailto:[email-masked]]
Sent: Tuesday, January 15, 2002 2:14 PM
To: George Tsirtsis; [email-masked]
Subject: Re: RE: EAP over ICMP

George,

This response comes late because I have been on vacation and I am trying to
catch up. Thanks for your clarifications. However:

- What I question is the necessity of locating an authenticator at the AR at
all. Would not some equipment on the AR (e.g. a firewall) to enforce access
control be sufficient, and one would not need to locate an authenticator at
each AR. I have recently sent another e-mail to the list (in response to
Erik's message) to clarify this issue.

GT> Paal, clearly you do not understand one of the main drivers behind PANA.
This has been discussed at length since the first BURP BOF so I encourage
you to read through the archives.

- I still don't agree to your arguments of using ICMP in favor of f.ex. UDP.
We are talking about sending a few authentication messages back an forth.
Wouldn't the extra overhead of using UDP be only an extremely small fraction
of the users total bandwidth usage?

GT> Only true if you think of the PAA as being in the network rather than
the AR. In the AR case and when PANA is used for basic internet access ICMP
is much more efficient than UDP and that is very important given potential
application of PANA in wireless. This is clearly a subject that this WG will
have to discuss in detail.

- I agree you have to choose a security mechanism that is fit for your
environment. My main point is that EAP-over-ICMP will be more prone to
attacks in a multiaccess IP subnet than its PPP EAP counterpart. For
example, by snooping a challenge and a MD5 response (assuming the use of a
user password), wouldn't it be pretty simple to launch a brute-force
dictionary attack, and find the password? If so, EAP mehtods can not be
ported directly to be used over ICMP without compromising the security.

GT> I hear you and I have yet to check these things in detail....in my to do
list I guess.

- I hope that in your next version of your draft you will replace "It is
clear that..." and "it is most likely that" with a few sentences of
explanation that would be helpful for people at my own level. For example,
for me it is not obvious that the PAA most likely will be located in front
of the firewall. Why? I can think of many security arguments against it.

GT> Paal, since this is a *personal* rather than a WG contribution I can say
whatever I want :-) You are also free to explain what your security
arguments are against what I am proposing. Through that process we may all
learn something.

Regards
George

---

From: Paal Engelstad <[email-masked]>
Date: Wed, 16 Jan 2002 16:44:58 +0100

> 
> Fra: Erik Nordmark <[email-masked]>
> Dato: 2002/01/16 Wed AM 11:30:59 CET
> Til: Paal Engelstad <[email-masked]>
> CC: George Tsirtsis <[email-masked]>,  [email-masked]
> Tema: RE: RE: EAP over ICMP
> 
> 
> > A configurable firewall will probably be a favorite target of DoS attacks.
> > As a countermeasure it would be easy to configure the FW so that all
> > configuration messages (e.g. of a MIDCOM protocol) must be received on the
> > interface behind (inside) the firewall. Messages received from the outside
> > would simply be discarded. 
> > 
> > If the PAA, on the other hand, is located outside the firewall, the FW may
> > have to process a lot of bogus configuration messages (e.g. performing
> > packet authenticating) before discarding them. 
> 
> I don;t understand what the "outside" is in this case.
> The AR+PAA+FW are sitting between a bunch of visiting client devices
> (which might be potentially hostile) and the Internet (which might might
> contain some hostile nodes).
> Thus there are two "outsides" as far as I can tell.
> 

Good point.

Paal

>   Erik
> 
> > Placing PAA behind the FW will naturally require that PAA is designed to be
> > sufficently secure since it requires a hole in the FW to allow reachablity
> > from un-authenticated hosts. However, accommodating this security is in the
> > hands of PANA WG. We will not depend on work from other WGs.
> > 
> > Paal
> 
> 
>

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 16 Jan 2002 14:03:29 -0500

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 1:51 PM
To: George Tsirtsis; Patil Basavaraj (NET/Dallas);
[email-masked]
Subject: Re: RE: EAP over ICMP

> PANA MUST NOT assume any specific AAA mechanism. System integrators
should
> be able to interface PANA to Radius, Diameter, local file or whatever
else
> they want.
> Makes sense?

I just want to make sure the WG isn't coming up with an alternate
network AAA
architecture to that done by the AAA WG. They spent a lot of work and
many years on it, and I think it is pretty good.

If somebody wants to run PANA to a local file, that is their business.
But
for AAA within the network, and in particular between different
administrative
domains, I believe PANA must endorse the AAA architecture.

            jak

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Wed, 16 Jan 2002 14:58:05 -0600

> But  for AAA within the network, and in particular between different
> administrative domains, I believe PANA must endorse the AAA
architecture.

PANA complements the AAA architecture. It is what we believe is the
missing piece of the puzzle. i.e a protocol that extends AAA (meaning
authentication, authorization and accounting and NOT necessarily
implying
RADIUS or Diameter) over the last hop.

>             jak

-Basavaraj

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Wed, 16 Jan 2002 14:55:00 -0600

> network AAA architecture to that done by the AAA WG. They spent 
> a lot of work and many years on it, and I think it is pretty good.
>

PANA is not in any way trying to define AAA architecture. 

-Basavaraj

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 16 Jan 2002 18:08:08 -0500

Exactly :-)

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 5:50 PM
To: James Kempf
Cc: George Tsirtsis; 'Erik Nordmark'; [email-masked]
Subject: Re: RE: EAP over ICMP

> > GT> I agree with this. Furthermore, PAA should be thought of as a
> *function*
> > rather than as a *box*. So the PAA can be implemented in the AR, in
> the
> > site's FW or somewhere in between. The result of a PANA session is
> likely to
> > be some configuration that will allow access to what was just
> authenticated.
> > This "configuration" is likely to be installed in the AR or in the FW.
> The
> > details of how this is done are out of scope of this discussion and
> the
> > reasons are:
> 
> Now I am really confused. I thought this was all the responsiblity of
> AAA.
> I thought PANA was supposed to only be between the host and the
> AAA server. Do we really need two ways of doing AAA??

I *think* I know what George is talking about so let me try to
explain what I think.

Case 1: PAA colocated with the AR. The AR implements access control
enforcement.

The AAA protocol might return some filter attributes in addition the PAA 
function might want to specify some filtering (e.g. IP addresses or IP
address
prefixes). This results in some filter rules being added to the AR.

Case 2: PAA separate from the AR. The AR implements access control
enforcement.
 Just like above AAA plus potential PAA filter rules are merged by the PAA.
But those need to be downloaded to the AR for enforcement.
So some protocol (out of scope for PANA - could be SNMP or whatever) needs
to be used for this "download".

Makes sense?

  Erik

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 17 Jan 2002 10:05:28 -0500

-----Original Message-----
From: Paal Engelstad [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 7:55 PM
To: James Kempf; Erik Nordmark
Cc: George Tsirtsis; 'Erik Nordmark'; [email-masked]
Subject: Re: RE: EAP over ICMP

George,

This mail was clarifying. I wonder if I can bring the conclusion a tiny step
forward without stepping out a cliff:

What if we say that the access control function on the AR in terms of
address filtering equals a functional firewall. 

GT> Paal, the point of this thread is that *access control* is OUT OF SCOPE!
Yes, it MAY happen as consequence of PANA but with mechanisms that we are
not going to deal with. 

Is that a conceptual model that could be agreed upon? 

GT> I think your model is "reasonable" but since access control is out of
scope I do not see why this WG needs to formally agree on it... Am I missing
something?

George

> 
> Fra: "James Kempf" <[email-masked]>
> Dato: 2002/01/17 Thu AM 12:10:16 CET
> Til: "Erik Nordmark" <[email-masked]>
> CC: "George Tsirtsis" <[email-masked]>, 
>    "'Erik Nordmark'" <[email-masked]>, 
> Tema: Re: RE: EAP over ICMP
> 
> OK, now I understand. Thanx.
> 
>             jak
> 
> 
>

---

From: Paal Engelstad <[email-masked]>
Date: Thu, 17 Jan 2002 18:15:41 +0100

> Dato: 2002/01/17 Thu AM 10:04:52 CET
> CC: James Kempf <[email-masked]>, 
>    Erik Nordmark <[email-masked]>, 
>    George Tsirtsis <[email-masked]>,  [email-masked]
> I don't think the term "firewall" is well defined and it is definitely
> evolving over time.
> Used to be that stateless packet filters were firewalls.
> Then came stateful. Then inspecting email attachments for viruses.
> Is URL filtering for kids accessing the 'net considered to be a firewall
> function today?
> 

Good point!

> I *think* the Radius/Diameter attributes for carrying filters is of the
> simplest kind - be able to specify IP addresses, protocols, and port numbers
> and nothing more. (but I haven't checked the specs)
> 
> Is it such "5-tuple filtering" that you think we should agree upon?
> 

Exactly.

Paal

---

From: Paal Engelstad <[email-masked]>
Date: Thu, 17 Jan 2002 18:45:55 +0100

> Dato: 2002/01/17 Thu PM 04:05:28 CET
> Til: "'Paal Engelstad'" <[email-masked]>
> CC: [email-masked]

Agreed. I think everyone agrees that access control is out of scope. 

However, the scenarios in the scenario document are very useful to establish a common understanding of the problem we are working with. The filtering function (that some might call a "firewall") is only related to the scenarios. As soon as someone points out that the PANA protocol needs a "hook" to do this or that, a common understanding on scenarios can be useful to address the suggestion or to easily choke the discussion off (in case it is out of scope.)

Furthermore, I think the separation of filtering functionality and authentication goes directly to the core of the discussion on where the PAA(s) should be located (e.g. "on the AR", "on the access network", "both" or "does not matter"). This discussion falls within the WG charter.

Moreover, a common understanding could be beneficial to understand the scenarios presented in other Internet-Drafts, too (including your own EAP-over-ICMP draft where you argue for different scenarios in terms of "firewalls" and locations of PAAs). 

> GT> I think your model is "reasonable" 

Good!

> but since access control is out of
> scope I do not see why this WG needs to formally agree on it... 

Agreed. I am satisfied with the fact that we have established a common understanding between outselves for the time being.

> Am I missing

Not at all.

Paal