[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments to draft-ietf-ipsec-ciph-aes-ctr-04.txt
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/