Subject: Re-authentication and security requirements

From: Paal Engelstad <[email-masked]>
Date: Wed, 16 Jan 2002 22:50:43 +0100

Hi, again.

Taking up the re-authenication discussion: 

I think that PANA re-authentication will face significantly different security requirements on a multi-access link, compared to its PPP counterpart. If so is the case, the requirement document might have to address this issue:

If I understand your discussion correctly, a firewall together with re-authentication is proposed as a means to enforce network access. This works fine on a point to point link. The good guy might be charged per minute, or per megabyte, and every time the user is about to start on the new minute or megabyte, it is asked to re-authenticate.

However, on a multiaccess link, any malicious node could use an authenticated node's IP-address and get a free ride.

Is there an obvious solution to this problem that I have overlooked?

Otherwise:

In order to protect inself against per-IP-address, wouldn't the user node require some feedback from the access network, indicating its actual bandwidth usage, so that the user can stop re-authenticating itself when it realizes the theft of service? If this is require should not this be linked to the (re-)authentication protocol?

Some users would perhaps prefer a more bullet-proof protection in terms of per-packet authentication, e.g. the user communicates over IPSec AH to a security gateway located in the access domain.

If firewalls are a part of the PANA scenarios, should not also security gateways also be considered at least as an option in the scenario document?

Paal
 
> 
> Fra: Yoshihiro Ohba <[email-masked]>
> Dato: 2002/01/15 Tue AM 01:37:54 CET
> Til: James Kempf <[email-masked]>
> CC: George Tsirtsis <[email-masked]>, 
>    "'Reinaldo Penno'" <[email-masked]>, 
>    Erik Nordmark <[email-masked]>,  [email-masked]
> Tema: Re: Solutions ...
> 
> On Mon, Jan 14, 2002 at 03:19:45PM -0800, James Kempf wrote:
> > George,
> > 
> > I interpreted Erik's remarks to mean the same thing as periodic
> > reauthentication. Thus, if a MN fails a periodic
> > reauthentication, it is deauthenticated.
> 
> That is one type of de-authentication.  We can call it implicit
> logoff.
> 
> There would be another type of de-authentication, i.e., explicit
> logoff.  802.1X supports explicit logoff at L2.  I think that explicit
> logoff at L3 is also useful as we cannot assume all L2 has 
> explicit logoff, and PANA should support it as much as possible.
> 
> 
> > 
> > I agree that sensing the disappearence of a MN requires link layer
> > interaction, and would be better put under link
> > layer triggers.
> 
> 
> > 
> >             jak
> 
> Yoshihiro Ohba
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 16 Jan 2002 15:18:29 -0800

Paal,

> I think that PANA re-authentication will face significantly different
security requirements on a multi-access link, compared to its PPP
counterpart. If so is the case, the requirement document might have to
address this issue:
>
> If I understand your discussion correctly, a firewall together with
re-authentication is proposed as a means to enforce network access. This
works fine on a point to point link. The good guy might be charged per
minute, or per megabyte, and every time the user is about to start on the
new minute or megabyte, it is asked to re-authenticate.
>
> However, on a multiaccess link, any malicious node could use an
authenticated node's IP-address and get a free ride.

I think this is outside the scope of PANA. PANA should be used to
authenticate the client, but not necessarily to protect the data
traffic of authenticated/authorized clients.

But it might provide some hooks for that though. This is not
a requirement, but if PANA also creates session keys, these
keys can be fed to link-layer or IPsec for using L2 or L3
security for data traffic... This is something we mentioned
in SNARD proposal.

alper