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

[Russ Housley <[e-mail]>]

Tero:

Good catch.  I will post an update as soon as the Internet-Draft repository 
opens after the IETF meeting in Vienna.

I will point to [CCM] for test vectors.  I think this will be sufficient 
for implementors.

Russ

At 09:16 PM 6/23/2003 +0300, Tero Kivinen wrote:
>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"...
>--
>[e-mail]
>SSH Communications Security                  http://www.ssh.fi/
>SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/