Subject: RE: PANA and cryptographic keys

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 2 Dec 2002 19:21:30 -0800

Alper,

> At the last IETF meeting, some concerns were raised regarding 
> the relation between cryptographic keys and PANA. We should 
> be looking at different type of keys and their usage to understand 
> this issue better.
> 
> First, there is one (or more) key(s) to authenticate the 
> client to the authentication backend and vice versa. These 
> keys are part 
> of the authentication method used and they are not really visible to 
> PANA. PANA simply carries EAP regardless of the particular EAP 
> authentication method. An example of such a key is the shared 
> secret in 
> MD5-challenge method.
> 
> Secondly, depending on the authentication method used, there 
> might be derived or distributed keys. For example, with 
> EAP-TLS method. These keys might be used for integrity 
> protection of the rest of the PANA 
> exchange, or in conjunction with per-packet protection following 
> PANA authentication.
> 
> An instance of PANA authentication might be multi-phased. 
> First phase might generate such keys to be used in protecting 
> the second phase. Using PEAP or EAP-TTLS, or PoTLS or SeNAA 
> are such examples.
> 
> 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. 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.

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

-mohan

> Comments?
> alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 3 Dec 2002 12:22:40 -0800

Mohan,

> 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

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.

> 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

Please see above and let us know if it helped clarifying the issue.

alper