Subject: PANA and cryptographic keys

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 2 Dec 2002 17:45:34 -0800

Hello,

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.

In either case, key distribution and derivation are outside the scope
of PANA. Respective EAP methods take care of these 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).

Comments?

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 5 Dec 2002 12:35:08 -0500

Does the analysis mean that protecting EAP message exchange outside
the EAP is out of the scope of PANA even optionally?  I ask this
question because most EAP methods that are strictly compliant with
RFC2284 do not have a mechanism to protect EAP Success/Failure message
which should actually be protected especially in multi-access
environments.  (PEAP is able to protect EAP Success/Failure message
within TLS, but I don't think PEAP is strictly compliant with
RFC2284.)

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 5 Dec 2002 16:04:19 -0800

> environments.

4.2.4. Secure Channel

   PANA MUST not assume a secure channel between the PaC and the PAA.
   PANA MUST be able to provide authentication especially in networks
   which are not protected against eavesdropping and spoofing. PANA
   MUST provide protection against replay attacks on both PaCs and
   PAAs.

This above requirement, in conjunction with the security threats
you mentioned above makes some level of protection during
PANA exchanges a MUST.

But, whether this protection is provided at PANA level (e.g., POTLS,
SeNAA), or within its payload EAP (e.g., encapsulating EAP over EAP-TTLS
or PEAP when needed) is an open issue for the protocol design.

[Btw, we should do something about the requirements language.
Some of the requirements will be satisfied by the designed encapsulation,
some others by the chosen payload (i.e., EAP). When we say "PANA must..",
I think we usually mean "the designed encapsulation in combination with
the chosen payload must ...". We should clarify this in the document..]

> (PEAP is able to protect EAP Success/Failure message

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 6 Dec 2002 10:19:59 -0500

OK.  Thanks for the clarification.

Yoshihiro Ohba