Subject: Re: RE: Solutions ...

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

Yoshihiro Ohba and Erik Nordmark,

Allow me to shoot from the hip, and propose something from the top of my head. Hopefully it will trigger some more discussion around this topic:

My current abstraction of the authentication process is that it contains 3 elements:

- User-ID or NAIs
- Secrets or Keys 
- Network access context (i.e. IP-addresses of the client, IP-addresses of AR(s), possibly link-layer addresses, etc.)

I think that the RFC 3041 concern is a part of the Context. I also think that the SNARD concerns that attempts to secure ND should be incorporated into the same context.

1) A requirement could be that the PANA protocol must allow authentication of both user-ID AND context information simultaneously. 

Thus, when the user authenticates the PAA, it can simultanously check the validity of IP-addresses (of itself and of the ARs). Likewise, the PAA can check the validity of the AR addresses etc. of the user, when authenticating the user. 

Hopefully such a requirement may address the ND-threats in an approprate way, and simultanously accommodate the SNARD solution, without excluding other solutions.

2) An additional requirement would be that re-authentication should allow for the context information to be changed (The formulation should of course be less vague.)

Thus, if a mobile node wants to change its IP-address (for the purpose of identity hiding) this is already accommodated in the PANA protocol. Moreover, if the node roams to a new AR or wants to gain access to an additional new AR, it may simply add its address to the context information and try to get this context authenticated by the PAA.

I think that explicitely authenticating the context as part of the PANA protocol, and potentially allowing a wide variety of different types of contexts, the PANA protocol could be extensible to new scenarios that will evolve along with the development of IPv6. 

In the framework of EAP, the contexts could perhaps be represented as a string, and presented to the other party as some form of a MD5-challenge. For example:
 
"Uid=user@realm user-ip={a:b::c, a:b::d} AR-ip={a:b::e} unique-challenge=123456789" 

Just some ideas...

Paal 

> 
> Fra: Yoshihiro Ohba <[email-masked]>
> Dato: 2002/01/16 Wed PM 03:35:17 CET
> Til: Erik Nordmark <[email-masked]>
> CC: Yoshihiro Ohba <[email-masked]>, 
>    Paal Engelstad <[email-masked]>,  [email-masked]
> Tema: Re: RE: Solutions ...
> 
> On Wed, Jan 16, 2002 at 11:04:49AM +0100, Erik Nordmark wrote:
> > 
> > > I did not include this in the usage scenarios draft because 
> > > it would relate to the notion of "authorization token" which is 
> > > now out of the scope of PANA.
> > 
> > I think we had some discussion about tokens where I said I didn't understand
> > how they could provide any security hence doesn't make sense.
> > 
> > But this doesn't mean that the identity of the "session" (or whatever term
> > makes more sense) need to be tied to an IP address.
> > 
> > For instance, it could be tied to an IP address prefix (like a /64 for a PAN)
> > or it could be tied to a e.g. a symmetric crypto key that is created 
> > during the initial authentication and later used for local reauthentication.
> > (The above are just example of mechanisms - I'm not pushing for
> > any particular mechanism.)
> 
> If I understand your point correctly, authorization token per packet
> is out of scope, but authorization/anonymity token per "session" could
> be in scope, right?
> 
> > 
> >   Erik
> > 
> > 
> 
> Yoshihiro Ohba
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 16 Jan 2002 12:05:25 -0800

Paal,

I think PAA should "authenticate" client credentials (identifier,
authenticator),
but "create a binding for" network access context. I don't think you can or
you have to authenticate that context.

As for creating this binding, in the case PAA is on the first hop router,
it could create a binding beween the client and the link-layer address
of the client. I was thinking PANA could even do this implicitely by
looking at the source link-layer address of the PANA request, but
it seems like you are suggesting carrying this context explicitely
(as a payload)?

Either case, next PANA request can set the new binding.. (which
we can consider a re-authentication)

alper

----- Original Message -----
From: "Paal Engelstad" <[email-masked]>
To: "Yoshihiro Ohba" <[email-masked]>; "Erik Nordmark"
<[email-masked]>
Cc: "Yoshihiro Ohba" <[email-masked]>; "Paal Engelstad"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, January 16, 2002 8:40 AM
Subject: Re: RE: Solutions ...

> Allow me to shoot from the hip, and propose something from the top of my
head. Hopefully it will trigger some more discussion around this topic:
> - Network access context (i.e. IP-addresses of the client, IP-addresses of
AR(s), possibly link-layer addresses, etc.)
>
> I think that the RFC 3041 concern is a part of the Context. I also think
that the SNARD concerns that attempts to secure ND should be incorporated
into the same context.
>
> 1) A requirement could be that the PANA protocol must allow authentication
of both user-ID AND context information simultaneously.
>
> Thus, when the user authenticates the PAA, it can simultanously check the
validity of IP-addresses (of itself and of the ARs). Likewise, the PAA can
check the validity of the AR addresses etc. of the user, when authenticating
the user.
>
> Hopefully such a requirement may address the ND-threats in an approprate
way, and simultanously accommodate the SNARD solution, without excluding
other solutions.
>
> 2) An additional requirement would be that re-authentication should allow
for the context information to be changed (The formulation should of course
be less vague.)
>
> Thus, if a mobile node wants to change its IP-address (for the purpose of
identity hiding) this is already accommodated in the PANA protocol.
Moreover, if the node roams to a new AR or wants to gain access to an
additional new AR, it may simply add its address to the context information
and try to get this context authenticated by the PAA.
>
> I think that explicitely authenticating the context as part of the PANA
protocol, and potentially allowing a wide variety of different types of
contexts, the PANA protocol could be extensible to new scenarios that will
evolve along with the development of IPv6.
>
> In the framework of EAP, the contexts could perhaps be represented as a
string, and presented to the other party as some form of a MD5-challenge.