Subject: RE: RE: EAP over ICMP

From: Paal Engelstad <[email-masked]>
Date: Tue, 15 Jan 2002 22:27:57 +0100

George,

Comments inline.

> 
> Fra: George Tsirtsis <[email-masked]>
> Dato: 2002/01/15 Tue PM 09:22:23 CET
> Til: 'Paal Engelstad' <[email-masked]>,  [email-masked]
> Tema: RE: RE: EAP over ICMP
> 
> 
> 
> -----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.
> 

Unfortunately, I joined the list at a later stage. I hoped that the arguments were so clear that you easily would be willing to repeat them. I guess I have to scan through the archives, or wait for the requirement document, which I expect will summarize the arguments. 

> 
> - 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.
> 

Yes, when I have clarified the first issue, it will naturally be easier to discuss this.

> 
> - 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 :-) 

Don't get too personal :-)

> You are also free to explain what your security
> arguments are against what I am proposing. Through that process we may all
> learn something.
> 

Hopefully at least I will learn something:

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. 

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

> Regards
> George
> 
> > 
> > Fra: George Tsirtsis <[email-masked]>
> > 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...
> > 
> > -----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: Erik Nordmark <[email-masked]>
Date: Wed, 16 Jan 2002 11:30:59 +0100 (CET)

> 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.

  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