Internet Engineering Task Force (IETF) W. Kim Request for Comments: 8269 J. Lee Category: Informational J. Park ISSN: 2070-1721 D. Kwon NSRI D. Kim Kookmin Univ. October 2017
The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)
Abstract
This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR and GCM) and the SRTP key derivation functions for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and Multimedia Internet KEYing (MIKEY) parameter sets for use with ARIA.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8269.
Kim, et al. Informational [Page 1]
RFC 8269 ARIA Algorithm for SRTP October 2017
Copyright Notice
Copyright (c) 2017 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 (https://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 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.
This document defines the use of the ARIA block cipher algorithm [RFC5794] in the Secure Real-time Transport Protocol (SRTP) [RFC3711] for providing confidentiality for Real-time Transport Protocol (RTP) [RFC3550] traffic and for RTP Control Protocol (RTCP) [RFC3550] traffic.
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 Public-Key Cryptography Standards (PKCS) #11 in 2007 [ARIAPKCS]. The algorithm specification and object identifiers are described in [RFC5794].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Block ciphers ARIA and AES share common characteristics including mode, key size, and block size. ARIA does not have any restrictions for modes of operation that are used with this block cipher. We define two modes of running ARIA within SRTP: (1) ARIA in Counter Mode (ARIA-CTR) and (2) ARIA in Galois/Counter Mode (ARIA-GCM).
Section 4.1.1 of [RFC3711] defines AES-128 counter mode encryption, which it refers to as "AES_CM". Section 2 of [RFC6188] defines "AES_256_CM" in SRTP. ARIA counter modes are defined in the same manner except that each invocation of AES is replaced by that of ARIA [RFC5794] and are denoted by ARIA_128_CTR and ARIA_256_CTR, respectively, according to the key lengths. The plaintext inputs to the block cipher are formed as in AES-CTR (AES_CM, AES_256_CM) and the block cipher outputs are processed as in AES-CTR. Note that,
Kim, et al. Informational [Page 3]
RFC 8269 ARIA Algorithm for SRTP October 2017
ARIA-CTR MUST be used only in conjunction with an authentication transform.
Section 3.2 of [RFC6904] defines AES-CTR for SRTP header extension keystream generation. When ARIA-CTR is used, the header extension keystream SHALL be generated in the same manner except that each invocation of AES is replaced by that of ARIA [RFC5794].
Galois/Counter Mode [GCM] [RFC5116] is an Authenticated Encryption with Associated Data (AEAD) block cipher mode. A detailed description of ARIA-GCM is defined similarly as AES-GCM found in [RFC5116] and [RFC5282].
[RFC7714] describes the use of AES-GCM with SRTP. The use of ARIA- GCM with SRTP is defined the same as AES-GCM except that each invocation of AES is replaced by ARIA [RFC5794]. When encryption of header extensions [RFC6904] is in use, a separate keystream to encrypt selected RTP header extension elements MUST be generated in the same manner defined in [RFC7714] except that AES-CTR is replaced by ARIA-CTR.
Section 4.3.3 of [RFC3711] defines the AES-128 counter mode key derivation function, which it refers to as "AES-CM PRF". Section 3 of [RFC6188] defines the AES-256 counter mode key derivation function, which it refers to as "AES_256_CM_PRF". The ARIA-CTR Pseudorandom Function (PRF) is defined in a same manner except that each invocation of AES is replaced by that of ARIA. According to the key lengths of the underlying encryption algorithm, ARIA-CTR PRFs are denoted by "ARIA_128_CTR_PRF" and "ARIA_256_CTR_PRF". The usage requirements of [RFC6188] and [RFC7714] regarding the AES-CM PRF apply to the ARIA-CTR PRF as well.
This section defines SRTP protection profiles that use the ARIA transforms and key derivation functions defined in this document. The following list indicates the SRTP transform parameters for each protection profile. Those are described for use with DTLS-SRTP [RFC5764].
The parameters cipher_key_length, cipher_salt_length, auth_key_length, and auth_tag_length express the number of bits in the values to which they refer. The maximum_lifetime parameter indicates the maximum number of packets that can be protected with
Kim, et al. Informational [Page 4]
RFC 8269 ARIA Algorithm for SRTP October 2017
each single set of keys when the parameter profile is in use. All of these parameters apply to both RTP and RTCP, unless the RTCP parameters are separately specified.
SRTP_ARIA_128_CTR_HMAC_SHA1_80 cipher: ARIA_128_CTR cipher_key_length: 128 bits cipher_salt_length: 112 bits key derivation function: ARIA_128_CTR_PRF auth_function: HMAC-SHA1 auth_key_length: 160 bits auth_tag_length: 80 bits maximum_lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets
SRTP_ARIA_128_CTR_HMAC_SHA1_32 cipher: ARIA_128_CTR cipher_key_length: 128 bits cipher_salt_length: 112 bits key derivation function: ARIA_128_CTR_PRF auth_function: HMAC-SHA1 auth_key_length: 160 bits SRTP auth_tag_length: 32 bits SRTCP auth_tag_length: 80 bits maximum_lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets
SRTP_ARIA_256_CTR_HMAC_SHA1_80 cipher: ARIA_256_CTR cipher_key_length: 256 bits cipher_salt_length: 112 bits key derivation function: ARIA_256_CTR_PRF auth_function: HMAC-SHA1 auth_key_length: 160 bits auth_tag_length: 80 bits maximum_lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets
Kim, et al. Informational [Page 5]
RFC 8269 ARIA Algorithm for SRTP October 2017
SRTP_ARIA_256_CTR_HMAC_SHA1_32 cipher: ARIA_256_CTR cipher_key_length: 256 bits cipher_salt_length: 112 bits key derivation function: ARIA_256_CTR_PRF auth_function: HMAC-SHA1 auth_key_length: 160 bits SRTP auth_tag_length: 32 bits SRTCP auth_tag_length: 80 bits maximum_lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets
SRTP_AEAD_ARIA_128_GCM cipher: ARIA_128_GCM cipher_key_length: 128 bits cipher_salt_length: 96 bits aead_auth_tag_length: 128 bits auth_function: NULL auth_key_length: N/A auth_tag_length: N/A key derivation function: ARIA_128_CTR_PRF maximum_lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets
SRTP_AEAD_ARIA_256_GCM cipher: ARIA_256_GCM cipher_key_length: 256 bits cipher_salt_length: 96 bits aead_auth_tag_length: 128 bits auth_function: NULL auth_key_length: N/A auth_tag_length: N/A key derivation function: ARIA_256_CTR_PRF maximum_lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets
The ARIA-CTR protection profiles use the same authentication transform that is mandatory to implement in SRTP: HMAC-SHA1 with a 160-bit key.
Note that SRTP protection profiles that use AEAD algorithms do not specify an auth_function, auth_key_length, or auth_tag_length, since they do not use a separate auth_function, auth_key, or auth_tag. The term aead_auth_tag_length is used to emphasize that this refers to the authentication tag provided by the AEAD algorithm and that this tag is not located in the authentication tag field provided by SRTP/ SRTCP.
Kim, et al. Informational [Page 6]
RFC 8269 ARIA Algorithm for SRTP October 2017
The PRFs for ARIA protection profiles are defined by ARIA-CTR PRF of the equal key length with the encryption algorithm (see Section 2). SRTP_ARIA_128_CTR_HMAC and SRTP_AEAD_ARIA_128_GCM MUST use the ARIA_128_CTR_PRF key derivation function. And SRTP_ARIA_256_CTR_HMAC and SRTP_AEAD_ARIA_256_GCM MUST use the ARIA_256_CTR_PRF key derivation function.
MIKEY specifies the SRTP protection profile definition separately from the key length (which is specified by the session encryption key length) and the authentication tag length. The DTLS-SRTP [RFC5764] protection profiles are mapped to MIKEY parameter sets as shown below.
At the time of publication of this document, no security problem has been found on ARIA. Previous security analysis results are summarized in [ATY].
The security considerations in [GCM], [RFC3711], [RFC5116], [RFC6188], [RFC6904], and [RFC7714] apply to this document as well. This document includes crypto suites with authentication tags of a length less than 80 bits. These suites MAY be used for certain application contexts where longer authentication tags may be undesirable, for example, those mentioned in [RFC3711], Section 7.5.
Kim, et al. Informational [Page 7]
RFC 8269 ARIA Algorithm for SRTP October 2017
Otherwise, short authentication tags SHOULD NOT be used, since they may reduce authentication strength. See [RFC3711], Section 9.5 for a discussion of risks related to weak authentication in SRTP.
At the time of publication of this document, SRTP recommends HMAC- SHA1 as the default and mandatory-to-implement MAC algorithm. All currently registered SRTP crypto suites except the GCM-based ones use HMAC-SHA1 as their HMAC algorithm to provide message authentication. Due to security concerns with SHA-1 [RFC6194], the IETF is gradually moving away from SHA-1 and towards stronger hash algorithms such as SHA-2 or SHA-3 families. For SRTP, however, SHA-1 is only used in the calculation of an HMAC, and no security issue is known for this usage at the time of this publication.
DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP protection profile". In order to allow the use of the algorithms defined in this document in DTLS-SRTP, IANA has added the following protection profiles below to the "DTLS-SRTP Protection Profiles" registry (see <http://www.iana.org/assignments/srtp-protection/>) created by [RFC5764]:
[RFC3830] and [RFC5748] define encryption algorithms and PRFs for the SRTP policy in MIKEY. In order to allow the use of the algorithms defined in this document in MIKEY, IANA has updated the "Multimedia Internet KEYing (MIKEY) Payload Name Spaces" registry (see <http://www.iana.org/assignments/mikey-payloads/>.)
Kim, et al. Informational [Page 8]
RFC 8269 ARIA Algorithm for SRTP October 2017
IANA has registered the following two encryption algorithms in the "Encryption algorithm (Value 0)" subregistry within the "MIKEY Security Protocol Parameters" registry:
The default session encryption key length is 16 octets.
IANA has registered the following PRF in the "SRTP Pseudo Random Function (Value 5)" subregistry within the "MIKEY Security Protocol Parameters" registry:
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007.
[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, DOI 10.17487/RFC5282, August 2008, <https://www.rfc-editor.org/info/rfc5282>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.
[ARIAKS] Korean Agency for Technology and Standards, "128 bit block encryption algorithm ARIA - Part 1: General (in Korean)", KS X 1213-1:2014, December 2014.
[ATY] Abdelkhalek, A., Tolba, M., and A. Youssef, "Improved Linear Cryptanalysis of Round-Reduced ARIA", Information Security - ISC 2016, Lecture Notes in Computer Science (LNCS), Vol. 9866, pp. 18-34, DOI 10.1007/978-3-319-45871-7_2, September 2016.
[RFC5748] Yoon, S., Jeong, J., Kim, H., Jeong, H., and Y. Won, "IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY)", RFC 5748, DOI 10.17487/RFC5748, August 2010, <https://www.rfc-editor.org/info/rfc5748>.
This section provides test vectors for the default key derivation function that uses ARIA in Counter Mode. In the following, we walk through the initial key derivation for the ARIA Counter Mode cipher that requires a session encryption key of 16/24/32 octets according to the session encryption key length, a 14-octet session salt, and an authentication function that requires a 94-octet session authentication key. These values are called the cipher key, the cipher salt, and the auth key in the following. The test vectors are generated in the same way with the test vectors of key derivation functions in [RFC3711] and [RFC6188] but with each invocation of AES replaced with an invocation of ARIA.