Subject: RE: Solutions ...

From: George Tsirtsis <[email-masked]>
Date: Fri, 18 Jan 2002 09:18:36 -0500

Erik,

Could you clarify what is the difference between 1 and 3 below? 

I think that PANA transport does not need to "secure" anything; in fact I
think it can not possibly secure anything since by definition at the time
PANA runs the two sides do not know who each other is. i.e.: if I have a
security association that I can use to secure PANA why do I need PANA
for?...don't I already know the identity of the other end?

The authentication protocol running on top of it, however, will need to
*secure itself* and needs to be appropriate for the deployment scenario
(e.g.: some auth mechanisms maybe more appropriate for shared media than
others)

But maybe I misunderstand what you mean by 1 below....

George

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Friday, January 18, 2002 4:21 AM
To: Pekka Nikander
Cc: Paal Engelstad; Erik Nordmark; Yoshihiro Ohba;
[email-masked]
Subject: Re: Solutions ...

>  > If I read you correctly, you propose a mechanism to protect the
>  > users data traffic (after she has authenticated)?
> 
> I agree that it is out of the scope of this WG.  However, that
> is one of the practical problems people seem to have with the
> multiaccess link scenarios.  I just wanted to point out that
> securing a multiaccess link does not necessarily require anything
> as heavy as, for example, running AH between the client and the
> firewall.  Instead, something relatively lightweight could be
> used, and still have _good_enough_ security.  (Good enough for
> at least some purposes.)

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.

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.

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.

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.

But I could be wrong.

  Erik

Note that because

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 20 Jan 2002 22:11:58 +0100 (CET)

> Could you clarify what is the difference between 1 and 3 below? 

Sending a user-name and password in the clear would be an example of
not satisfying #1.

Not inventing a mechanism to authenticate and authorize router advertisements
would be an example of not satisfying #3.

> for?...don't I already know the identity of the other end?

Perhaps my wording was sloppy. But I expect the
to be some security requirements on the PANA protocol.
 
> (e.g.: some auth mechanisms maybe more appropriate for shared media than

I'll answer your question with some questions:
To what extend do authentication protocols assume that there is a
somewhat secure channel over which the authentication protocol runs?
For instance, does or does not CHAP or EAP method used with PPP assume
that there can be only one client at the end of a PPP link?
If they do then it seems like PANA would need to create a secure channel
(without any authentication) before running the authentication protocol.

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 21 Jan 2002 09:28:33 +0200

Erik,

> that there can be only one client at the end of a PPP link?

I haven't rechecked all the RFCs, but my understanding is that CHAP
does assume that there is only one reachable client.  Anyhow, it is
a simple challenge-response protocol that does not create any shared
secret between the client and server.  In the EAP case the situation
is more complex, basically depending on what you run on the top of EAP.
If you run EAP MD5-CHALLENGE, the situation is similar to CHAP.  The
same applies to EAP S/KEY.  On the other hand, EAP TLS seems to protect
even in multiaccess case, but I haven't check.

> (without any authentication) before running the authentication protocol.

This sounds like a good requirement.  However, that leads very quickly
to a protocol considerably similar to Son-of-IKE.  That is, to create
a secure channel you basically need to run unauthenticated Diffie-Helman.
But that creates potential CPU-exhausting DoS attacks.  Thus, to plug
those you need to first perform a cookie-exchange (a reachability
check).  And voila, you are close to Son-of-IKE designs.  Or alternatively
designs similar to MIPv6 Cryptographically Protected Addresses (CGA).

--Pekka Nikander

---

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

> designs similar to MIPv6 Cryptographically Protected Addresses (CGA).

PIC might be another possible thing to reuse here.

But the WG doesn't have to take this path. Another possible approach would
be to require that the EAP methods (or auth methods in general for those who'd 
like to keep the door open for non-EAP solutions) used with PANA must not
assume that there is a single client on the link.
 
   Erik