Subject: Comments to draft-ietf-ipsec-ciph-aes-ctr-04.txt

From: Tero Kivinen <[email-masked]>
Date: Mon, 23 Jun 2003 17:55:55 +0300

The document draft-ietf-ipsec-ciph-aes-ctr-04 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:
----------------------------------------------------------------------
5.1. Keying Material and Nonces

   As described in section 2.1, implementations MUST use fresh keys
   with AES-CTR. IKE can be used to establish fresh keys. This section
   describes the conventions for obtaining the unpredictable nonce
   value from IKE. Note that this convention provides a nonce 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 four octets longer than is
   needed by the associated AES key. The keying material is used as
   follows:

      AES-CTR with a 128 bit key
         SK_ei and SK_er are each 20 octets. The first 16 octets are
         the 128-bit AES key, and the remaining four octets are used
         as the nonce value in the counter block.

      AES-CTR with a 192 bit key
         SK_ei and SK_er are each 28 octets. The first 24 octets are
         the 192-bit AES key, and the remaining four octets are used
         as the nonce value in the counter block.

      AES-CTR with a 256 bit key
         SK_ei and SK_er are each 36 octets. The first 32 octets are
         the 256-bit AES key, and the remaining four octets are used
         as the nonce value in the counter block.
----------------------------------------------------------------------

The SK_ai, SK_ar, SK_ei, SK_er are only used in the IKEv2 SA packet
encryption and authentication. The IPsec keys are generated from the
KEYMAT generated from the SK_d. I.e the IKEv2 draft says:

----------------------------------------------------------------------
   For CREATE_CHILD_SA exchanges with PFS the keying material is
   defined as:

      KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) ...
----------------------------------------------------------------------

and the IKEv1 RFC 2409 says:

----------------------------------------------------------------------
   If PFS is not needed, and KE payloads are not exchanged, the new
   keying material is defined as

       KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).

   If PFS is desired and KE payloads were exchanged, the new keying
   material is defined as

       KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)
...
----------------------------------------------------------------------

They both define how to expand the KEYMAT if needed.

So the proposed replacement text is:
----------------------------------------------------------------------
5.1. Keying Material and Nonces

   As described in section 2.1, implementations MUST use fresh keys
   with AES-CTR. IKE can be used to establish fresh keys. This section
   describes the conventions for obtaining the unpredictable nonce
   value from IKE. Note that this convention provides a nonce 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 requested is four octets longer than is needed
   by the associated AES key. The keying material is used as follows:

      AES-CTR with a 128 bit key
         KEYMAT requested for each AES-CTR key are each 20 octets. The
         first 16 octets are the 128-bit AES key, and the remaining
         four octets are used as the nonce value in the counter block.

      AES-CTR with a 192 bit key
         KEYMAT requested for each AES-CTR key are each 28 octets. The
         first 24 octets are the 192-bit AES key, and the remaining
         four octets are used as the nonce value in the counter block.

      AES-CTR with a 256 bit key
         KEYMAT requested for each AES-CTR key are each 36 octets. The
         first 32 octets are the 256-bit AES key, and the remaining
         four octets are used as the nonce value in the counter block.
----------------------------------------------------------------------

The wording is like that, because in the IKEv1 the KEYMAT is generated
for each SPI separetely, i.e inbound/outbound etc AH/ESP have separete
KEYMAT. For the IKEv2 the keying material is generated from one call
to the KEYMAT.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/