Subject: RE: Solutions ...

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Fri, 18 Jan 2002 10:46:54 -0600

Erik Nordmark [[email-masked]] wrote:

>In terms of the scope there are some clear things and some less clear
things
>1. Should PANA secure the PANA protocol itself?
>   Yes, obviously.

But this does not mean that PANA will be responsible for securing the
transport protocol used for carrying the authentication
parameters. 

>2. Should PANA secure the data traffic?
>   No, presumably end-to-end security is needed to provide integrity
and/or
>   confidentiality. And in some cases L2 security might be deemed
>good enough.

L2 security (ciphering) may only provide security over the last hop
and not necessarily e2e.
However e2e security may be secured by other means (VPNs, IPsec, SSL
etc.). The scope of securing the traffic is definitely outside the
scope of PANA.
But can or should PANA be considered as an enabler for securing the
traffic over the last hop? What I mean here is that PANA could enable
exchange of keys (securely) which could be used to setup a Local
Security Association (LSA beteween client and AP or AR) and any
traffic sent over this LSA would be at least secured over the last
hop. 

>
>3. Should PANA prevent security threats on a multi-access link?
>   (draft-kempf-ipng-netaccess-threats-00.txt)
>   I have so far assumed that this could be a separate thing that can
be done
>   later. I think my co-author would argue we need to solve them at the
same
>   time as PANA.

I agree that we can consider this at a later date, i.e when we are
ready to close the WG or recharter.

>
>4. Should PANA prevent specific threats on multi-access links
>   such as the "stealing of service" that your hashing scheme
addresses?
>   I don't know. Does it make sense to do this when router
advertisement
>   spoofing can make the attacker receive the legit packets (and their
hashes)
>   and replace the packet content (while using the hash value) with its
>   own packet?
>
>I'm not saying that #3 and #4 aren't important (and the above list is
not
>likely to be complete) - I'm just concerned that trying to solve those
>problems at the same time as trying to figure out the model,
requirements,
>and PANA protocol is going to be too complex.
>

At this point we are trying to keep the scope of PANA relatively
simple and straightforward. A simple protocol for network access
authentication probably has a much better chance of success. So if we
can get a solution out in the next six months or less, we may see some
use for it and actual deployments. Else we will be spinning on
developing a complex protocol for the next couple of years by which
time interest as well as need would have waned.

>But I could be wrong.
>  Erik

-Basavaraj

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jan 2002 10:28:53 +0100 (CET)

> traffic sent over this LSA would be at least secured over the last

That is a good question.
I don't think there is an obvious answer.

I think 802.1X with 802.11 will be used to derive per-station keys for WEP.
Does that mean that PANA should be required to solve this type of
problem in the general case as well?
Does it imply that it is desired to do this in PANA?

   Erik

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 21 Jan 2002 11:47:15 +0200

> I think 802.1X with 802.11 will be used to derive per-station keys for WEP.

In some cases yes, in some cases no.  Actually, at least as far
as I know, the actual mechanism for doing so is either not standardized
(yet) or I just haven't found the relevant documents.  Anyway,
if you want to use 802.1x for deriving WEP keys, you have to
use TLS over EAP or such, just running EAP MD5-CHALLENGE or
EAP S/Key is not sufficient, since they do not create the required
shared secret from which you can derive WEP keys or with which you
can protect the 802.1x EAPOL KEY messages.

> Does it imply that it is desired to do this in PANA?

If we want PANA to replace 802.1x at some point of time,
then maybe yes.  At minimum, I think it would be good if
PANA _always_ creates a shared secret between the client and
PAA.  That would allow securing many things...

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jan 2002 11:49:44 +0100 (CET)

> PAA.  That would allow securing many things...

But the requirements might be different if the purpose is just to
use this for local reauthentication of the client, as opposed to
securing data traffic locally. (For instance, in the former case
there might not be a need for local rekeying - when the local key
expires just take a trip to the AAA. But in the latter case I wouldn't
be surprised if there is need for local rekeying for performance reasons.)

Thus I think the WG needs to but some stakes in the group in order to nail
down some requirements.

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 21 Jan 2002 13:11:16 +0200

Erik Nordmark wrote:

> be surprised if there is need for local rekeying for performance 

 > reasons.)

Good point.  I'd like to keep things simple, and just creating
the shared secret for reauthentication seems to be enough.  On
the other hand, if that same secret then OPTIONALLY can be used
to secure the traffic, that is another issue, and probably
should be kept outside the scope of the WG.

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jan 2002 13:54:18 +0100 (CET)

> Thus I think the WG needs to but some stakes in the group in order to nail

s/group/ground/

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Tue, 22 Jan 2002 10:45:24 -0800

Erik/Raj,

> Does it imply that it is desired to do this in PANA?

I think this is a critical problem and it will be a gating issue
about whether public access wireless service providers deploy IPv6
networks
using Neighbor Discovery and/or DHCP, or whether they deploy
using PPP or some other way of rendering the last hop to look
like a point to point link. I personally think this problem
has more urgency than the last hop authentication problem,
since there are already L2 ways of dealing with last hop
authentication, and securing signaling on the last hop
currently has no solution.  The last hop authentication protocol that
PANA is
coming up is also a natural fit for solving this problem
in general.

Currently, I see no working group in IETF where this issue is
being addressed. One choice might be IPNG, but they seem
to have such a broad charter that it might simply get lost.

Therefore, I would support examining this issue in PANA.
There was also some feeling at the IPNG meeting in SLC
that solutions for IPv4 networks should be examined
as well. So the scope of any charter item (should we
choose to add it) needs to be discussed.

            jak