Subject: [Pana] Re: [issue235] Nonce AVP

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Jan 2006 10:24:53 -0500

Hannes,

Thank you for the detailed observation on nonce.
I fully agree with your observation and suggest text.

Yoshihiro Ohba

On Sun, Jan 08, 2006 at 12:58:01PM +0000, Hannes Tschofenig PANA-Issues wrote:
> 
> Hannes Tschofenig <[email-masked]> added the comment:
> 
> i would suggest that we use the same style as in ikev2. 
> 
> ikev2 (rfc 4306, section 2.10) says: 
> 
> "
>    Nonces used in IKEv2 MUST
>    be randomly chosen, MUST be at least 128 bits in size, and MUST be at
>    least half the key size of the negotiated prf. 
> "
> 
> furthermore, section 3.9 defines the nonce and says:
> "
>    The size of a Nonce MUST be between 16 and 256 octets inclusive.
> "
> 
> The text in pana (section 8.9 about the nonce avp) is therefore inline with the 
> text in ikev2. i think, however, we should add text provided by Yoshi about 
> Hugo's comment. 
> 
> regarging your statement yoshi:
> "
> On the other hand, nonce exchange occurs in PSR/PSA exchange before
> the PaC knows the actual integrity protection algorithm (the actual
> integrity protection algorithm is known to the PaC during
> authentication and authorization phase via MAC AVP carried in PFER or
> PBR message.)  So, we should also recommend the PaC to generate the
> same length of nonce as the PAA generated, in the PSR/PSA exchange
> (PAA always knows the actual integrity protection algorithm).
> "
> 
> i guess your conclusion of hugo's ipsec mailing list posting is not fully 
> correct. Hugo makes two classifications depending on whether you trust your 
> peer regarding the generation of random numbers. we have no reason not to trust 
> our peer with regard to this capability. you correctly observed that we don't 
> know the PRF function before the nonces are sent. as such, the length of the 
> nonces are determined by the best PRF available in PANA. currently, there is 
> only one PRF availabel HMAC-SHA1 with 160 bit output length. 
> 
> as such, currently we can only recommend that the length of the nonce has to be 
> either (a) 80 or (b) 160 BITS at minimum whereby (a) is applicable if you trust 
> both peers to be able to generate a good enough random number and (b) if you do 
> not trust your peer to generate a good random number. 
> 
> my suggestion therefore is that we make use of Hugo's mail (with a reference) 
> and write something along these lines:
> 
> "
> The length of the nonces are determined based on the available pseudo-random 
> functions (PRFs) and the degree of trust placed into the two PaC and the PAA to 
> compute random values. The length of the random value for the nonce is 
> determined whether
> 
> (1) The PaC and the PAA each are likely to be able to compute a random nonce 
> (according to RFC 4086).  
> 
> The length of the nonce has to be 1/2 the length of the PRF key (e.g., 80 in 
> the case of HMAC-SHA1).
> 
> (2) The PaC and the PAA each are not trusted with regard to the computation a 
> random nonce (according to RFC 4086).
> 
> The length of the nonce has to have the full length of the PRF key (e.g., 160 
> in the case of HMAC-SHA1).
> 
> Furthermore, the strongest available PRF available for PANA has to be 
> considered in this computation. Currently, only a single PRF (namely HMAC-SHA1) 
> is available and therfore the maximum output length is 160 bits). The 
> recommended maximum length of the nonce value is therfore currently 160 bits. 
> "
> ___________________________________________________
> PANA Issues <[email-masked]>
> <http://danforsberg.info:8080/pana-issues/issue235>
> ___________________________________________________
> 
> 

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