Internet DRAFT - draft-nsri-ipsecme-aria-ipsec
draft-nsri-ipsecme-aria-ipsec
Network Working Group W. Kim
Internet-Draft J. Lee
Intended status: Informational J. Park
Expires: March 18, 2012 D. Kwon
NSRI
September 15, 2011
The ARIA Cipher Algorithm and Its Use with IPsec
draft-nsri-ipsecme-aria-ipsec-00
Abstract
This document describes the use of the ARIA block cipher algorithm in
conjunction with several different modes of operation within IKE and
IPsec. It describes the use of ARIA in CBC, CTR, GCM and CCM modes
to encrypt and/or authenticate IKE and ESP traffic. It also
describes the use of ARIA in XCBC, CMAC, and GMAC modes to
authenticate IKE, ESP and AH traffic. The use of ARIA in XCBC and
CMAC modes for pseudorandom functions is also included.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 18, 2012.
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Kim, et al. Expires March 18, 2012 [Page 1]
Internet-Draft ARIA Cipher with IPsec September 2011
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. ARIA . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Modes of Operation . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Encryption and Combined Mode Algorithms . . . . . . . . . . . . 4
2.1. ARIA-CBC and ARIA-CTR . . . . . . . . . . . . . . . . . . . 4
2.2. ARIA-CCM and ARIA-GCM . . . . . . . . . . . . . . . . . . . 4
3. Integrity-Protection (Authentication) Algorithms . . . . . . . 5
3.1. ARIA-XCBC and ARIA-CMAC . . . . . . . . . . . . . . . . . . 5
3.2. ARIA-GMAC . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Pseudo-Random Functions (PRFs) . . . . . . . . . . . . . . . . 5
5. IKEv2 Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Keying Material . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Transform Type 1 . . . . . . . . . . . . . . . . . . . . . 6
5.3. Transform Type 2 . . . . . . . . . . . . . . . . . . . . . 6
5.4. Transform Type 3 . . . . . . . . . . . . . . . . . . . . . 6
5.5. Key Length Attribute . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Kim, et al. Expires March 18, 2012 [Page 2]
Internet-Draft ARIA Cipher with IPsec September 2011
1. Introduction
This document describes how to use ARIA in conjunction with several
different modes of operation within IKE [RFC5996] and IPsec
([RFC4301][RFC4302][RFC4303]). Within IKE, it is used either to
protect the IKE SA's traffic (encryption and integrity-protection
algorithms) or to generate keying material (pseudorandom functions).
Within IPsec, it is used to protect the IPsec/child SA's traffic, and
IKE is capable of negotiating its use for that purpose.
For encryption algorithms, the use of ARIA in cipher block chaining
(CBC) mode and counter (CTR) mode is described. Both are used to
encrypt IKE and/or ESP traffic, providing confidentiality protection
to the traffic. For integrity-protection algorithms, the use of ARIA
in eXtended CBC (XCBC) mode, CMAC mode and GMAC mode is described.
These are used to authenticate IKE and/or IPsec traffic, providing
integrity protection to the traffic. For combined mode algorithms,
the use of ARIA in counter with CBC-MAC (CCM) mode and Galois/Counter
Mode (GCM) is described. Both are used to encrypt and integrity
protect IKE and/or ESP traffic, providing both confidentiality and
integrity protection to the traffic. For pseudorandom functions, the
use of ARIA in XCBC mode and CMAC mode is described. Both are used
to generate the secret keys that are used in IKE SAs and IPsec SAs.
This document does not provide an overview of IPsec. However,
information about how the various components of IPsec and the way in
which they collectively provide security services is available in
[RFC4301], [RFC4302], [RFC4303] and [RFC5996].
1.1. ARIA
ARIA is a general-purpose block cipher algorithm developed by Korean
cryptographers in 2003. It is an iterated block cipher with 128-,
192-, and 256-bit keys and encrypts 128-bit blocks in 12, 14, and 16
rounds, depending on the key size. It is secure and suitable for
most software and hardware implementations on 32-bit and 8-bit
processors. It was established as a Korean standard block cipher
algorithm in 2004 [ARIAKS] and has been widely used in Korea,
especially for government-to-public services. It was included in
PKCS #11 in 2007 [ARIAPKCS]. The algorithm specification and object
identifiers are described in [RFC5794].
1.2. Modes of Operation
Block ciphers ARIA and AES share common characteristics including key
size and block length. ARIA does not have any restrictions for modes
of operation that are used with this block cipher. So several
definitions for ARIA modes of operation such as changes to packet
Kim, et al. Expires March 18, 2012 [Page 3]
Internet-Draft ARIA Cipher with IPsec September 2011
formats, detailed algorithmic computations, and special
considerations within relevant protocols can be specified according
as those which were previously specified for AES. This document does
not describe such definitions appropriate for the specific ARIA mode
of operation, but attempts to indicate the reference of the
corresponding AES mode of operation. The only difference in the
processing is that the underlying encryption primitive is ARIA
instead of AES.
1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Encryption and Combined Mode Algorithms
We specify four algorithms within IKE and IPsec ESP, (1) ARIA in CBC
Mode (ARIA-CBC), (2) ARIA in CTR Mode (ARIA-CTR), (3) ARIA in CCM
Mode (ARIA-CCM) and (4) ARIA in GCM (ARIA-GCM).
ARIA-CBC and ARIA-CTR are used to encrypt IKE and/or ESP traffic.
When ARIA-CTR is used to provide confidentiality, the use of
integrity protection is strongly recommended. As a single algorithm
which can provide both encryption and integrity protection, ARIA-CCM
and ARIA-GCM are used for IKE and/or ESP traffic.
2.1. ARIA-CBC and ARIA-CTR
The use of ARIA-CBC and ARIA-CTR within ESP is defined as AES-CBC
[RFC3602] and AES-CTR [RFC3686]. [RFC3602] can also be a reference
of ARIA-CBC within IKE, while ARIA-CTR within IKE refers to
[RFC5930], which extends [RFC3686] to enable the use of AES-CTR to
provide confidentiality for IKEv2 traffic.
2.2. ARIA-CCM and ARIA-GCM
The use of ARIA-CCM and ARIA-GCM within ESP is defined as AES-CCM
[RFC4309] and AES-GCM [RFC4106]. The use of ARIA-CCM and ARIA-GCM
within IKE is defined as AES in [RFC5282]. ARIA-CCM is a block-mode
algorithm with a random IV that is sent in the packet along with the
encrypted data, a 24-bit salt value; a 128-bit key and ICV sizes of
64, 96 and 128 bits. ARIA-GCM has the same structure with ARIA-CCM,
except that a 32-bit salt value is used.
Kim, et al. Expires March 18, 2012 [Page 4]
Internet-Draft ARIA Cipher with IPsec September 2011
3. Integrity-Protection (Authentication) Algorithms
We specify three algorithms within IKE and IPsec, (1) ARIA in
eXtended CBC Mode (ARIA-XCBC), (2) ARIA in CMAC Mode (ARIA-CMAC) and
(3) ARIA in GMAC Mode (ARIA-GMAC). These are block cipher modes of
operation providing integrity-protection, and can be used as an
authentication mechanism within the context of the IKE and/or IPsec
AH and ESP protocols. This protection is provided by computing an
Integrity Check Value (ICV), which is included in the packet.
3.1. ARIA-XCBC and ARIA-CMAC
XCBC and CMAC are variants of CBC-MAC, which are secure for message
of varying lengths (unlike classic CBC-MAC). The use of ARIA-XCBC
and ARIA-CMAC is defined as AES-XCBC [RFC3566] and AES-CMAC
[RFC4494]. Both are integrity-protection algorithms with a 128-bit
block and 128-bit key and 128-bit ICV. For use within IKE and IPsec,
the ICV is truncated to 96 bits.
3.2. ARIA-GMAC
ARIA-GMAC is a variant of ARIA-GCM that provides integrity protection
without encryption. It has two versions: an integrity-protection
algorithm for use within AH, and a combined mode algorithm with null
encryption for use within ESP. It can use key sizes of 128, 192, and
256 bits; the ICV is always 128 bits, and is not truncated. The use
ARIA-GMAC within IPsec is defined as AES-GMAC [RFC4543].
ARIA-GMAC cannot be used by IKE to protect its own SAs, since IKE SA
traffic requires encryption.
4. Pseudo-Random Functions (PRFs)
IKE uses pseudorandom functions (PRFs) to generate the secret keys
that are used in IKE SAs and IPsec SAs. These PRFs are generally the
same algorithms used for integrity protection, but their output is
not truncated, since all of the generated bits are used for the keys
in general.
We specify two algorithms within IKE as PRFs, (1) ARIA-XCBC and (2)
ARIA-CMAC. The use of ARIA-XCBC and ARIA-CMAC within IKE is defined
as AES-XCBC [RFC4434] and AES-CMAC [RFC4615].
5. IKEv2 Conventions
This section describes the conventions used to generate keying
material for use with ARIA modes of operation using the Internet Key
Exchange (IKEv2). The identifiers and attributes needed to negotiate
Kim, et al. Expires March 18, 2012 [Page 5]
Internet-Draft ARIA Cipher with IPsec September 2011
a security association that uses ARIA modes of operation are also
specified.
5.1. Keying Material
The PRF in IKE is used iteratively to derive keying material of
arbitrary size, called KEYMAT. Keying material consisting of the
actual ARIA key and the nonce is extracted from the output string
without regard to boundaries, but is derived in the same way as AES
modes of operation.
5.2. Transform Type 1
For IKEv2 negotiations, IANA is requested to assign IKE Transform
Type 1 Identifiers for ARIA-CBC, ARIA-CTR, ARIA-CCM and ARIA-GCM, as
recorded in Section 7.
5.3. Transform Type 2
For IKEv2 negotiations, IANA is requested to assign IKE Transform
Type 2 Identifiers for ARIA-XCBC, ARIA-CMAC and ARIA-GMAC, as
recorded in Section 7.
5.4. Transform Type 3
For IKEv2 negotiations, IANA is requested to assign IKE Transform
Type 3 Identifiers for ARIA-XCBC and ARIA-CMAC, as recorded in
Section 7.
For the usage of ARIA-GMAC within AH, each key size requires its own
IANA value because IKE does not have to negotiate the key size. For
the usage of ARIA-GMAC within ESP, there is only one IANA value,
because IKE negotiations specify the key size.
5.5. Key Length Attribute
ARIA modes of operation can be used with any of the three ARIA key
sizes. The way that the key size is indicated is different for
Transform Type 1 and the others.
For Transform Type 1, there is a single encryption identifier. The
IKE Key Length attribute MUST be used with each use of this
identifier to indicate the key size. The Key Length attribute MUST
have a value of 128-, 192-, or 256-bit, and is used in the same way
as AES modes of operation.
For Transforms Type 2 and Type 3, the IKE Key Length attribute MUST
NOT be used. Like ARIA-GMAC, each key size has its own separate
Kim, et al. Expires March 18, 2012 [Page 6]
Internet-Draft ARIA Cipher with IPsec September 2011
integrity transform identifier and algorithm name.
6. Security Considerations
At the time of writing this document no security problem has been
found on ARIA (see [TSL]).
The security considerations in [RFC3566], [RFC3602], [RFC3686],
[RFC4106], [RFC4309], [RFC4434], [RFC4494], [RFC4543], [RFC4615] and
[RFC5282] apply to this document as well. Within IKE and IPsec, ARIA
modes of operation do not create additional security considerations
beyond those of AES modes of operation.
7. IANA Considerations
IANA is requested to allocate Transform Type 1 (Encryption Algorithm
Transform IDs) Identifiers for ARIA-CBC, ARIA-CTR, ARIA-CCM, and
ARIA-GCM with an explicit IV in the "IKEv2 Parameters" registry:
Number Name
<TBD1> ENCR_ARIA_CBC;
<TBD2> ENCR_ARIA_CTR;
<TBD3> ENCR_ARIA_CCM_8;
<TBD4> ENCR_ARIA_CCM_12;
<TBD5> ENCR_ARIA_CCM_16;
<TBD6> ENCR_ARIA_GCM_8;
<TBD7> ENCR_ARIA_GCM_12;
<TBD8> ENCR_ARIA_GCM_16;
<TBD9> ENCR_NULL_AUTH_ARIA_GMAC;
IANA is also requested to allocate Transform Type 2 (Pseudo-random
Function Transform IDs) Identifiers for ARIA-XCBC and ARIA-CMAC with
an explicit IV in the "IKEv2 Parameters" registry:
Number Name
<TBD1> PRF_ARIA_128_XCBC;
<TBD2> PRF_ARIA_128_CMAC;
Kim, et al. Expires March 18, 2012 [Page 7]
Internet-Draft ARIA Cipher with IPsec September 2011
IANA is also requested to allocate Transform Type 3 (Integrity
Algorithm Transform IDs) Identifiers for ARIA-XCBC, ARIA-CMAC, and
ARIA-GMAC with an explicit IV in the "IKEv2 Parameters" registry:
Number Name
<TBD1> AUTH_ARIA_128_XCBC_96;
<TBD2> AUTH_ARIA_128_CMAC_96;
<TBD3> AUTH_ARIA_128_GMAC;
<TBD4> AUTH_ARIA_192_GMAC;
<TBD5> AUTH_ARIA_256_GMAC;
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
Algorithm and Its Use With IPsec", RFC 3566,
September 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES)
CCM Mode with IPsec Encapsulating Security Payload
(ESP)", RFC 4309, December 2005.
Kim, et al. Expires March 18, 2012 [Page 8]
Internet-Draft ARIA Cipher with IPsec September 2011
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434,
February 2006.
[RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96
Algorithm and Its Use with IPsec", RFC 4494, June 2006.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH",
RFC 4543, May 2006.
[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
PRF-128) Algorithm for the Internet Key Exchange Protocol
(IKE)", RFC 4615, August 2006.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282,
August 2008.
[RFC5794] Lee, J., Lee, J., Kim, J., Kwon, D., and C. Kim, "A
Description of the ARIA Encryption Algorithm", RFC 5794,
March 2010.
[RFC5930] Shen, S., Mao, Y., and NSS. Murthy, "Using Advanced
Encryption Standard Counter Mode (AES-CTR) with the
Internet Key Exchange version 02 (IKEv2) Protocol",
RFC 5930, July 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
8.2. Informative References
[ARIAKS] Korean Agency for Technology and Standards, "128 bit
block encryption algorithm ARIA - Part 1: General (in
Korean)", KS X 1213-1:2009, December 2009.
[ARIAPKCS] RSA Laboratories, "Additional PKCS #11 Mechanisms",
PKCS #11 v2.20 Amendment 3 Revision 1, January 2007.
[TSL] Tang, X., Sun, B., Li, R., Li, C., and J. Yin, "A meet-
in-the-middle attack on reduced-round ARIA", The Journal
of Systems and Software Vol.84(10), pp. 1685-1692,
October 2011.
Kim, et al. Expires March 18, 2012 [Page 9]
Internet-Draft ARIA Cipher with IPsec September 2011
Authors' Addresses
Woo-Hwan Kim
National Security Research Institute
P.O.Box 1, Yuseong
Daejeon 305-350
Korea
EMail: whkim5@ensec.re.kr
Jungkeun Lee
National Security Research Institute
P.O.Box 1, Yuseong
Daejeon 305-350
Korea
EMail: jklee@ensec.re.kr
Je-Hong Park
National Security Research Institute
P.O.Box 1, Yuseong
Daejeon 305-350
Korea
EMail: jhpark@ensec.re.kr
Daesung Kwon
National Security Research Institute
P.O.Box 1, Yuseong
Daejeon 305-350
Korea
EMail: ds_kwon@ensec.re.kr
Kim, et al. Expires March 18, 2012 [Page 10]
