Subject: Re: Re: Solutions ...

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

Pekka Nikander,

An interesting idea! Comments inline.

> 
> Fra: Pekka Nikander <[email-masked]>
> Dato: 2002/01/17 Thu PM 03:08:48 CET
> Til: Erik Nordmark <[email-masked]>
> CC: Yoshihiro Ohba <[email-masked]>, 
>    Paal Engelstad <[email-masked]>,  [email-masked]
> Tema: Re: Solutions ...
> 
> Erik,
> 
> This goes completely to the solution space (and therefore

More than that - I wonder if it might also be out of scope of the PANA WG. I think that security protection (just like policing/enforcement) of the users data traffic lies outside our charter. After reading the end of your mail, I realized that this is what you are trying to address (see my comments by the end of the mail). Right?

The security threats that the PANA protocol are exposed to, on the other hand, should be addressed by this WG. 

> may be inappropriate), but may be interesting anyhow.

It is an interesting idea. From the top of my head: I wonder if it could be useful for protecting the PANA protocol itself? E.g. to protect the PANA messages that performs the re-authentication. It seems like a very efficient mechanism, and it would be lightweight enough for the PANA protocol. 

> 
>  > Establishing the token in a secure manner is the easy part I think.
>  >
>  > The issue is how to, on a multiaccess link, prevent an attacker from
>  > snooping the token from the data packets and the either
>  > - using that token on the same link at the same time as the real
>  >   device
>  > - using that token on the link after the legitimate device has left
>  >   the link
>  > - taking the token to another link/AR and using it there
>  >
>  > In order to handle the above type of threats the token can't be
>  > carried in the clear in the data packets as far as I can tell.
> 
> One idea (and just an idea) that have been locally floating
> here for some time is to use some S/Key kind of mechanism
> on per-packet level.  That is, when the client authenticates
> to PAA, it gets a random number R_0.  The client then
> calculates a number of sequentive hashes, i.e.
>    H_1 = hash(R_0)
>    H_2 = hash(H_1)
>    H_i = hash(H_i-1)
>    H_N = hash(H_N-1)
> 
> After that, when sending a packet, it simply includes
> an ID, the sequence number i and the corresponding hash code
> H_i to the packet.  The firewall/whatever keeps a state
> corresponding state <ID, i, H_i>.  When it gets a packet
> with the matching ID, it checks that j in the packet is
> smaller than i in the state.  Normally j = i-1.  The
> firewall then computes hash(H_j) and checks that it
> matches with the H_i in the database, and records the
> new values.
> 
> If computing a hash for each a packet is considered to be
> too expensive, an alternative is require that the next
> hash code is sent every 10th packet or so.
> 
> One additional benefit of this scheme is that it also
> requires the client to re-authenticate whenever it is about
> to run out of the hash codes.

If I read you correctly, you propose a mechanism to protect the users data traffic (after she has authenticated)?

Paal 

> --Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 17 Jan 2002 21:38:03 +0200

Paal,

 > More than that - I wonder if it might also be out of scope of
 > the PANA WG. I think that security protection (just like
 > policing/enforcement) of the users data traffic lies outside
 > our charter. After reading the end of your mail, I realized
 > that this is what you are trying to address (see my comments
 > by the end of the mail). Right?

Right.  But if I understood Erik's question right (Erik?),
that was exactly what Erik was worried about.  But maybe
I just misread what you were talking about.

 > It is an interesting idea. From the top of my head:
 > I wonder if it could be useful for protecting the PANA
 > protocol itself? E.g. to protect the PANA messages that
 > performs the re-authentication. It seems like a very
 > efficient mechanism, and it would be lightweight enough
 > for the PANA protocol.

Well, if you have a look at S/Key over EAP (RFC1937 +
RFC2284), you see the protocol being used for (re-)authentication.
Many people on this WG seem to be planning to use EAP...
Of course, the original RFC1937 protocol is unnecessarily
complex since it was designed to authenticate humans, not
just computers...

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

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 18 Jan 2002 10:21:04 +0100 (CET)

> used, and still have _good_enough_ security.  (Good enough for

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: "Alper Yegin" <[email-masked]>
Date: Fri, 18 Jan 2002 12:23:38 -0800

Erik,

> 1. Should PANA secure the PANA protocol itself?

I think the payload of PANA will take care of this. It will
not only authenticate the sender of this message, but also
provide integrity on the rest of the PANA request packet...
(so no tampering, etc..)

>    confidentiality. And in some cases L2 security might be deemed good
enough.

I agree. As I said before, PANA might be an "enabler" for other security
mechanisms or protocols (IPsec, link-layer mechanisms).

>    later. I think my co-author would argue we need to solve them at the
same

I think we shall separate this and not include in the requirements at this
point.
But I can see a PANA protocol being used for this purpose as well. By
distributing
keys, we can secure neighbor discovery and router discovery in the future.
We discuss
this in SNARD proposal. Actually by using the router discovery as the
carrier, SNARD
is automatically securing that aspect of network access...

But for a complete "architecture", this issue needs to be addressed as well.
We cannot just
authenticate a client for a "session" and not later authenticate its
"traffic". That would
open up holes for attackers. They can impersonate an already authenticated
client.
So, for a complete "solution" what we are doing is not sufficient, but a
required first
step. But I guess that's OK, after all, PANA is a "protocol", not a
"complete solution"
or "an architecture".

> and PANA protocol is going to be too complex.

alper