[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-ipsecme-aes-ctr-ikev2

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


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/