Comments to draft-ietf-ipsec-ciph-aes-ccm-03.txt

[Tero Kivinen <kivinen@ssh.fi>]

The document draft-ietf-ipsec-ciph-aes-ccm-03 talks about generating
keying material in section 5.1, which only is valid to IKEv2 and Phase
1 SA creation. This should be change to apply to both IKEv1 and IKEv2
keying material generation.

The current text:
----------------------------------------------------------------------
7.1. Keying Material and Salt Values

   As previously described, implementations MUST use fresh keys with
   AES-CCM.  IKE can be used to establish fresh keys.  This section
   describes the conventions for obtaining the unpredictable salt value
   for use in the nonce from IKE.  Note that this convention provides a
   salt value that is secret as well as unpredictable.

   IKE makes use of a pseudo-random function (PRF) to derive keying
   material.  The PRF is used iteratively to derive keying material of
   arbitrary size.  Keying material is extracted from the output string
   without regard to boundaries.

   IKE uses the PRF to generate an output stream that parsed into five
   keys: SK_d, SK_ai, SK_ar, SK_ei, and SK_er.  SK_d is used to derive
   new keys for the child security associations.  SK_ai and SK_ar are
   the authentication keys for the initiator and the responder,
   respectively.  SK_ei and SK_er are the encryption keys for the
   initiator and the responder, respectively.

   SK_ai and SK_ei are used to protect traffic from the initiator to the
   responder.  SK_ar and SK_er are used to protect traffic from the
   responder to the initiator.

   The size of SK_ei and SK_er are each three octets longer than is
   needed by the associated AES key.  The keying material is used as
   follows:

      AES-CCM with a 128 bit key
         SK_ei and SK_er are each 19 octets.  The first 16 octets are
         the 128-bit AES key, and the remaining three octets are used as
         the salt value in the counter block.

      AES-CCM with a 192 bit key
         SK_ei and SK_er are each 27 octets.  The first 24 octets are
         the 192-bit AES key, and the remaining three octets are used as
         the salt value in the counter block.

      AES-CCM with a 256 bit key
         SK_ei and SK_er are each 35 octets.  The first 32 octets are
         the 256-bit AES key, and the remaining three octets are used as
         the salt value in the counter block.
----------------------------------------------------------------------

In my previous mail about the aes-ctr I already cut & pasted the
relevant pieces from the IKEv2 draft and RFC2409, so I do not repeat
them here.

The proposed replacement text is:
----------------------------------------------------------------------7.1. Keying Material and Salt Values

   As previously described, implementations MUST use fresh keys with
   AES-CCM.  IKE can be used to establish fresh keys.  This section
   describes the conventions for obtaining the unpredictable salt value
   for use in the nonce from IKE.  Note that this convention provides a
   salt value that is secret as well as unpredictable.

   IKE makes use of a pseudo-random function (PRF) to derive keying
   material. The PRF is used iteratively to derive keying material
   "KEYMAT" of arbitrary size. Keying material is extracted from the
   output string without regard to boundaries.

   The size of KEYMAT needed for each AES-CTR key is each three octets
   longer than is needed by the associated AES key. The keying
   material is used as follows:

      AES-CCM with a 128 bit key
         KEYMAT requested for each AES-CCM key are each 19 octets.
         The first 16 octets are the 128-bit AES key, and the
         remaining three octets are used as the salt value in the
         counter block. 

      AES-CCM with a 192 bit key
         KEYMAT requested for each AES-CCM key are each 27 octets.
         The first 24 octets are the 192-bit AES key, and the
         remaining three octets are used as the salt value in the
         counter block. 

      AES-CCM with a 256 bit key
         KEYMAT requested for each AES-CCM key are each 35 octets.
         The first 32 octets are the 256-bit AES key, and the
         remaining three octets are used as the salt value in the
         counter block. 
----------------------------------------------------------------------

Also the draft-ietf-ipsec-ciph-aes-ccm-03.txt is missing section "8.
Test Vectors"...
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/