IPSECME NSS Murthy
Internet-Draft Freescale
Intended status: Standard Track S.Shen
Expires: January 11, 2010 Huawei
Y.Mao
H3C
July 10, 2009
Using Advanced Encryption Standard (AES) Counter Mode with IKEv2
draft-ipsecme-aes-ctr-ikev2-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 11, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes the usage of Advanced Encryption Standard
Counter Mode (AES-CTR), with an explicit initialization vector, by
IKEv2 for encrypting IKE-SA and Child-SA negotiations.
Shen, et al. Expires January 11, 2010 [Page 1]
Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. AES Counter Mode . . . . . . . . . . . . . . . . . . . . . . . 3
3. IKEv2 Encrypted Payload . . .. . . . . . . . . . . . . . . . . 3
3.1 Initialization Vector(IV). . . . . . . . . . . . . . . . . . 4
3.2 Integrity Checksum Data . . . . . . . . . . . . . . . . . . 4
4. Counter Block Format. . . . . . . . . . . . . . . . . . . . . . 5
5 IKEv2 Conventions. . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Keying Material and Nonces. . . . . . . . . . . . . . . . . . 5
5.2 Encryption identifier. . . . . . . . . . . . . . . . . . . . 6
5.3 Key Length Attribute . . . .. ... . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Shen, et al. Expires January 11, 2010 [Page 2]
Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009
1. Introduction
All the IKEv2 messages that follow the initial exchange(IKE_SA_INIT)
are cryptographically protected using the cryptographic algorithms and
keys negotiated in the first two messages of the IKEv2 exchange.These
subsequent messages use the syntax of the IKEv2 Encrypted Payload as
explained in RFC 4306.
This document explains how IKEv2 makes use of AES-CTR algorithm for
encrypting IKE messages that follow initial exchange.This document
specifies the IANA defined encryption identifier for AES-CTR to be
used during IKE-SA and Child-SA negotiations.It explains how to derive
the AES-CTR encryption key and nonce required from the key material
generated.It also explains the Initialization vector,its length and
its uniqueness for a given encryption key.This document explains the
counter block format used for encryption and decryption.It provides
references for more details regarding implementation of AES-CTR
algorithm.
2. AES Counter Mode
Section 2 of RFC 3686 provides a description of AES-CTR mode
including its characteristics and implementation issues.
3.IKEv2 Encrypted Payload
Section 3.14 of IKEv2 RFC 4306 explains the IKEv2 Encrypted Pay load.
The encrypted Payload,denoted SK{...} contains other IKEv2 payloads in
encrypted form.
The pay load includes an Initialization Vector(IV) whose length is
defined by the encryption algorithm negotiated.It also includes
Integrity Checksum data.These two fields are not encrypted.
3.1.Initialization Vector(IV)
The IV field MUST be eight octets when AES-CTR algorithm is used for
encryption.The IV MUST be chosen by the encryptor in a manner that
ensures that the same IV value is NOT used more than once with a given
encryption key.The encryptor can generate the IV in any manner that
ensures uniqueness.Common approaches to IV generation include
incrementing a counter for each packet and linear feedback shift
registers (LFSRs).
Shen, et al. Expires January 11, 2010 [Page 3]
Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009
3.2.Integrity Checksum Data
Since it is trivial to construct a forgery AES-CTR ciphertext from a
valid AES-CTR ciphertext, IKEv2 MUST employ an integrity algorithm
when AES-CTR is selected for encrypting the IKEv2 payloads.
HMAC-SHA-1-96 [HMAC-SHA] is a likely choice.
4.Counter Block Format
All the IKEv2 messages following the initial exchange are
cryptographically protected using the cryptographic algorithms and
keys negotiated in the first two messages of the IKEv2 exchange.These
subsequent messages use the syntax of the IKEv2 Encrypted Payload.
All such messages carry the IV that is necessary to construct the
sequence of counter blocks used to generate the key stream necessary
to decrypt the payload.The AES counter block cipher block is 128 bits.
Figure 1 shows the format of the counter block.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector (IV) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Counter Block Format
The components of the counter block are as follows:
Nonce
The Nonce field is 4 octets.An unpredictably fresh nonce value
MUST be assigned to each security association immediately after
it is established.Section 5.1 explains how IKEv2 is used to
generate the nonce by the two parties individually.
Shen, et al. Expires January 11, 2010 [Page 4]
Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009
Initialization Vector
The IV field is 64 bits.The IV MUST be chosen by the encryptor
in a manner that ensures that the same IV value is used only once
for a given encryption key.The encryptor includes the IV in the
IKEv2 message containing encrypted pay loads.
Block Counter
The block counter field is the least significant 32 bits of the
counter block.The block counter begins with the value of one,
and it is incremented to generate subsequent portions of the key
stream. The block counter is a 32-bit big-endian integer value.
Section 2 provides references to other documents for implementing
AES-CTR encryption/decryption process.
5 IKEv2 Conventions
This section describes the conventions used by Internet Key Exchange
IKEv2 protocol to generate keying material and nonces for use with
AES-CTR algorithm for both IKE-SA and Childs-SA negotiations.The
identifiers and attributes needed to negotiate security associations
which uses AES-CTR are also defined.
5.1 Keying Material and Nonces
As we MUST not reuse the same combination of IV and encryption key
values with AES-CTR algorithm,IKEv2 can be used to establish fresh
keys and Nonces. This section describes the conventions for
obtaining an unpredictable and secret nonce value and encryption
key using IKEv2.
IKEv2 makes use of a negotiated pseudo-random function(PRF) for the
construction of keying material for all of the cryptographic
algorithms used in both the IKE_SA and the CHILD_SAs as explained
in sections 2.14 and 2.17 of RFC 4306.Keying material is extracted
from the output string without regard to boundaries.The two
directions of traffic flow use different keys.
The size of the keying material required for AES-CTR algorithm for
different key lengths is as follows:
AES-CTR with a 128 bit key
The key material required for each AES-CTR key is 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.
Shen, et al. Expires January 11, 2010 [Page 5]
Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009
AES-CTR with a 192 bit key
The key material requested for each AES-CTR key is 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
The key material requested for each AES-CTR key is 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.
5.2 Encryption identifier
IKEv2 uses the IANA allocated encryption identifier of 13 for
AES-CTR with an explicit IV (ENCR_AES_CTR 13) for both the IKE-SA
and Child-SA negotiations.
5.3 Key Length Attribute
Since the AES-CTR algorithm supports three key lengths, the Key
Length attribute MUST be specified in both the IKE-SA and Child-SA
negotiations.The Key Length attribute MUST have a value of 128,192,
or 256.
6. Security Considerations
Security considerations explained in section 7 of RFC 3686 are
entirely relevant for this draft also.
7. IANA Considerations
IANA has assigned 13 as the transform ID for AES-CTR encryption with
an explicit IV.This can be used for both IKE_SA and Child-SA
negotiations.
8. References
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC3686] R.Housley.,"Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)"RFC 3686 January 2004.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[AES] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197, November 2001, <
http://csrc.nist.gov/publications/fips/fips197/
fips-197.pdf>.
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation Methods and Techniques", NIST Special
Publication 800-38A, December 2001, <http://csrc.nist.gov/
publications/nistpubs/800-38a/sp800-38a.pdf>.
Shen, et al. Expires January 11, 2010 [Page 6]
Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009
Authors' Addresses
N S Srinivasa murthy
Freescale Semiconductor
UMA PLAZA,NAGRJUNA CIRCLE,PUNJAGUTTA
HYDERABAD 500082
INDIA
Email: ssmurthy.nittala@freescale.com
Sean Shen
Huawei
No. 9 Xinxi Road
Beijing 100085
China
Email: sshen@huawei.com
Yu Mao
Huawei-3com
Email: maoyu@h3c.com
Comments are solicited and should be addressed to the working
group's mailing list at ipsec@ietf.org and/or the author(s).
Shen, et al. Expires January 11, 2010 [Page 7]
Internet-Draft draft-ipsecme-aes-ctr-ikev2-00 July 2009