Subject: RE: [Pana] Some comments about PANA drafts

From: [email-masked]
Date: Tue, 22 Jun 2004 12:21:10 +0300

Yoshihiro Ohba wrote:
>
> We could modify the algorithm to derive both PANA_MAC_KEY and 
> PANA_KD_KEY as follows:
> 
> In case of single AAA-Key:
> 
>       {PANA_MAC_KEY | PANA_KD_KEY} = 
>                       The first N+M bits of
>                       HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | 
>                                 Session-ID)
> 
> In case of double AAA-Key:
> 
>       {PANA_MAC_KEY | PANA_KD_KEY} = 
>                       The first N+M bits of
>                       HMAC_SHA1(AAA-Key1 | AAA-Key2, ISN_pac |
>                                 ISN_paa | Session-ID)
> 
> PANA_MAC_KEY have a length of N bits.
> PANA_KD_KEY have a length of M bits.
> 
> N depends on the integrity protection algorithm in use for 
> PANA MAC AVP. M is 512 (equal to the typical length of 
> AAA-KEY or EAP MSK).

Looks like a reasonable approach to me. But note that HMAC-SHA1 
output is only 160 bits, so something more is needed to
generate enough bits (maybe PANA could borrow e.g. the "prf+" 
construct from IKEv2).

Best regards,
Pasi

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 22 Jun 2004 07:51:18 -0700

Hi Pasi,

> generate enough bits (maybe PANA could borrow e.g. the "prf+" 

Yes, I received the same comment personally from Mohan, and borrowing
prf+ from IKEv2 seems to be a good solution.  I will post updated text
in a separate email.

Thanks!

Yoshihiro Ohba