Subject: RE: [Ipsec] Question about PRFs with fixed size key

From: [email-masked]
Date: Thu, 27 Jan 2005 17:06:21 +0200

Tero Kivinen writes:
> [email-masked] writes:
> > Section 2.15 of draft-ietf-ipsec-ikev2-17 says that "If the
> > negotiated prf takes a fixed size key, the shared secret MUST be
> > of that fixed size".
> > 
> > I found some earlier mails about this topic (from May 2003), and
> > got the understanding that this means that if the shared secret
> > is not of that fixed size, it simply can't be used, period; and
> > there's no padding, truncation, or other processing to make it
> > the correct size.
> 
> That is my interpretation of the above text from the draft. The 
> shared secret MUST be exactly of that given size tobe able to be 
> used in the
> 
> AUTH = prf(prf(Shared-secret, "Key Pad for IKEv2"), <msg octets>)
> 
> if PRF requires fixed key size.
> 
> > Could some of the IKEv2 gurus confirm that this interpretation
> > is indeed correct?
> 
> Yes, I think it is correct.

Ok. What was confusing me a bit is the text in Section 2.13
("When the key for the prf function has fixed length, the data
provided as a key is truncated or padded with zeros as necessary
unless exceptional processing is explained following the
formula."), but I guess this text applies only to the prf+
construction? Or in other words, prf+ accepts a variable 
length key even if the underlying prf does not?

However, since in IKEv2 prf+ always uses an output of the prf
as the key, the padding/truncation happens only if the prf 
has a fixed key size that is different from the output size.
But due to the way AUTH payload is calculated, those prfs can't
be used with shared key authentication at all... so perhaps we
should require that all future prfs either accept variable
length keys or have a key size equal to the output size?
(In which case the text in 2.13 becomes unnecessary.)
 
> > (This would imply that PRF_AES128_CBC can't be used with EAP
> > authentication, since RFC 3748 says that MSK is at least 64
> > octets (512 bytes), while PRF_AES128_CBC requires a 128-bit
> > key.)
> 
> I think the section 2.16 should be modified so that says that
> if fixed length of the shared secret is required the MSK is
> truncated or padded with zeros to get the shared secret used
> in the section 2.15.
> 
> The text in the 2.15 is mostly meant that if the adminstrator
> configures the shared secret to be used with PRF_AES128_CBC in
> the IKEv2, he should also configure the shared secret with
> proper length.  As the 2.16 was added nobody realized that in
> that case the shared secret is not configured by the
> adminstrator but coming from the MSK.

Alternatively, we could just say that if you produce a 512-bit
MSK, then negotiate a prf that can handle it (i.e., has a fixed
key size of 512 bits, or accepts variable length keys).  But I'm
fine with your proposal as well.

Best regards,
Pasi

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Jan 2005 10:58:03 +0200

> length key even if the underlying prf does not?

Yes. 

> be used with shared key authentication at all... so perhaps we

True.

> (In which case the text in 2.13 becomes unnecessary.)

There is also other places where it is little bit ambiguous what do if
fixed length PRFs are used. The section 2.14 says that if we are using
PRF with fixed length key, then

1) If the length(Ni) + length(Nr) == fixed_length_key_length
   use prf(Ni | Nr, ...)
2) If the length(Ni) + length(Nr) != fixed_length_key_length
   use Ni and Nr so that half of the bits of key must come from Ni and
   half from Nr,taking first bits of each.

Now if the fixed length key length is 512 bits, and the Ni is 128
bits, annd Nr is 1024 bits, how do we generate the key for the PRF?

a) Pad Ni to 256 bits by zeros, and then take 256 bits from it, and
   concatenate it with first 256 bits of Nr?
b) Take 128 bits of Ni, and concatenate it with 384 bits from Nr?

What if Nr is also 128 bits long? Do we then concatenate Ni and Nr to
form a 256 bit long secret which is then padded with zeros?

Currently this cannot yet happen as the nonces must be >= 128 bits
long, and the only fixed size PRF is PRF_AES128_CBC and that has key
length of 128 bits.

Btw the PRF_AES128_CBC should have been named PRF_AES128_XCBC, as it
is based on the AES-XCBC-PRF-128.
-- 
[email-masked]