Comments to draft-ietf-ipsec-ciph-aes-ccm-03.txt
Tero Kivinen <kivinen@ssh.fi> Mon, 23 June 2003 21:52 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11644 for <ipsec-archive@lists.ietf.org>; Mon, 23 Jun 2003 17:52:57 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00503 Mon, 23 Jun 2003 15:29:27 -0400 (EDT)
X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <16119.17412.231940.346484@ryijy.hel.fi.ssh.com>
Date: Mon, 23 Jun 2003 21:16:36 +0300
From: Tero Kivinen <kivinen@ssh.fi>
To: ipsec@lists.tislabs.com
CC: housley@vigilsec.com
Subject: Comments to draft-ietf-ipsec-ciph-aes-ccm-03.txt
X-Mailer: VM 7.07 under Emacs 20.7.1
Organization: SSH Communications Security Oy
X-Edit-Time: 5 min
X-Total-Time: 12 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit
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/
- Comments to draft-ietf-ipsec-ciph-aes-ccm-03.txt Tero Kivinen
- Re: Comments to draft-ietf-ipsec-ciph-aes-ccm-03.… Russ Housley