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

[Russ Housley <housley@vigilsec.com>]

Tero:

Good catch.  I made the changes, and I will post the updated draft as soon 
as the repository opens after the Vienna IETF.

Russ

At 05:55 PM 6/23/2003 +0300, Tero Kivinen wrote:
>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.
>--
>kivinen@ssh.fi
>SSH Communications Security                  http://www.ssh.fi/
>SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/