Subject: RE: PANA and cryptographic keys

From: <[email-masked]>
Date: Thu, 5 Dec 2002 09:42:57 +0200

Alper and Mohan,

One small comment. In PANA we are interested in preventing session hijacking. Thus, for example the VPN connection(s) to some other network(s) could protect the packets. But in this case the session hijacking is still possible since, the EP can't verify the packet's origin in L3 level. So, if L2 doesn't provide session hijacking protection (IP spoofing), PANA should provide it.

One possibility is to use IPSec per-packet authentication between PaC and EP/PAA after proper key derivation (for example with TLS or with EAP "key derivation").

- Dan

> -----Original Message-----
> From: ext Alper E. YEGIN [mailto:[email-masked]]
> Sent: 05 December, 2002 04:48
> To: Mohan Parthasarathy; Pana (E-mail)
> Subject: Re: PANA and cryptographic keys
> 
> 
> Mohan,
> 
> > Ok, to summarize, PANA does not care what EAP method is used. If it
> > does not derive keys, some one else can steal your service. 
> PANA does
> > not
> > enforce/care what EAP methods will be used.
> 
> Yes. And someone might want to write a document that identifies what
> methods are appropriate in what kind of environments. But note that
> this would not be specific to PANA, it'd be also applicable to
> other encapsulations of EAP, such as PPP and 802.1x. This document
> would be outside the scope of PANA.
> 
> > 
> > When you are pushing the keys as part of fliters to EP, what does it
> > mean to EP ? Does it mean that the EP should be expecting some sort
> > of key exchange shortly from the PaC ? Or the PaC is free to ignore 
> > setting up SA with the EP and setup a secure channel (VPN) back to
> > home network ? I prefer the latter. 
> 
> These all depend on the access network architecture. It might be using
> L2 (e.g., WEP) or L3 (e.g., IKE and IPsec) mechanisms for 
> that purpose. 
> PaC might need to have profiles to know what exactly is being used in 
> a particular network, etc.
> 
> 
> > Also, there might be more
> > information
> > needed along with the keys e.g. identity of the PaC that 
> will establish
> > the SA etc.  The key information is slightly different from 
> the other
> > filter information pushed in the sense that it needs lot of 
> additional
> > bits for it to be useful. We can safely classify all this 
> as outside the
> > scope of PANA. But pushing some information to EP and not 
> knowing what
> > to do with it does not seem very useful.
> 
> I'd encourage anyone to write a draft that outlines how these 
> keys and 
> associated information can be used in various networks. This could be
> a guideline document, not inventing new protocols and mechanisms, but 
> instead pointing out how existing ones can be used for this purpose.
> I think this would be useful for general discussions, though this
> problem space is outside the scope of PANA protocol. 
> 
> alper
> 
> > 
> > -mohan
> >  
> > 
> > 
> > > -----Original Message-----
> > > From: Alper E. YEGIN [mailto:[email-masked]] 
> > > Sent: Tuesday, December 03, 2002 12:23 PM
> > > To: Mohan Parthasarathy; Pana (E-mail)
> > > Subject: Re: PANA and cryptographic keys
> > > 
> > > 
> > > Mohan,
> > > 
> > > > > Also, depending on the environment, access control by using
> > > > > filters on the source mac address or IP address might not be 
> > > > > sufficient. For example public access wireless networks. In 
> > > > > this case, using 
> > > > > cryptographic methods for per-packet authentication is needed 
> > > > > to prevent service theft by free-loaders. Now the keys become 
> > > > > part of the filtering 
> > > > > information just like mac and IP addresses are. They 
> > > would be part 
> > > > > of the provisioning information passed from PAA to EPs. 
> > > EP would have 
> > > > > to know how to use them once received.
> > > > > 
> > > > What if I use a method that does not derive keys ? Then, 
> > > service theft 
> > > > becomes very easy.
> > > 
> > > That's right. Therefore right authentication method must be 
> > > used depending on the environment. If service theft is an 
> > > issue, client and network better use use an authentication 
> > > method that 
> > > derives/distributes keys. 
> > > 
> > > > Are we saying that PANA will develop solution that
> > > > will enable per-packet protection or not ? It is still not 
> > > clear to me 
> > > > from the above.
> > > 
> > > PANA carries EAP, EAP supports various authentication 
> methods some 
> > > of which does key distribution/derivation (which is needed 
> > > for per-packet protection). So, PANA enables per-packet 
> > > protection in this indirect way. Current understanding is 
> > > that, PANA doesn't have to do anything other than to carry 
> > > EAP to accomplish this.
> > > 
> > > > 
> > > > > In either case, key distribution and derivation are outside
> > > > > the scope of PANA. Respective EAP methods take care of these 
> > > > 
> > > > What do you mean by key distrbution here ? In your above 
> > > description, 
> > > > you just distributed keys from PAA to EP.
> > > 
> > > But that protocol is not called PANA, which runs between 
> PaC and PAA. 
> > > That protocol is either COPS or SNMP or DIAMETER or 
> something else...
> > > 
> > > > I think you meant something
> > > > like setting up an SA between PaC and EP.
> > > > 
> > > > > tasks for the
> > > > > authentication end-points, i.e, PaC and the 
> > > authentication server. 
> > > > > If the authentication server is separate from the PAA, 
> > > then the AAA 
> > > > > protocol running between two should take care of key 
> > > > > distribution from 
> > > > > authentication server to PAA. And finally, if these keys are 
> > > > > needed by the EP for per-packet protection, they should be 
> > > > > delivered from PAA to EP, using the yet-to-be-identified 
> > > > > protocol (which is not PANA).
> > > > > 
> > > > I am not disagreeing with anything here. But what do we 
> > > expect out of 
> > > > the PANA solution ? Should it be an enabler of per-packet 
> > > protection 
> > > > to avoid service thefts i.e should the solution (e.g. EAP 
> > > method) used 
> > > > derive keys or not ?
> > > 
> > > Please see above and let us know if it helped clarifying 
> the issue.
> > > 
> > > alper
> > > 
> > > 
> > > 
> > 
> 
>

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 5 Dec 2002 15:31:33 -0800

Hi Dan,

> One small comment. In PANA we are interested in preventing session
hijacking. Thus, for example the VPN connection(s) to some other network(s)
could protect the packets. But in this case the session hijacking is still
possible since, the EP can't verify the packet's origin in L3 level.

This is a good point. So, this suggests EP as the VPN end-point, if a
VPN-like
solution is used for per-packet protection.

> So, if L2 doesn't provide session hijacking protection (IP spoofing), PANA
should provide it.

So, what exactly is it that PANA should provide here?

> One possibility is to use IPSec per-packet authentication between PaC and
EP/PAA after proper key derivation (for example with TLS or with EAP "key
derivation").

Yes, but PANA protocol should not include this mechanism/protocol.
PANA indirectly enables this by carrying EAP, though. And this is where
we are trying to limit the scope.

alper