[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments to draft-ietf-ipsec-ciph-aes-ccm-03.txt
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"...
>--
>kivinen@ssh.fi
>SSH Communications Security http://www.ssh.fi/
>SSH IPSEC Toolkit http://www.ssh.fi/ipsec/