Subject: Re: [Pana] PANA key derivation key

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 05 Jul 2004 12:49:28 -0400

How about the following changes?

[1] In section 2,

change:

"
   AAA-Key:

      A key derived by the EAP peer and EAP server and transported to
      the authenticator [I-D.ietf-eap-keying].
"

to:

"
   AAA-Key:

      A key derived by the EAP peer and EAP server and transported to
      the authenticator [I-D.ietf-eap-keying].  In this document, when
      there are two such keys, namely AAA-Key1 and AAA-Key2, are
      generated as a result of running two EAP authentications in a
      single round of PANA authentication, the AAA-Key from
      which other keys are derived refers to the concatenation of
      AAA-Key1 and AAA-Key2.
"

[2] In section 4.1.5 of draft-ietf-pana-pana-04.txt change:

"
   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-SHY1.

   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:

"
   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.  The length of AAA-Key MUST be N
   bits or longer.  See Section 4.1.6 for the detailed usage of the
   PANA_MAC_KEY.
"

[3] In section 4.3,

change:

"
   When separate NAP and ISP authentications are performed and the
   lower-layer is insecure, the two EAP methods MUST be capable of
   deriving keys.  In this case, if the first EAP authentication is
   successful, the PANA-FirstAuth-End-Request and
   PANA-FirstAuth-End-Answer messages as well as PANA-Auth-Request and
   PANA-Auth-Answer messages in the second EAP authentication MUST be
   protected with the key derived from the AAA-Key for the first EAP
   authentication. The PANA-Bind-Request and PANA-Bind-Answer messages
   and all subsequent PANA messages MUST be protected either with the
   AAA-Key for the first EAP authentication if the first EAP
   authentication succeeds and the second EAP authentication fails, or
   with the AAA-Key for the second EAP authentication if the first EAP
   authentication fails and the second EAP authentication succeeds, or
   with the compound key derived from the two AAA-Keys, one for the
   first EAP authentication and the other from the second EAP
   authentication, if both the first and second EAP authentications
   succeed (see Section 4.1.5 for how the compound key is derived).
"

to:

"
   When separate NAP and ISP authentications are performed and the
   lower-layer is insecure, the two EAP methods MUST be capable of
   deriving keys.  In this case, if the first EAP authentication is
   successful, the PANA-FirstAuth-End-Request and
   PANA-FirstAuth-End-Answer messages as well as PANA-Auth-Request and
   PANA-Auth-Answer messages in the second EAP authentication MUST be
   protected with the key derived from the AAA-Key for the first EAP
   authentication.  The PANA-Bind-Request and PANA-Bind-Answer
   messages and all subsequent PANA messages MUST be protected either
   with the AAA-Key for the first EAP authentication if the first EAP
   authentication succeeds and the second EAP authentication fails, or
   with the AAA-Key for the second EAP authentication if the first EAP
   authentication fails and the second EAP authentication succeeds, or
   with the compound AAA-Key derived from the two AAA-Keys, one for the
   first EAP authentication and the other from the second EAP
   authentication, if both the first and second EAP authentications
   succeed.
"

[4] In section 4.9,

change:

"
   As part of the context transfer, an intermediate AAA-Key material is
   provided by the previous PAA to the current PAA.

      AAA-Key-int = The first N bits of
                    HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)

   In case there are two AAA-Keys generated from a NAP-ISP
   authentication, the AAA-Key-int computation is:

      AAA-Key-int = The first N bits of
                    HMAC-SHA1(AAA-Key1 | AAA-Key2, DiameterIdentity |
                              Session-ID)
"

to:

"
   As part of the context transfer, an intermediate AAA-Key material is
   provided by the previous PAA to the current PAA.

      AAA-Key-int = The first N bits of
                    HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)
"

Regards,

Yoshihiro Ohba

On Tue, Jun 29, 2004 at 03:56:22PM -0700, Alper Yegin wrote:
> 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
> > 
> > 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
> 
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 12 Jul 2004 14:31:37 -0700

Hi Yoshi,

>       which other keys are derived refers to the concatenation of

I think it is better if we didn't get into the specific AAA-keys and
computations in the terminology. I think we should keep the terminology
section as is, and later discuss how AAA-Key may be set to
AAA-Key1|AAA-Key2.

in
Session-ID)
in
in
|
EAP
in
Session-ID)
>    bits or longer.  See Section 4.1.6 for the detailed usage of the

I think this is where we should discuss how two AAA-Keys are combined. 
For example:

	When two AAA-Keys (AAA-Key1 and AAA-Key2) are generated as a 
      result of double EAP authentication (see Section 4.3), the 
      compound AAA-Key can be computed as follows:

	AAA-Key = AAA-Key1 | AAA-Key2

      The PANA_MAC_Key is used to integrity protect PANA messages.

      where the value of N depends on the integrity protection algorithm
      in use, i.e., N=160 for HMAC-SHA1.  The length of AAA-Key MUST be
N
      bits or longer.  See Section 4.1.6 for the detailed usage of the
      PANA_MAC_KEY.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 12 Jul 2004 19:28:50 -0400

This looks good.

Yoshihiro Ohba

On Mon, Jul 12, 2004 at 02:31:37PM -0700, Alper Yegin wrote:
> When
> The