Subject: RE: Solutions ...

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 15 Jan 2002 13:35:20 +0100

One way of finding out that a MN is 'disconnected'
(on a wireless link this may not be so obvious)
is re-authentication. 

Hesham

  > -----Original Message-----
  > From: George Tsirtsis [mailto:[email-masked]]
  > Sent: Tuesday, January 15, 2002 12:10 AM
  > To: 'Reinaldo Penno'
  > Cc: Erik Nordmark; [email-masked]
  > Subject: RE: Solutions ...
  > 
  > 
  > All,
  > 
  > Erik will correct me if I wrong but I do not think he talked about
  > "de-authentication" but about "sensing that a node 
  > disconnected from the
  > network".
  > 
  > I think network "sensing" of any type should be outside the 
  > scope of the
  > PANA WG. In fact this is a much needed work that the IETF 
  > needs to take up
  > at some point...and something tells me that it will happen 
  > soon and comes
  > under the general area of "link layer triggers". And yes I 
  > know you can
  > devise "liveness" protocols to do that at the IP layer but 
  > I really think
  > PANA should not go there.
  > 
  > De-authentication, is also kind of interesting but I think 
  > not very useful.
  > What I mean is that the networks will have to cope with end 
  > nodes suddenly
  > disconnected in wired and even more in wireless networks; 
  > no way to go
  > around that. Still, if people think that de-authentication 
  > is useful as an
  > optional feature then fine, but again I do not see it as 
  > work for PANA but
  > rather for the authentication mechanisms that will be carried over
  > PANA...Again trying to follow the idea that PANA is an 
  > *authentication
  > transport mechanism* rather than an *authentication 
  > protocol* by itself.
  > 
  > Regards
  > George
  > 
  > -----Original Message-----
  > From: Reinaldo Penno [mailto:[email-masked]]
  > Sent: Monday, January 14, 2002 8:46 PM
  > To: John Angelmo; Alper Yegin
  > Cc: Erik Nordmark; [email-masked]
  > Subject: Re: Solutions ...
  > 
  > 
  > I think Erik had a good point.
  > 
  > We should think about the deauthentication also,
  > otherwise we will end up with different solutions from
  > different companies (as pointed out) and/or a "new"
  > protocol to sync state between PPP/DHCP/Radius and
  > PANA to know when a user has disconnected.
  > 
  > regards,
  > 
  > -Reinaldo
  > 
  > --- John Angelmo <[email-masked]> wrote:
  > > 
  > > 
  > > Alper Yegin wrote:
  > > > 
  > > > Hi Erik,
  > > > 
  > > > > Oh - and for those that can't stay away from
  > > thinking about solutions
  > > > > even though it is a bit too early:
  > > > > As far as I understand the solutions that are
  > > being discussed
  > > > > they don't talk about a way to detect when the
  > > client has been
  > > > disconnected,
  > > > 
  > > > I understand that for a network access
  > > architecture, we definitely need a
  > > > way
  > > > to detect client has disconnected. So that the
  > > network can cancel the access
  > > > granted to the disconnected client (for security,
  > > resource management
  > > > reasons..).
  > > > 
  > > > But, doesn't this go beyond "carrying
  > > authentication" that PANA is about?
  > > > I'm under the impression that client sending a
  > > message like "authenticate me
  > > > for
  > > > network access" is in the scope, but "stop the
  > > network access for me" is not
  > > > so (?)
  > > > 
  > > > Or, maybe we can see it like this:
  > > > 
  > > > - the initial PANA exchange can also be seen as
  > > both "authenticate me"
  > > >   and "provide me network access".
  > > > - another message can say "authenticate me and
  > > terminate my network
  > > >   access".
  > > > 
  > > > Is what you are suggesting this second type of
  > > message?
  > > > 
  > > > > dealing with multiple access routers on the
  > > link, etc.
  > > > > (Of course, I could be wrong.)
  > > > 
  > > > Regards,
  > > > 
  > > > alper
  > > 
  > > If PANA handles both authentication and
  > > "deauthentication" we are
  > > handeling one solution/protocol but if PANA only
  > > handles authentication
  > > then we might end up with one solution from
  > > Microsoft one from Cisco one
  > > for linux and so on and then we have to invent the
  > > wheel again with
  > > "PANA 2.0"
  > > 
  > > I'm just a newbie here so I don't have the
  > > experience that you all got.
  > > 
  > > Regards,
  > > 
  > > John
  > > 
  > 
  > 
  > __________________________________________________
  > Do You Yahoo!?
  > Send FREE video emails in Yahoo! Mail!
  > http://promo.yahoo.com/videomail/
  >

---

From: "Forsberg Dan (NRC/Helsinki)" <[email-masked]>
Date: Wed, 16 Jan 2002 10:49:51 +0200

> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 15. tammikuuta 2002 22:57
> To: George Tsirtsis
> On Tue, Jan 15, 2002 at 03:43:39PM -0500, George Tsirtsis wrote:
> > 
> > 
> > From: Erik Nordmark [mailto:[email-masked]]
> > Sent: Tuesday, January 15, 2002 1:50 PM
> > To: George Tsirtsis
> > Cc: 'Reinaldo Penno'; Erik Nordmark; [email-masked]
> > I'm not a "sensing" kind of guy :-)
> > so I suspect I actually used a term like "detecting".
> > 
> > 
> > > I think network "sensing" of any type should be outside 
> the scope of the
> > > at some point...and something tells me that it will 
> happen soon and comes
> > > under the general area of "link layer triggers". And yes 
> I know you can
> > > devise "liveness" protocols to do that at the IP layer 
> but I really think
> > You mean that TCP should have never been define to have a 
> FIN flag? :-)
> > 
> > GT> Maybe I do mean that, but I do not claim it to be in 
> scope for PANA
> > :---)
> > GT> Seriously, maybe I was too negative here...someone said 
> that periodic
> > re-authentication provides a way of detecting if someone is 
> still there and
> > wants the service, which is fair enough and appropriate for 
> PANA. More
> > accurate "detection" :-) may still need link layer triggers 
> and that is
> > still out of scope IMO.
> 
> When a user wants to actively disconnect from the network by pusing 
> "disconnect" button, no link layer trigger is needed.

That's right. I think there should be an explicit disconnect message. 

And if there are link layer triggers, the implementation can use the
link layer trigger as a trigger to send the disconnect message (if the
link layer connectivity is still available - depends on the trigger
etc.).

- Dan Forsberg

> Yoshihiro Ohba

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 16 Jan 2002 09:31:34 -0500

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 4:57 AM
To: Paal Engelstad
Cc: Erik Nordmark; [email-masked]
Subject: Re: RE: Solutions ...

> (BTW: Isn't identity hiding also relevant with regard to using NAIs? A
> visited domain does not need to know the exact identity of the user; it
> needs to know the user realm and an opaque user id that the authentication
> authorithy in the home-realm is able to recognize/decrypt.)

This is a good issue to bring up.

Today with roaming between ISPs using PPP I think the NAI is
a fixed username and the realm, but the NAI format can be used to 
carry something else that the home realm understands.

GT> I think the need for a globally unique identifier is clear and accepted.
The identifier will also have to be flexible in that different systems may
need different types of IDs. The soon to come out draft requirements will
reflect that.

I don't know if PANA will push for the need to specify something like this
thus it would be good to have a discussion whether or not it should be
part of the PANA requirements.

GT> PANA should be able to carry an ID that can be used for roaming. Of
course roaming itself is handled by AAA and it is out of scope but the ID
requirements are reasonably straight forward.

George

---

From: Tomas Goldbeck-Löwe (ERA)<[email-masked]>
Date: Wed, 16 Jan 2002 18:04:13 +0100

> need different types of IDs. The soon to come out draft 
I agree on that we need a globally unique identifier.
As I understand it, the question is if the visited domain should be able to read the username part of the NAI (username@realm).
IMO, I think it should be possible not to reveal your username in the visited domain.

> requirements are reasonably straight forward.
Agree.

	--> Tomas

---

From: Paal Engelstad <[email-masked]>
Date: Thu, 17 Jan 2002 0:54:48 +0100

Message from Alper forwarded to the list:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Paal,

> > Paal,
> >
> > I think PAA should "authenticate" client credentials (identifier,
> > authenticator),
>
> Could you be a little more specific about what you mean by "authenticator"
in this context? Exactly what information is included?

Something that proves that whoever provided this ID owns it. It can be a
password,
a message digest using a secret, etc..

>
> > but "create a binding for" network access context. I don't think you can
or
> > you have to authenticate that context.
> >
>
> Well, although it seems to be outside the PANA charter, I thought the
requirement draft still may want to
> address security threats related to ND, as outlined in
draft-kempf-netaccess-threats-00.txt. It might also

I think they are outside the scope of this WG. PANA doesn't have to solve
them, but the protocol
chosen might end up helping solve them. For example SNARD has some text for
this problem.

> want to address identity hiding in terms of RFC 3041, and other access
specific things. In that case the requirement draft would need to express
the requirements in general terms. I thought that "Network Access Context"
could be a suitable concept. No matter if the context is implicit (as part
of the "carriers" packet/message header) or if it is explicitely expressed
in a payload - this belongs to solution space and is outside the scope of
the requirement draft anyway. It was only an idea. Discard it if you like.
>
> > 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)?
>
> I am only suggesting NOT to rule this option out.

I'm not particularly against it. I'm not sure...

>
> I am not convinced which solution would be the best, simply because I have
little idea how the final PANA protocol will be. Carrying it implicitly will
probably be more lightweight and might fit well with ICMP as a carrier, but
it may not be flexible enough to meet all PANA scenarios. Carrying it in the
payload might be more suitable to the generic EAP approach. I don't know...
>
> For example, - from the top of my head - I think George mentioned in his
draft that a PANA request could be bridged over a series of links before it
eventually hits the AR. I am not sure how your implicit proposal to look at
the source link-layer address of the PANA request will be in this scenario.

Shouldn't the receiving end see the actual link-layer address of the sender
even if the packet
has traversed several bridges?

>
> This discussion won't be meaningful before actual PANA proposals are on
the table, anyway.

alper

>
> Paal
>
> > 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
> > > 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

---

From: Paal Engelstad <[email-masked]>
Date: Thu, 17 Jan 2002 1:31:03 +0100

Alper,

Agreed. I think that is an appropriate attitude at this point in time.

Paal

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 17 Jan 2002 11:13:15 +0100

> 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

=> So the trick here is how to do access enforcement based
on that token? I guess this would at least ensure that 
the attacker can not fool the router(s)/firewall performing
the access enforcement. 
But he might be able to fool other nodes on link. This 
IMHO can only be solved if we create secure logical 
channels between the nodes on link and the AR's. 

Of course we lose the shared media advantages for 
better security. 

Am I off on a tangent ? 

Hesham

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

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 18 Jan 2002 16:04:00 +0100

George
  > 
  > 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?

=> Sure, but if that is the case, then there must be 
a third entity (trusted by PAA) that can identify the user and 
authenticate him so that the PAA will grant access. 
How else would the user be granted access ?

If you agree with that, then the third entity can generate
the SA between the user and PAA, to protect any further
messages. 
I'm not saying this should all be done in PANA, but 
we need to know how PANA will be used to be able 
to make the right assumptions / requirements 
for the final solution.  

Hesham

---

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

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Friday, January 18, 2002 10:04 AM
To: 'George Tsirtsis'
Cc: [email-masked]
Subject: RE: Solutions ...

George

GT> A 3rd party or even itself it does not matter...but yes.

GT> OK, to that I agree. My point was that *initial* PANA session can not be
secured...however, re-authentication could be secured I guess. I think the
requirements will cover the idea of use of local security associations as a
result of initial PANA session...in which case re-authentication can make
use of it.

Thanks
George

Hesham

---

From: Paal Engelstad <[email-masked]>
Date: Fri, 18 Jan 2002 19:30:41 +0100

Basavaraj,

Comments inline.

> 
> Fra: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
> Dato: 2002/01/18 Fri PM 05:46:54 CET
> Til: "'Erik Nordmark'" <[email-masked]>, 
>    "Pekka Nikander" <[email-masked]>
> CC: <[email-masked]>
> Tema: RE: Solutions ...
> 
> 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. 

Agreed. But I think the PANA protocol MAY assure that some parameters included in the IP/transport header are valid (e.g. that the IP-address is not spoofed.)

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

"Enable" is a loose term. I think we should go as far as defining or recommending the "format" of the credentials that are initially exchanged between a host and a PAA. If that is clearly defined, the AAA-people are allowed to easily intergrate the PANA scheme into their protocols 

> 
> >
> >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 think Alper's comment on the list could be applicable. He said something like:

Solving general security threats related to ND in general, will not be a requirement. It MAY however be beneficial if the PANA protocol would be a tool to address such threats later.

Paal

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

[email-masked] 
[email-masked]

---

From: Paal Engelstad <[email-masked]>
Date: Fri, 18 Jan 2002 20:09:11 +0100

George, Hesham

First to George: I think Erik meant that 1) and 3) are different things:

1) relates to PANA-specific security threats, while 

3) relates to general ND shortcomings that MAY comprise the security of the PANA protocol as well.

> secured...however, re-authentication could be secured I guess. 

Looking at the *initial* (first) PANA request/response alone, you are right.

However, the result of the intial PANA request/response could be that keys/secrets are established between host and PAA in a secure manner. When this SA is estableshed, the host and PAA can use the SA to authenticate in a subsequent request/response that the *initial* PANA request/response was correct.

The same is done in IKE - however in a different way. Note that I do not push the idea of using IKE - you have already convinced me that IKE probably won't be part of PANA's solution space. (In fact, I am about to re-submit a revised version of the EAPoIP-draft where the IKE-part is removed, and where the generic discovery mechanism is moved to a separate draft.)

On the contrary, validating the unsecured *inital* PANA request/response exchange can easily be accommodated within the EAP-framework. An authenication session can consist of a series of authentication methods in terms of request/response exchanges. The session finally ends in a Success or Failure message.

Thus, if the first *initial* EAP Request/Reply exchange allows the host and PAA to exchange credentials (possibly by support of a back-end AAA infrastructure), a subsequent Request/Response type can be performed to validate (i.e. authenticate) the "context information" (i.e. all relevant information that needs to be secured in the *inital* EAP Request/Reply exchange.

All we have to do is to define 

1) an EAP R/R type and method that allows host and PAA to exchange credentials

2) an EAP R/R type that allows host and PAA to validate each others "access context" information.

Thus, first-time (uni-directional) autentication requires 2RTT beween host and PAA (and 1 RTT between PAA and AAAh if applicable).

Subsequent (uni-directional) re-authentication requires only 1RTT between host and PAA, and existing PPP EAP methods can be reused for this purpose.

I have been pushing this idea on the list for a long time, because I think it represent a very simple solution to a rather complex problem. - At least if we assume EAP to be part of the solution.

What do you any of you guys think? 
Have I missed a point or two?

Paal

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 21 Jan 2002 06:07:37 -0500

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Monday, January 21, 2002 5:42 AM
To: Pekka Nikander
Cc: Erik Nordmark; George Tsirtsis; [email-masked]
Subject: Re: Solutions ...

> 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.
> 
> 
> > If they do then it seems like PANA would need to create a secure channel
> > (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).

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.

GT> This is the approach I had in mind. Maybe something like the following
would be satisfactory.
"The authentication methods used on top of PANA transport must take into
account and be appropriate for the individual deployment scenario. For
example, if PANA is deployed over a shared medium or over a multi-hop IP
network, the authentication protocol used should not assume only two nodes
on the link". This in combination with the requirement for PANA to support
multiple authentication protocols and be extensible should give us enough
flexibility to do the right thing.

GT> I would also like to repeat that PPP based authentication suffers from
the same issues. People run PPP over Ethernet in which case the
point-to-point nature of PPP is just an illusion and does not offer any
security.

George

---

From: <[email-masked]>
Date: Tue, 22 Jan 2002 14:51:48 -0600

Comments inline:

James Kempf [[email-masked]] wrote:
>Erik/Raj,
>> 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?
>>
>
>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.
>

While I agree with your observation that there is a larger problem
that needs to be looked at, I do not believe that PANA would be the
right WG to tackle it (at least not now). 
PANA has a clear charter and a good chance of delivering a protocol
that is useful for both IPv4 and IPv6. Adding new work items or
expaning the charter at this early stage of the WG may be detrimental
to making any progress.

>            jak
-Basavaraj

---

From: Paal Engelstad <[email-masked]>
Date: Wed, 23 Jan 2002 0:44:05 +0100

> 
> Fra: "Alper Yegin" <[email-masked]>
> Dato: 2002/01/22 Tue PM 10:56:54 CET
> Til: "George Tsirtsis" <[email-masked]>, 
>    "'James Kempf'" <[email-masked]>
> Tema: Re: Solutions ...
> > I think there are two very different issues here.
> >
> > 1. Authentication transport protocol which can optionally accommodate
> > session key agreement
> >
> > 2. Secured Neighbor Discovery.
> >
> >
> > I think (1) is well defined in PANA so far and we have a chance to do
> > something useful given the mix of people involved in this work. If you are
> > thinking along the same lines forget the rest of the e-mail.
> >
> > (2) is a much harder problem that IPv6 WG has avoided for some time now
> > despite its expertise and I do not see what PANA WG will be able to offer
> > here, unless all people from IPv6 WG get involved. IMO IPv6 WG should take
> > up this work or a different WG should be created to look at this
> > fundamentally hard problem if there is enough real interest.  PANA has a
> > well defined problem that is IP version independent and should not get
> > confused by more adventurous tasks.
> 
> 
> The problem of securing network access in not limited to
> neighbor discovery. It involves securing router discovery, and
> neighbor discovery in IPv6, and address resolution in IPv4. The
> problem is not even specific to IPv6, same applies to IPv4.
> 
> I agree this is a harder problem to solve, and currently
> outside the scope of PANA. And I think we should keep
> it separate. PANA is not meant to solve all the issues
> related to "secure network access." It deals with solving the
> must-fix problem of authenticating the clients. Once we
> have the PANA, we can see it may provide sufficient hooks
> (key distribution, etc.) to help solving this other problem as well.

Agree. But I still think it might be worthwhile to mention this point in the requirement document, e.g. in terms of _extensibility_ of the PANA protocol.

(PANA can be extensible in different ways:
1) Assuming EAP, I think several mechanism can be added at a later stage, using the extensiblity of EAP (i.e. defining specific Request/Response types to solve other problems, such as key distribution)
2) PANA may need some mechanisms to secure the protocol itself - including securing the network access environment (e.g. that IP-addresses are not spoofed). These mechanisms should perhaps also be extensible (e.g to also include other network access parameters at a later stage).

Paal

> Once current charter is completed, depending on the solution
> at hand and what else is needed we might either not need anything
> else, re-charter the WG or create a new WG. i think this is better
> than expanding the charter at this point.
> 
> my 0.02 cents.
> 
> alper
> 
> 
> 
> 
> 
> 
> 
> >
> >
> > My 2 (now obsolete) drachmas
> >
> > George
> >
> >
> > From: James Kempf [mailto:[email-masked]]
> > Sent: Tuesday, January 22, 2002 6:45 PM
> > To: Erik Nordmark; Patil Basavaraj (NET/Dallas)
> > Cc: 'Erik Nordmark'; Pekka Nikander; [email-masked]

---

From: Paal Engelstad <[email-masked]>
Date: Wed, 23 Jan 2002 0:57:19 +0100

I agree. IMO one of the critcal factors of success is to determine how few security requirements are sufficient to make the PANA protcol secure enough. Some ways to make things simpler include:

- No re-keying requirements.

- No negotiation: The PANA protocol comes in versions. All auth and/or encr methods are mandated by the PANA protocol.

- Focus on Integrity protection. E.g. only privacy protection of protocol elements that must be hidden not to compromise the integrity of the PANA protocol.

- Let identity hiding be out of scope of PANA (although hooks may be useful at a later stage). Identity hiding can be accommodated by other protocols specified later.

- ...etc...

Paal
 
> 
> Fra: Pekka Nikander <[email-masked]>
> Dato: 2002/01/21 Mon PM 12:11:16 CET
> CC: "Patil Basavaraj (NET/Dallas)" <[email-masked]>,
> Erik Nordmark wrote:
> >>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...
> >>
> > 
> > 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.)
> 
> 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: <[email-masked]>
Date: Thu, 24 Jan 2002 18:03:50 -0600

Maybe this discussion would make more sense in the IPv6 WG :)
than PANA.

-Basavaraj

> 
> Hesham,
> 
> 
> >I think if we're going to the level of protecting 
> > ND, then a safe and easy (relatively) way to do it
> > is to run the ND communication between hosts and 
> > routers over a secure channel. As for host to host
> > we would probably have to do so via the AR. 
> > 
> 
> If by 'secure channel' you mean that Layer
> 2 is as secure as a wired network, I don't think running 
> ND over a secure channel will eliminate the
> threat entirely.
> 
> Consider the following scenario. A fully authenticated
> host on the secure channel suddenly decides to play
> the trickster and starts advertising itself as a router,
> and sending out RAs for the real router with
> lifetime zero. At some point, the host will get
> found out, and the user's account will be cancelled
> (perhaps even with legal action) but until
> that time, the host can do a lot of damage.
> 
> The current ND scheme basically depends
> on implicit trust between hosts and the
> routers or router on the link. In a public
> access network, even if all hosts are authenticated
> and the channel is secure, because the signaling isn't
> authenticated, there is still the potential for damage.
> 
>             jak
> 
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 25 Jan 2002 14:28:57 +0100

James, 

  > ND over a secure channel will eliminate the

=> I actually meant a secure L3 channel. No a physical
channel. This is only in referece to ND messages.

Cheers,
Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 25 Jan 2002 14:37:02 +0100

> > I can think of scenarios where after authentication
  > > a host is issued a key for protecting RS and 
  > > authenticating RAs. However, for NS and NA this 
  > > is a different problem. 
  > > So it may be doable without too much trouble.
  > > 
  > But that would make broadcast and multicast on the local link
  > very efficient; the host would unicast to the router and the router

=> I guess you meant 'inefficient' ?

  > would need to send out N copies over every secure channel 
  > to every other host.
  > 

=> Sure, I was aiming at the simplest PANA case. 
I think we could make it more efficient if we 
do the following:

1. Host Authenticates to PAA
2. Keys between PAA and Host are generated.
   This can be done by third party (if the host
   is 'visiting') or by PAA if there was pre-established
   trust. 

3. The same key in 2) or a different one, can 
   be used for host - router communication. 

4. A new key (probably generated by PAA or AR)
   can be used for host to host communication. 

Step 4), if performed, would make things more 
efficient for host to host. 
Of course in step 4) the same key must be given
to hosts on link. 

I haven't thought about it in a lot of detail
but comments are welcome !

Hesham

---

From: Paal Engelstad <[email-masked]>
Date: Fri, 25 Jan 2002 20:43:42 +0100

Hesham,

Comments inline,

> 
> Fra: "Hesham Soliman (ERA)" <[email-masked]>
> Dato: 2002/01/25 Fri PM 02:37:02 CET
> Til: "'Erik Nordmark'" <[email-masked]>
> CC: "'George Tsirtsis'" <[email-masked]>, 
>    "'James Kempf'"
> 	 <[email-masked]>, 
>    "[email-masked]'"
> 	 <[email-masked]>
> Tema: RE: Solutions ...
> 

It is difficult to authenticate without a key. Therefore, if I understand you correctly, 1. is the actual PANA protocol. It can be realized as follows:

1.a) Host discovers PAA

1.b) Host establishes session key with PAA (possibly using a TTP and an AAA infrastructure)

1.c) 
 - PAA (re-)authenticates host anytime, and
 - host (re-)authenticates PAA anytime.

As for 2., 3., and 4. below, these proposals seem to be posed in order to secure Neighbor Discovery, which is out of scope, and should be addressed by another WG (e.g. IPv6 WG). If this other WG can reuse the PANA protocol to secure ND - well, fine!

Let us keep ND security out of the discussion on this list, and focus on the PANA protocol first!

Paal

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 28 Jan 2002 13:59:27 +0100

> It is difficult to authenticate without a key. Therefore, 
  > if I understand you correctly, 1. is the actual PANA 
  > protocol. It can be realized as follows:
  > 
  > 1.a) Host discovers PAA
  > 

=> Yes.

  > 
  > As for 2., 3., and 4. below, these proposals seem to be 
  > posed in order to secure Neighbor Discovery, which is out 
  > of scope, and should be addressed by another WG (e.g. IPv6 

=> It is not an IPv6-only issue, therefore unlikely
to be addressed in the IPv6 WG. The problem is securing
address resolution to prevent address stealing on shared
links. It just so happens to be easier to secure
ND than ARP.

  > WG). If this other WG can reuse the PANA protocol to secure 
  > ND - well, fine!

=> I wasn't proposing that this goes into PANA, although
I wouldn't be against it if it did become part of PANA's
application. I was discussing the possible ways of 
securing ND using PANA.

Hesham