[IPsec] About new PRF algorithms (comments to draft-kato-ipsec-camellia-cmac96and128-01)

[Tero Kivinen <[e-mail]>]

I read the draft-kato-ipsec-camellia-cmac96and128-01.txt and found one
big issue in there. It copies the RFC4434 and RFC4615 mechanism of
mixed fixed / variable length keys. Those documents are like they are
because we messed up with them, I do not think we want to copy that
kind of broken behavior any further. The new
draft-hoffman-ikev2bis-02.txt actually removes the fixed length prf
text from the IKEv2, and only says that it is used as special case for
those two RFCs (RFC 4434, RFC 4615):

from draft-hoffman-ikev2bis-02.txt:
   ...
   modulus.  Ni and Nr are the nonces, stripped of any headers.  For
   historical backwards-compatibility reasons, there are two PRFs that
   are treated specially in this calculation.  If the negotiated PRF is
   AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the
   first 64 bits of Ni and the first 64 bits of Nr are used in the
   calculation.


So I think we should change:

>  The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use
>                                with IPsec
>                draft-kato-ipsec-camellia-cmac96and128-01
...
> 5.  Camellia-CMAC-PRF-128
>
>    The Camellia-CMAC-PRF-128 algorithm is identical to Camellia-CMAC
>    except that the 128-bit key length restriction is removed.
>
>    IKEv2 [5] uses PRFs for multiple purposes, most notably for
>    generating keying material and authentication of the IKE_SA.  The
>    IKEv2 specification differentiates between PRFs with fixed key sizes
>    and those with variable key sizes.
>
>    When using Camellia-CMAC-PRF-128 as the PRF described in IKEv2,
>    Camellia-CMAC-PRF-128 is considered to take fixed size (16 octets)
>    keys for generating keying material but it takes variable key sizes
>    for authentication.
>
>    That is, when generating keying material, "half the bits must come
>    from Ni and half from Nr, taking the first bits of each" as described
>    in IKEv2, section 2.14; but for authenticating with shared secrets
>    (IKEv2, section 2.16), the shared secret does not have to be 16
>    octets and the length may vary.

to:

----------------------------------------------------------------------
5.  Camellia-CMAC-PRF-128

   The Camellia-CMAC-PRF-128 algorithm is identical to Camellia-CMAC
   except that the 128-bit key length restriction is removed.

   IKEv2 [5] uses PRFs for multiple purposes, most notably for
   generating keying material and authentication of the IKE_SA.

   When using Camellia-CMAC-PRF-128 as the PRF described in IKEv2,
   Camellia-CMAC-PRF-128 is considered to take variable key lenght in
   all places, and the number of bits of keying material generated
   when new keys are generated is 128 bits (i.e. when generating
   keying material the length of SK_d, SK_pi, and SK_pr will be 128
   bits).

   When generating SKEYSEED the full Ni and Nr are used as key for the
   PRF.
----------------------------------------------------------------------

As I think we do want to start using standard variable length PRF code
and specification for all future PRFs. 


Here is also some small nits in the
draft-kato-ipsec-camellia-cmac96and128-01.txt:

> 1.  Introduction
...
>    Since optimized source code is provided by several open source
>    lisences [21], Camellia is also adopted by several open source
>    projects(Openssl, FreeBSD, Linux and Gran Paradiso).  Additional API
             ^
Missing space.

>    for Network Security Services (NSS) and IPsec stack of Linux and Free
>    BSD are prepared or working progress for release.

Free BSD should be FreeBSD.

> 10.  References
> 10.1.  Normative
>    [1]   National Institute of Standards and Technology, "Recommendation
>          for Block Cipher Modes of Operation:The CMAC Mode for
>          Autentication", Special Publication 800-38B, May 2005.
>
>    [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
>          Levels", BCP 14, RFC 2119, March 1997.
>
>    [3]   Kent, S., "IP Authentication Header", RFC 4302, December 2005.
>
>    [4]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
>          December 2005.
>
>    [5]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
>          RFC 4306, December 2005.
>
>    [6]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
>          Roadmap", RFC 2411, November 1998.

I do not think the roadmap document is really a normative reference.

Also I am not sure if the RFC 4302, 4303 or 4306 need to be normative
refence either, as you can implement Camellia-CMAC-96 and
Camellia-CMAC-PRF-128 without reading or understanding those documents
(you can most likely also use them in IPsec without reading those
documents :). I would move all of those [3]-[6] to the informative
refences.

>    [7]   Matsui, M., Nakajima, J., and S. Moriai, "A Description of the
>          Camellia Encryption Algorithm", RFC 3713, April 2004.
>
> 10.2.  Informative
>
>    [8]   Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
>          RFC 2409, November 1998.

I cannot find any references to this in the document.
-- 
[e-mail]


_______________________________________________
IPsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipsec