Subject: RE: [Pana] PANA and lower layer ciphering

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 15 Jun 2005 16:41:43 -0700

> Although PaC-EP master keys are cryptographically independent 
> of each other and of PANA keys, PaC-EP master keys are 
> cryptographically dependent on the AAA-Key because they are 
> derived from AAA-Key.
>

[Joe] The draft does not state that the PaC-EP master key is
cryptographically independent of the PANA keys.  The best way to achieve
this is to specify the derivation in this draft so that the keys are
independent.  

> > This would help eliminate
> > the possibility that a AAA-key is used directly by a lower layer 
> > protocol or that a lower-layer key is derived that is not 
> > cryptographically independent from the PANA keys.  This should be 
> > specified in the PANA protocol spec rather than trying to 
> coordinate 
> > it in multiple lower layer specs.
> 
> I believe that key derivation algorithms for PaC-EP master 
> keys cannot be independent of lower layers, because lower 
> layer parameters such as authenticator identifier would need 
> to be bound to the master keys.
> Thus, I think what we can describe in the PANA protocol spec 
> is something like: "The PaC-EP master keys MUST be drived 
> from the AAA-Key, bound to appropriate lower layer parameters 
> and cryptographycally independent of each other".
> 

[Joe] Why must they be bound to lower layer parameters?  This should be
done in the lower layer instead of creating dependencies in PANA on the
lower layer.  PANA exports a key and the lower layer is free to use it
how it wishes, including deriving additional keys that have specific
binding to lower layer parameters.

> > 
> > If negotiation is necessary then why is the 
> Protection-Capability AVP 
> > only indicated by the PAA, shouldn't the PaC be able to 
> indicate this 
> > as well?
> 
> The current PANA design on this is that ciphering layer is 
> not negotiable.  This is because if we allow multiple choices 
> on ciphering layers, then it might end up with a situation 
> where some PaC uses L3 ciphering while others use L2 
> ciphering in the same access network, which might open up a 
> security hole.
> 

[Joe] Interesting, can you elaborate on this problem?  

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Jun 2005 08:05:13 +0300

Payload protection keys are indeed derived from the AAA-Key
just as in 802.11, so we can't have independence from AAA-Key.
Independence between the different derived keys is necessary,
however.

The interesting bit about PANA is that there are multiple ways
of achieving payload protection. Only one has been fully defined,
and uses IPsec and IKE. The formula for the keys to use here
is

   IKE Pre-shared Key = HMAC-SHA-1 (AAA-Key, "IKE-preshared key" |
                           Session ID | Key-ID | EP-address)
   
I don't recall if there's anything said about the formula for other
usage, e.g., L2 protection. Ideally, all of them should use a different
key. Maybe that's your question Joe that this should be specified.
Just as an example:

  Pre_Protection key_<Mech> = HMAC-SHA-1 (AAA-Key, "<Mech>" |
                                                                        
       Session ID | Key-ID)
  Protection_Key_IKE = HMAC_SHA-1 (Pre_Protection_key_IKE, EP-IP-Address)
  Protection_Key_11i = HMAC_SHA-1 (Pre_Protection_key_11i, EP-MAC-Address)

Or something to that effect.

--Jari

---

From: Alper Yegin <[email-masked]>
Date: Thu, 16 Jun 2005 10:18:35 -0700

The current pana-pana spec provides a guideline in the form of:

   When link-layer or network-layer ciphering [I-D.ietf-pana-ipsec] is
   enabled as a result of successful PANA authentication, a separate
   PaC-EP master key is generated based on the *** AAA-Key, session
   identifier, key identifier, and EP device identifier ***.

And it leaves the exact computation to complimentary specs. For example,
pana-ipsec following this guideline states:

I think doing more than what is in the pana-pana may be over specifying.

Alper

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Jun 2005 21:50:33 +0300

>I think doing more than what is in the pana-pana may be over specifying.
Well.. the formula may be overspecifying. But you may want
to consider specifying a requirement for the PaC-EP master
key, e.g., MUST NOT be possible to derive AAA-Key from it,
MUST NOT be able to derive another PaC-EP master key
for other EP or technology from a given PaC-EP master key.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 16 Jun 2005 13:16:28 -0400

> this is to specify the derivation in this draft so that the keys are

I agree.

> binding to lower layer parameters.

At least the PaC-EP master key needs to be associated with the
identity of the consumers (i.e., the PaC and EP) so that the PaC and
EP can make sure that which master key is used for which peer.

> [Joe] Interesting, can you elaborate on this problem?  

Assume that there are two EPs on a single IP link where one EP is an
WLAN AP using IEEE 802.11i and another EP is an access router using
IPsec.  Note that there is at least one open-access AP on the link to
make this work.  Then an unauthorized attacker may access the link via
open-access AP to launch L3 or higher layer attacks on the legitimate
PaCs that are using 802.11i.

Yoshihiro Ohba