Subject: Re: EAP over ICMP

From: Paal Engelstad <[email-masked]>
Date: Sat, 5 Jan 2002 5:50:41 +0100

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? 

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

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. 

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?

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.   

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

More comments may follow when I found your draft in the IETF I-D database. 

Thanks for your attention.

Paal

> 
> 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: "James Kempf" <[email-masked]>
Date: Mon, 7 Jan 2002 10:46:16 -0800

Paal,

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

I think we should be careful here to distinguish between what L2 should
do and what L3 should do. IMHO, securing
the last hop link should be the job of L2. Securing the end-to-end link
should be the job of L3. If someone runs
PANA on an insecure L2, then it will necessarily be the case that
certain attacks are possible. The issue is that
if the last hop L2 is insecure, there will always be a way that someone
can snoop the traffic.

Of course, this begs the question of cases like WEP, where the L2
protocol is deficient for some reason.

                jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 7 Jan 2002 16:49:44 -0500

> protocol is deficient for some reason.

Yes. One thing that makes me annoying is that we are not always able
to expect an appropriate L2 security mechanism or there may be no L2
security mechanism at all.  So, in the worst case, L3 may have to do
what we think L2 should do.

Another thing is that L2 security mechanism would cover a portion of
last hop link between the device and the first L2 attachment point
(e.g., APs or swiches) but would not cover the rest of the last hop 
link beyond the L2 attachment point.

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Mon, 7 Jan 2002 14:28:45 -0800

> link beyond the L2 attachment point.

The issue is whether EAP should be involved in setting up this or not?

Just off the top of my head, it seems like it would be a hard thing to
do, since without a secure L2 some of the IP traffic would have to
go in the clear before security could be set up. This traffic would
always be subject to various attacks.

            jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 7 Jan 2002 18:19:22 -0500

> The issue is whether EAP should be involved in setting up this or not?

Yes. IMHO, EAP should be involved but we should use only stronger EAP
mechanisms that will satisfy the upcoming requirements.  Such stronger
EAP mechanisms would work without IPsec or L2 encryption in a similar
way that SSL or TLS works without relying on lower layer security
mechanisms.  What charactericstics are required for stronger EAP
mechanisms that can be used for PANA, should be described in the
framework document.

In addition, we need to discuss whether other authentication
mechanisms as well as EAP should be supported or not when creating the
requirement I-D.

> always be subject to various attacks.

I don't understand this, since the similar thing would also apply to
L2.  For example, in some of the L2 authentication mechanism (i.e.,
802.1X over 802.11), the 802.1X EAP traffic would have to go in the
clear before L2 security could be set up, and this traffic would
always be subject to various attacks.  So I think 802.1X over 802.11
also should use the stronger EAP mechanisms.

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Mon, 7 Jan 2002 15:35:02 -0800

Yoshi,
> also should use the stronger EAP mechanisms.

Well, that is precisely my point. If the L2 isn't secure, I think you
will
always end up having exposure at the very beginning. So I don't
see how it would be possible to set up IP securely if
the L2 doesn't provide security in the first place (note that I
am talking about wireless here, wired networks can depend
on physical security measures to limit unwarrented access,
to a certain extent).

        jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 7 Jan 2002 19:36:57 -0500

Jim,

> on physical security measures to limit unwarrented access,

The L3 security is able to be set up without relying on L2/L1 security
in a similar way that L2 security is set up without relying on L1
security.  

On the other hand, I can also say that the L3 security setup could be
simplified if the L2 security has already been set up.  
Does this what you mean?

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Mon, 7 Jan 2002 17:12:36 -0800

Yoshi,

> simplified if the L2 security has already been set up.

Not quite.

The issue I'm trying to get at is the following. Suppose I have
a radio connection and the initial traffic from the mobile
is going out entirely unencrypted. This allows someone
in the parking lot to snoop the traffic. Now, there may
be a certain level of L3 security that you can attain
in this case, but the attacker in the parking lot is
still able to find out quite a bit about the mobile
node, possibly even distrupt traffic to the
mobile node.  It is an entirely different situation from
a host connected to a wired link in a secure premesis.
While it is conceivable that a dishonest sysadmin
or someone else with access to the local patch
panel could perform the same feat as the guy
in the parking lot, it is much harder and also
far less likely (maybe not of the same
level of algorithmic complexity as factoring
large primes, but still...:).

So, to the extent that PANA happens over the
last hop link, a completely unsecured wireless
link could give an attacker a lot of information
about the authentication procedure between
a mobile node and the PANA agent (whatever
that is). It may not be enough to crack through
the L3 security, but it is far more information
than is available if the link to the end
host is wired.

                jak