draft-ietf-ipsecme-aes-ctr-ikev2-01.txt   draft-ietf-ipsecme-aes-ctr-ikev2-02.txt 
IPSECME S. Shen IPSECME S. Shen
Internet-Draft Huawei Internet-Draft Huawei
Updates: RFC4307 Y. Mao Updates: RFC4307 Y. Mao
(if approved) H3C (if approved) H3C
Expires: February 18, 2010 NSS. Murthy Expires: March 19, 2010 NSS. Murthy
Freescale Semiconductor Freescale Semiconductor
August 17, 2009 September 15, 2009
Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Using Advanced Encryption Standard (AES) Counter Mode with IKEv2
draft-ietf-ipsecme-aes-ctr-ikev2-01 draft-ietf-ipsecme-aes-ctr-ikev2-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 18, 2010. This Internet-Draft will expire on March 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used In This Document . . . . . . . . . . . . 3 1.1. Conventions Used In This Document . . . . . . . . . . . . 3
2. AES Counter Mode . . . . . . . . . . . . . . . . . . . . . . . 4 2. AES Counter Mode . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Counter Mode . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Counter Mode . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Key Sizes and Rounds . . . . . . . . . . . . . . . . . . . 6 2.2. Key Sizes and Rounds . . . . . . . . . . . . . . . . . . . 6
2.3. Block Size . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Block Size . . . . . . . . . . . . . . . . . . . . . . . . 7
3. IKEv2 Encrypted Payload . . . . . . . . . . . . . . . . . . . 8 3. IKEv2 Encrypted Payload . . . . . . . . . . . . . . . . . . . 8
3.1. Initialization Vector(IV) . . . . . . . . . . . . . . . . 8 3.1. Initialization Vector(IV) . . . . . . . . . . . . . . . . 8
3.2. Integrity Checksum Data . . . . . . . . . . . . . . . . . 8 3.2. Integrity Checksum Data . . . . . . . . . . . . . . . . . 8
3.3. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Counter Block Format . . . . . . . . . . . . . . . . . . . . . 9 4. Counter Block Format . . . . . . . . . . . . . . . . . . . . . 9
5. IKEv2 Conventions . . . . . . . . . . . . . . . . . . . . . . 11 5. IKEv2 Conventions . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Keying Material and Nonces . . . . . . . . . . . . . . . . 11 5.1. Keying Material and Nonces . . . . . . . . . . . . . . . . 11
5.2. Encryption identifier . . . . . . . . . . . . . . . . . . 12 5.2. Encryption identifier . . . . . . . . . . . . . . . . . . 12
5.3. Key Length Attribute . . . . . . . . . . . . . . . . . . . 12 5.3. Key Length Attribute . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
IKEv2 [RFC4306] is a component of IPsec used for performing mutual IKEv2 [RFC4306] is a component of IPsec used for performing mutual
authentication and establishing and maintaining security associations authentication and establishing and maintaining security associations
(SAs). [RFC4307] defines the set of algorithms that are mandatory to (SAs). [RFC4307] defines the set of algorithms that are mandatory to
implement as part of IKEv2, as well as algorithms that should be implement as part of IKEv2, as well as algorithms that should be
implemented because they may be promoted to mandatory at some future implemented because they may be promoted to mandatory at some future
time. [RFC4307] requires that an implementation "SHOULD" support time. [RFC4307] requires that an implementation "SHOULD" support
Advanced Encryption Standard [AES] in Counter Mode [MODES] (AES_CTR) Advanced Encryption Standard [AES] in Counter Mode [MODES] (AES_CTR)
skipping to change at page 8, line 31 skipping to change at page 8, line 31
manner that ensures uniqueness. Common approaches to IV generation manner that ensures uniqueness. Common approaches to IV generation
include incrementing a counter for each packet and linear feedback include incrementing a counter for each packet and linear feedback
shift registers (LFSRs). shift registers (LFSRs).
3.2. Integrity Checksum Data 3.2. Integrity Checksum Data
Since it is trivial to construct a forgery AES_CTR ciphertext from a Since it is trivial to construct a forgery AES_CTR ciphertext from a
valid AES_CTR ciphertext, an integrity algorithm must be used when valid AES_CTR ciphertext, an integrity algorithm must be used when
using AES_CTR. IKEv2 does require Integrity Checksum Data for using AES_CTR. IKEv2 does require Integrity Checksum Data for
Encrypted Payload as described in section 3.14 of [RFC4306]. The Encrypted Payload as described in section 3.14 of [RFC4306]. The
choice of integrity algorithms in IKEv2 is defined in [RFC4307] as: choice of integrity algorithms in IKEv2 is defined in [RFC4307] or
its future update documents.
Name Number Defined In Status 3.3. Padding
NONE 0
AUTH_HMAC_MD5_96 1 [RFC2403] MAY AES-CTR does not require the plaintext to be padded to a multiple of
AUTH_HMAC_SHA1_96 2 [RFC2404] MUST the block size. For the Padding field in the Encrypted Payload, as
AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ required in [RFC4306]: the sender SHOULD set the Pad Length to the
minimum value that makes the combination of the Payloads, the
Padding, and the Pad Length a multiple of the block size, but the
recipient MUST accept any length that results in proper alignment.
In this case when AES-CTR is used in IKEv2, the Padding field of the
Encrypted Payload SHOULD be empty, and the Pad Length field SHOULD be
zero.
It should be noticed that ESP [RFC4303] Encrypted Payload requires
alignment on a 4-byte boundary while IKEv2 [RFC4306] Encrypted
Payload does not have such a requirement.
4. Counter Block Format 4. Counter Block Format
All the IKEv2 messages following the initial exchange are All the IKEv2 messages following the initial exchange are
cryptographically protected using the cryptographic algorithms and cryptographically protected using the cryptographic algorithms and
keys negotiated in the first two messages of the IKEv2 exchange. keys negotiated in the first two messages of the IKEv2 exchange.
These subsequent messages use the syntax of the IKEv2 Encrypted These subsequent messages use the syntax of the IKEv2 Encrypted
Payload. Payload.
The Encrypted Payload is the XOR of the plaintext and key stream. The Encrypted Payload is the XOR of the plaintext and key stream.
skipping to change at page 15, line 7 skipping to change at page 15, line 7
[Recommendations]. [Recommendations].
7. IANA Considerations 7. IANA Considerations
IANA has assigned 13 as the transform ID for ENCR_AES_CTR encryption IANA has assigned 13 as the transform ID for ENCR_AES_CTR encryption
with an explicit IV. This ID is to be used during IKE_SA with an explicit IV. This ID is to be used during IKE_SA
negotiation. negotiation.
8. Acknowledgments 8. Acknowledgments
The authors thank Yaron Sheffer, Paul Hoffman for their direction and The authors thank Yaron Sheffer, Paul Hoffman and Tero Kivinen for
comments on this document. their direction and comments on this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307, Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
skipping to change at page 16, line 41 skipping to change at page 16, line 41
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004. (ESP)", RFC 3686, January 2004.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[draft-ietf-ipsecme-roadmap-02] [draft-ietf-ipsecme-roadmap-02]
Sheila, S. and S. Suresh, "IP Security (IPsec) and Sheila, S. and S. Suresh, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", Internet Key Exchange (IKE) Document Roadmap",
draft-ietf-ipsecme-roadmap-02 (work in progress), draft-ietf-ipsecme-roadmap-02 (work in progress),
July 2009. July 2009.
[Recommendations] [Recommendations]
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
"Recommendation for Key Management - Part1 - "Recommendation for Key Management - Part1 -
General(Revised)", NIST Special Publication 800-57, General(Revised)", NIST Special Publication 800-57,
March 2007, <http://csrc.nist.gov/publications/nistpubs/ March 2007, <http://csrc.nist.gov/publications/nistpubs/
800-57/SP800-57-Part1.pdf>. 800-57/SP800-57-Part1.pdf>.
Authors' Addresses Authors' Addresses
Sean Shen Sean Shen
Huawei Huawei
No. 9 Xinxi Road 4, South 4th Street, Zhongguancun
Beijing 100085 Beijing 100190
China China
Email: sshen@huawei.com Email: sean.s.shen@gmail.com
Yu Mao Yu Mao
H3C Tech. Co., Ltd H3C Tech. Co., Ltd
Oriental Electronic Bld. Oriental Electronic Bld.
No.2 Chuangye Road No.2 Chuangye Road
Shang-Di Information Industry Shang-Di Information Industry
Hai-Dian District Hai-Dian District
Beijing 100085 Beijing 100085
China China
Email: maoyu@h3c.com Email: maoyu@h3c.com
N S Srinivasa Murthy N S Srinivasa Murthy
Freescale Semiconductor
UMA PLAZA, NAGARJUNA CIRCLE, PUNJAGUTTA UMA PLAZA, NAGARJUNA CIRCLE, PUNJAGUTTA
HYDERABAD 500082 HYDERABAD 500082
INDIA INDIA
Email: ssmurthy.nittala@freescale.com Email: ssmurthy.nittala@freescale.com
 End of changes. 13 change blocks. 
16 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.36. The latest version is available from http://tools.ietf.org/tools/rfcdiff/