Subject: [Pana] PANA key derivation key

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 22 Jun 2004 08:39:53 -0700

To reflect Pasi's comment on how to deal with two AAA-Keys in
pana-ipsec draft and resulting discussions, here is a proposed text 
for PANA specification draft to define PANA_KD_Key.

In section 4.1.5 of draft-ietf-pana-pana-04.txt,

change:

"
      *  PANA SA attributes:

         +  AAA-Key

         +  AAA-Key Identifier

         +  PANA_MAC_Key

   The PANA_MAC_Key is used to integrity protect PANA messages.  When
   the PANA_MAC_Key is derived from a single AAA-Key, it is computed in
   the following way:

      PANA_MAC_KEY = The first N bits of
                     HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID)

   where the value of N depends on the integrity protection algorithm in
   use, i.e., N=160 for HMAC-SHA1.

   When the PANA_MAC_Key is derived from two AAA-Keys, it is computed in
   the following way:

      PANA_MAC_KEY = The first N bits of
                     HMAC_SHA1(AAA-Key1 | AAA-Key2, ISN_pac | ISN_paa |
                               Session-ID)

   where AAA-Key1 and AAA-Key2 are AAA-Keys for the first and second EAP
   authentication in a single PANA authentication phase, respectively.

   The length of AAA-Key, AAA-Key1 and AAA-Key2 MUST be N bits or
   longer.  See Section 4.1.6 for the detailed usage of the
   PANA_MAC_Key.
"

to:

      *  PANA SA attributes:

         +  AAA-Key

         +  AAA-Key Identifier

         +  PANA_MAC_Key

         +  PANA_KD_Key

   The PANA_MAC_Key is used to integrity protect PANA messages.  The
   PANA_KD_Key is used to derive keys used for bootstrapping
   per-packet ciphering between PaC and EP.  The PANA_MAC_Key has a
   length of N bits, where the value of N depends on the integrity
   protection algorithm in use, which is HMAC-SHA1 in this document
   and N would be 160 bits for this case.  The PANA_KD_Key has a
   length of 512 bits, which is equal to the typical length of a
   AAA-Key or an EAP Master Session Key [I-D.ietf-eap-keying].

   When the PANA_MAC_Key and PANA_PD_Key are derived from a single
   AAA-Key, it is computed in the following way:

      {PANA_MAC_Key | PANA_KD_Key} = 
            HMAC_SHA1+(AAA-Key, ISN_pac | ISN_paa | Session-ID)

   When PANA_MAC_Key and PANA_PD_Key are derived from two AAA-Keys, it
   is computed in the following way:

      {PANA_MAC_Key | PANA_KD_Key} = 
            HMAC_SHA1+(AAA-Key1 | AAA-Key2, ISN_pac | ISN_paa | Session-ID)

   In the above key derivation algorithms, HMAC_SHA1+ is the
   iteratively calculated version of HMAC_SHA1 algorithm by applying
   HMAC_SHA1 in the prf+ function defined in IKEv2
   [I-D:ietf-ipsec-ikev2].  AAA-Key1 and AAA-Key2 are AAA-Keys for the
   first and second EAP authentication in a single PANA authentication
   phase, respectively.  The length of AAA-Key, AAA-Key1 and AAA-Key2
   MUST be 160 bits or longer.  See Section 4.1.6 for the detailed
   usage of the PANA_MAC_Key.  See [I-D:ietf-pana-ipsec] for the usage
   of the PANA_KD_Key for bootstrapping IPsec between PaC and EP.
"

Regards,

Yoshihiro Ohba

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

---

From: Alper Yegin <[email-masked]>
Date: Tue, 29 Jun 2004 15:56:22 -0700

Yoshi,

I understand these changes are proposed to have combine AAA keys when
there are two of them. Couldn't we achieve the same by stating:

"AAA-key is set to (AAA-Key1 | AAA-Key2) when there are two EAP runs."

This could help collapse the two separate calculations into one in the
pana-pana draft. Also what pana-ipsec refers to would still be valid.
And we wouldn't need to compute a new key and use prf+ (simplification).

What do you think?

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Yoshihiro Ohba
> Sent: Tuesday, June 22, 2004 8:40 AM
> To: [email-masked]
> Subject: [Pana] PANA key derivation key
> 
>             HMAC_SHA1+(AAA-Key1 | AAA-Key2, ISN_pac | ISN_paa |
Session-
> ID)

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 15 Jul 2004 21:37:33 -0400

Hi Alper,

Your proposal looks simpler and better.  

Yoshihiro Ohba