Subject: RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction]

From: "Colbert, Bernard" <[email-masked]>
Date: Fri, 14 Mar 2003 10:58:27 +1000

Using an existing key derivation procedure is better for several reasons:

1. they are often implemented; and
2. they have been analysed for soundness and correctness.

As Alper points out, there some EAP methods derive keys, and other key derivation will not been done via PANA.

Key derivation also gets into key management, which is not appropriate for the PANA WG to consider or for the PANA protocol to mess with.

regards

Bernard
--
Dr Bernard Colbert				|
Telstra Research Laboratories	| Phone: +61 3 9634 4621  
7/242 Exhibition Street			| Fax: +61 3 96344544
Melbourne Vic. 3000 Australia | e-mail: [email-masked]

> -----Original Message-----
> From:	Tschofenig Hannes [SMTP:[email-masked]]
> Sent:	Thursday, 13 March 2003 11:42 pm
> To:	[email-masked]'; [email-masked]; [email-masked]; [email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction]
> 
> hi dan, 
> hi mohan. 
> 
> if we need a key derivation procedure (assuming it is not done within the
> eap wg) then i would suggest to rely on something existing (instead of
> inventing something new). i am aware of the following key derivation
> procedures: 
> 
> a) "key derivation without a hierarchy"
> 
> the key and some other parameters serve as an input to a prf. each prf
> produces one part of the derived key. the output of a prf is input to the
> next prf. every prf takes the key as input.  
> 
> this approach is for example used by KINK, by IKE, by Kerberos and by the
> secure session key generation proposal by Blumenthal [1].  
> 
> b)  "key derivation with a hierarchy"
> 
> as a difference to the above-described procedure the output of each prf is
> not directly used as part of the derived key. instead it is again input to a
> function f. this function f also uses the key as second input. furthermore
> each function f takes the input of all previously computed prfs as an input.
> 
> this approach is for example used by TLS/SSL and by PKCS #5.  
> 
> ciao
> hannes
> 
> [1]	Blumenthal, U.: "Secure Session Key Generation. Createing PRF from
> MAC Function", <draft-blumenthal-keygen-03.txt>, (work in progress), July,
> 2002. 
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 14 Mar 2003 22:00:55 +0100

hi bernard,

i fully agree with you. i would also like to avoid a separate key derivation
within pana if possible. this, however, assumes that key derivation is done
somewhere in eap. it has to be done somewhere.

ciao
hannes

> From: Colbert, Bernard [mailto:[email-masked]]
> Sent: Freitag, 14. Marz 2003 01:58
> To: [email-masked]
> Subject: RE: WG Last
> Call:draft-ietf-pana-usage-scenarios-04.txt[Correction]
>
>
> As Alper points out, there some EAP methods derive keys, and
> other key derivation will not been done via PANA.
>
> Key derivation also gets into key management, which is not
> appropriate for the PANA WG to consider or for the PANA protocol
> to mess with.
>
> regards
>
> Bernard
> --
> Dr Bernard Colbert				|
> > To:	[email-masked]'; [email-masked];
> [email-masked]; [email-masked]
> > Subject:	RE: WG Last
> Call:draft-ietf-pana-usage-scenarios-04.txt[Correction]
> >
> > hi dan,
> > hi mohan.
> >