The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)
draft-ietf-avtcore-aria-srtp-11
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8269.
|
|
---|---|---|---|
Authors | Woo-Hwan Kim , Jungkeun Lee , Je Hong Park , Daesung Kwon , Dong-Chan Kim | ||
Last updated | 2017-10-16 (Latest revision 2017-08-08) | ||
Replaces | draft-nsri-avtcore-aria-srtp | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Informational | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-07)
by Alexey Melnikov
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Roni Even | ||
Shepherd write-up | Show Last changed 2017-05-27 | ||
IESG | IESG state | Became RFC 8269 (Informational) | |
Action Holders |
(None)
|
||
Consensus boilerplate | Yes | ||
Telechat date | (None) | ||
Responsible AD | Ben Campbell | ||
Send notices to | Roni Even <roni.even@huawei.com> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack |
draft-ietf-avtcore-aria-srtp-11
AVTCore W. Kim Internet-Draft J. Lee Intended status: Informational J. Park Expires: February 9, 2018 D. Kwon NSRI D. Kim Kookmin Univ. August 8, 2017 The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) draft-ietf-avtcore-aria-srtp-11 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, GCM) and the SRTP Key Derivation Functions for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and MIKEY parameter sets for the use with ARIA. 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 February 9, 2018. 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Kim, et al. Expires February 9, 2018 [Page 1] Internet-Draft ARIA Algorithm for SRTP August 2017 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. ARIA . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Cryptographic Transforms . . . . . . . . . . . . . . . . . . 3 2.1. ARIA-CTR . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. ARIA-GCM . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Key Derivation Functions . . . . . . . . . . . . . . . . . . 4 4. Protection Profiles . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6.1. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. MIKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 11 A.1. ARIA-CTR Test Vectors . . . . . . . . . . . . . . . . . . 11 A.1.1. SRTP_ARIA_128_CTR_HMAC_SHA1_80 . . . . . . . . . . . 11 A.1.2. SRTP_ARIA_256_CTR_HMAC_SHA1_80 . . . . . . . . . . . 12 A.2. ARIA-GCM Test Vectors . . . . . . . . . . . . . . . . . . 13 A.2.1. SRTP_AEAD_ARIA_128_GCM . . . . . . . . . . . . . . . 14 A.2.2. SRTP_AEAD_ARIA_256_GCM . . . . . . . . . . . . . . . 14 A.3. Key Derivation Test Vector . . . . . . . . . . . . . . . 15 A.3.1. ARIA_128_CTR_PRF . . . . . . . . . . . . . . . . . . 15 A.3.2. ARIA_256_CTR_PRF . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction This document defines the use of the ARIA [RFC5794] block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) [RFC3711] for providing confidentiality for the Real-time Transport Protocol (RTP) [RFC3550] traffic and for the RTP Control Protocol (RTCP) [RFC3550] traffic. 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 Kim, et al. Expires February 9, 2018 [Page 2] Internet-Draft ARIA Algorithm for SRTP August 2017 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. 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. Cryptographic Transforms 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 the SRTP protocol, (1) ARIA in Counter Mode (ARIA-CTR) and (2) ARIA in Galois/Counter Mode (ARIA- GCM). 2.1. ARIA-CTR 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, 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]. 2.2. ARIA-GCM GCM (Galois Counter Mode) [GCM][RFC5116] is an AEAD (Authenticated Encryption with Associated Data) block cipher mode. A detailed description of ARIA-GCM is defined similarly as AES-GCM found in [RFC5116][RFC5282]. Kim, et al. Expires February 9, 2018 [Page 3] Internet-Draft ARIA Algorithm for SRTP August 2017 The document [RFC7714] describes the use of AES-GCM with SRTP [RFC3711][RFC6904]. The use of ARIA-GCM with SRTP is defined the same as that of 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. 3. Key Derivation Functions 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 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 underlying encryption algorithm, ARIA-CTR PRFs are denoted by "ARIA_128_CTR_PRF" and "ARIA_256_CTR_PRF". The usage requirements of [RFC6188][RFC7714] regarding the AES-CM PRF apply to the ARIA-CTR PRF as well. 4. Protection Profiles 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 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 Kim, et al. Expires February 9, 2018 [Page 4]Bormann & Hoffman Expires June 20, 2020 [Page 18] Internet-Draft CBOR December 2019 2, additional information of 12 for the length) followed by the 12 bytes of the bignum. Decoders do not need to understand tags of every tag number, and tags may be of little value in applications where the implementation creating a particular CBOR data item and the implementation decoding that stream know the semantic meaning of each item in the data flow. Their primary purpose in this specification is to define common data types such as dates. A secondary purpose is to provide conversion hints when it is foreseen that the CBOR data item needs to be translated into a different format, requiring hints about the content of items. Understanding the semantics of tags is optional for a decoder; it can just jump over the initial bytes of the tag (that encode the tag number) and interpret the tag content itself, presenting both tag number and tag content to the application. A tag applies semantics to the data item it encloses. Thus, if tag A encloses tag B, which encloses data item C, tag A applies to the result of applying tag B on data item C. That is, a tag is a data item consisting of a tag number and an enclosed value. The content of the tag (the enclosed data item) is the data item (the value) that is being tagged. IANA maintains a registry of tag numbers as described in Section 9.2. Table 4 provides a list of tag numbers that were defined in [RFC7049], with definitions in the rest of this section. Note that many other tag numbers have been defined since the publication of [RFC7049]; see the registry described at Section 9.2 for the complete list. +----------+----------+---------------------------------------------+ | Tag | Data | Semantics | | Number | Item | | +----------+----------+---------------------------------------------+ | 0 | text | Standard date/time string; see | | | string | Section 3.4.1 | | | | | | 1 | multiple | Epoch-based date/time; see Section 3.4.2 | | | | | | 2 | byte | Positive bignum; see Section 3.4.3 | | | string | | | | | | | 3 | byte | Negative bignum; see Section 3.4.3 | | | string | | | | | | | 4 | array | Decimal fraction; see Section 3.4.4 | | | | | | 5 | array | Bigfloat; see Section 3.4.4 | Bormann & Hoffman Expires June 20, 2020 [Page 19] Internet-Draft CBOR December 2019 | | | | | 21 | multiple | Expected conversion to base64url encoding; | | | | see Section 3.4.5.2 | | | | | | 22 | multiple | Expected conversion to base64 encoding; see | | | | Section 3.4.5.2 | | | | | | 23 | multiple | Expected conversion to base16 encoding; see | | | | Section 3.4.5.2 | | | | | | 24 | byte | Encoded CBOR data item; see Section 3.4.5.1 | | | string | | | | | | | 32 | text | URI; see Section 3.4.5.3 | | | string | | | | | | | 33 | text | base64url; see Section 3.4.5.3 | | | string | | | | | | | 34 | text | base64; see Section 3.4.5.3 | | | string | | | | | | | 35 | text | Regular expression; see Section 3.4.5.3 | | | string | | | | | | | 36 | text | MIME message; see Section 3.4.5.3 | | | string | | | | | | | 55799 | multiple | Self-described CBOR; see Section 3.4.6 | +----------+----------+---------------------------------------------+ Table 4: Tag numbers defined in RFC 7049 Conceptually, tags are interpreted in the generic data model, not at (de-)serialization time. A small number of tags (specifically, tag number 25 and tag number 29) have been registered with semantics that may require processing at (de-)serialization time: The decoder needs to be aware and the encoder needs to be in control of the exact sequence in which data items are encoded into the CBOR data stream. This means these tags cannot be implemented on top of every generic CBOR encoder/decoder (which might not reflect the serialization order for entries in a map at the data model level and vice versa); their implementation therefore typically needs to be integrated into the generic encoder/decoder. The definition of new tags with this property is NOT RECOMMENDED. Protocols using tag numbers 0 and 1 extend the generic data model (Section 2) with data items representing points in time; tag numbers Bormann & Hoffman Expires June 20, 2020 [Page 20] Internet-Draft CBOR December 2019 2 and 3, with arbitrarily sized integers; and tag numbers 4 and 5, with floating point values of arbitrary size and precision. 3.4.1. Standard Date/Time String Tag number 0 contains a text string in the standard format described by the "date-time" production in [RFC3339], as refined by Section 3.3 of [RFC4287], representing the point in time described there. A nested item of another type or that doesn't match the [RFC4287] format is invalid. 3.4.2. Epoch-based Date/Time Tag number 1 contains a numerical value counting the number of seconds from 1970-01-01T00:00Z in UTC time to the represented point in civil time. The enclosed item MUST be an unsigned or negative integer (major types 0 and 1), or a floating-point number (major type 7 with additional information 25, 26, or 27). Other contained types are invalid. Non-negative values (major type 0 and non-negative floating-point numbers) stand for time values on or after 1970-01-01T00:00Z UTC and are interpreted according to POSIX [TIME_T]. (POSIX time is also known as UNIX Epoch time. Note that leap seconds are handled specially by POSIX time and this results in a 1 second discontinuity several times per decade.) Note that applications that require the expression of times beyond early 2106 cannot leave out support of 64-bit integers for the enclosed value. Negative values (major type 1 and negative floating-point numbers) are interpreted as determined by the application requirements as there is no universal standard for UTC count-of-seconds time before 1970-01-01T00:00Z (this is particularly true for points in time that precede discontinuities in national calendars). The same applies to non-finite values. To indicate fractional seconds, floating-point values can be used within tag number 1 instead of integer values. Note that this generally requires binary64 support, as binary16 and binary32 provide non-zero fractions of seconds only for a short period of time around early 1970. An application that requires tag number 1 support may restrict the enclosed value to be an integer (or a floating-point value) only. Bormann & Hoffman Expires June 20, 2020 [Page 21] Internet-Draft CBOR December 2019 3.4.3. Bignums Protocols using tag numbers 2 and 3 extend the generic data model (Section 2) with "bignums" representing arbitrarily sized integers. In the generic data model, bignum values are not equal to integers from the basic data model, but specific data models can define that equivalence, and preferred encoding never makes use of bignums that also can be expressed as basic integers (see below). Bignums are encoded as a byte string data item, which is interpreted as an unsigned integer n in network byte order. Contained items of other types are invalid. For tag number 2, the value of the bignum is n. For tag number 3, the value of the bignum is -1 - n. The preferred encoding of the byte string is to leave out any leading zeroes (note that this means the preferred encoding for n = 0 is the empty byte string, but see below). Decoders that understand these tags MUST be able to decode bignums that do have leading zeroes. The preferred encoding of an integer that can be represented using major type 0 or 1 is to encode it this way instead of as a bignum (which means that the empty string never occurs in a bignum when using preferred encoding). Note that this means the non-preferred choice of a bignum representation instead of a basic integer for encoding a number is not intended to have application semantics (just as the choice of a longer basic integer representation than needed, such as 0x1800 for 0x00 does not). For example, the number 18446744073709551616 (2**64) is represented as 0b110_00010 (major type 6, tag number 2), followed by 0b010_01001 (major type 2, length 9), followed by 0x010000000000000000 (one byte 0x01 and eight bytes 0x00). In hexadecimal: C2 -- Tag 2 49 -- Byte string of length 9 010000000000000000 -- Bytes content 3.4.4. Decimal Fractions and Bigfloats Protocols using tag number 4 extend the generic data model with data items representing arbitrary-length decimal fractions of the form m*(10**e). Protocols using tag number 5 extend the generic data model with data items representing arbitrary-length binary fractions of the form m*(2**e). As with bignums, values of different types are not equal in the generic data model. Decimal fractions combine an integer mantissa with a base-10 scaling factor. They are most useful if an application needs the exact representation of a decimal fraction such as 1.1 because there is no Bormann & Hoffman Expires June 20, 2020 [Page 22] Internet-Draft CBOR December 2019 exact representation for many decimal fractions in binary floating point. Bigfloats combine an integer mantissa with a base-2 scaling factor. They are binary floating-point values that can exceed the range or the precision of the three IEEE 754 formats supported by CBOR (Section 3.3). Bigfloats may also be used by constrained applications that need some basic binary floating-point capability without the need for supporting IEEE 754. A decimal fraction or a bigfloat is represented as a tagged array that contains exactly two integer numbers: an exponent e and a mantissa m. Decimal fractions (tag number 4) use base-10 exponents; the value of a decimal fraction data item is m*(10**e). Bigfloats (tag number 5) use base-2 exponents; the value of a bigfloat data item is m*(2**e). The exponent e MUST be represented in an integer of major type 0 or 1, while the mantissa also can be a bignum (Section 3.4.3). Contained items with other structures are invalid. An example of a decimal fraction is that the number 273.15 could be represented as 0b110_00100 (major type of 6 for the tag, additional information of 4 for the number of tag), followed by 0b100_00010 (major type of 4 for the array, additional information of 2 for the length of the array), followed by 0b001_00001 (major type of 1 for the first integer, additional information of 1 for the value of -2), followed by 0b000_11001 (major type of 0 for the second integer, additional information of 25 for a two-byte value), followed by 0b0110101010110011 (27315 in two bytes). In hexadecimal: C4 -- Tag 4 82 -- Array of length 2 21 -- -2 19 6ab3 -- 27315 An example of a bigfloat is that the number 1.5 could be represented as 0b110_00101 (major type of 6 for the tag, additional information of 5 for the number of tag), followed by 0b100_00010 (major type of 4 for the array, additional information of 2 for the length of the array), followed by 0b001_00000 (major type of 1 for the first integer, additional information of 0 for the value of -1), followed by 0b000_00011 (major type of 0 for the second integer, additional information of 3 for the value of 3). In hexadecimal: C5 -- Tag 5 82 -- Array of length 2 20 -- -1 03 -- 3 Bormann & Hoffman Expires June 20, 2020 [Page 23] Internet-Draft CBOR December 2019 Decimal fractions and bigfloats provide no representation of Infinity, -Infinity, or NaN; if these are needed in place of a decimal fraction or bigfloat, the IEEE 754 half-precision representations from Section 3.3 can be used. For constrained applications, where there is a choice between representing a specific number as an integer and as a decimal fraction or bigfloat (such as when the exponent is small and non-negative), there is a quality-of- implementation expectation that the integer representation is used directly. 3.4.5. Content Hints The tags in this section are for content hints that might be used by generic CBOR processors. These content hints do not extend the generic data model. 3.4.5.1. Encoded CBOR Data Item Sometimes it is beneficial to carry an embedded CBOR data item that is not meant to be decoded immediately at the time the enclosing data item is being decoded. Tag number 24 (CBOR data item) can be used to tag the embedded byte string as a data item encoded in CBOR format. Contained items that aren& Internet-Draft ARIA Algorithm for SRTP August 2017 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 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 Kim, et al. Expires February 9, 2018 [Page 5] Internet-Draft ARIA Algorithm for SRTP August 2017 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. 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. +--------------------------------------+ | Encryption | Encryption | Auth. | | Algorithm | Key Length | Tag Length | +======================================+ SRTP_ARIA_128_CTR_HMAC_80 | ARIA-CTR | 16 octets | 10 octets | SRTP_ARIA_128_CTR_HMAC_32 | ARIA-CTR | 16 octets | 4 octets | SRTP_ARIA_256_CTR_HMAC_80 | ARIA-CTR | 32 octets | 10 octets | SRTP_ARIA_256_CTR_HMAC_32 | ARIA-CTR | 32 octets | 4 octets | +======================================+ Figure 1: Mapping MIKEY parameters to ARIA-CTR with HMAC algorithm Kim, et al. Expires February 9, 2018 [Page 6] Internet-Draft ARIA Algorithm for SRTP August 2017 +--------------------------------------+ | Encryption | Encryption | AEAD Auth. | | Algorithm | Key Length | Tag Length | +======================================+ SRTP_AEAD_ARIA_128_GCM | ARIA-GCM | 16 octets | 16 octets | SRTP_AEAD_ARIA_256_GCM | ARIA-GCM | 32 octets | 16 octets | +======================================+ Figure 2: Mapping MIKEY parameters to AEAD algorithm 5. Security Considerations 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] [RFC7714] apply to this document as well. This document includes crypto suites with authentication tags of 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. Otherwise, short authentication tags SHOULD NOT be used, since 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. 6. IANA Considerations 6.1. DTLS-SRTP 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 is requested to add the protection profiles below to the "DTLS-SRTP Protection Profiles" created by [RFC5764], located on the following IANA page at time of writing: http://www.iana.org/assignments/srtp-protection/. SRTP_ARIA_128_CTR_HMAC_SHA1_80 = {TBD,TBD} Kim, et al. Expires February 9, 2018 [Page 7] Internet-Draft ARIA Algorithm for SRTP August 2017 SRTP_ARIA_128_CTR_HMAC_SHA1_32 = {TBD,TBD} SRTP_ARIA_256_CTR_HMAC_SHA1_80 = {TBD,TBD} SRTP_ARIA_256_CTR_HMAC_SHA1_32 = {TBD,TBD} SRTP_AEAD_ARIA_128_GCM = {TBD,TBD} SRTP_AEAD_ARIA_256_GCM = {TBD,TBD} 6.2. MIKEY [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 is requested to add the two encryption algorithms below to the "MIKEY Security Protocol Parameters SRTP Type 0 (Encryption algorithm)" and to add the PRF below to the "MIKEY Security Protocol Parameters SRTP Type 5 (Pseudo Random Function)" created by [RFC3830], located on the following IANA page at time of writing: http://www.iana.org/assignments/mikey- payloads/. +---------------+-------+ | SRTP Enc. alg | Value | +---------------+-------+ | ARIA-CTR | TBD | | ARIA-GCM | TBD | +---------------+-------+ Default session encryption key length is 16 octets. +----------+-------+ | SRTP PRF | Value | +----------+-------+ | ARIA-CTR | TBD | +----------+-------+ 7. References 7.1. Normative References [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST SP 800-38D, November 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. Kim, et al. Expires February 9, 2018 [Page 8] Internet-Draft ARIA Algorithm for SRTP August 2017 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, DOI 10.17487/RFC3830, August 2004, <http://www.rfc-editor.org/info/rfc3830>. [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>. [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, <http://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, <http://www.rfc-editor.org/info/rfc5764>. [RFC5794] Lee, J., Lee, J., Kim, J., Kwon, D., and C. Kim, "A Description of the ARIA Encryption Algorithm", RFC 5794, DOI 10.17487/RFC5794, March 2010, <http://www.rfc-editor.org/info/rfc5794>. [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure RTP", RFC 6188, DOI 10.17487/RFC6188, March 2011, <http://www.rfc-editor.org/info/rfc6188>. [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, <http://www.rfc-editor.org/info/rfc6904>. Kim, et al. Expires February 9, 2018 [Page 9] Internet-Draft ARIA Algorithm for SRTP August 2017 [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)", RFC 7714, DOI 10.17487/RFC7714, December 2015, <http://www.rfc-editor.org/info/rfc7714>. 7.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. [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, 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, <http://www.rfc-editor.org/info/rfc5748>. [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, <http://www.rfc-editor.org/info/rfc6194>. Kim, et al. Expires February 9, 2018 [Page 10] Internet-Draft ARIA Algorithm for SRTP August 2017 Appendix A. Test Vectors All values are in hexadecimal and represented by the network order (called big endian). A.1. ARIA-CTR Test Vectors Common values are organized as follows: Rollover Counter: 00000000 Sequence Number: 315e SSRC: 20e8f5eb Authentication Key: f93563311b354748c978913795530631 16452309 Session Salt: cd3a7c42c671e0067a2a2639b43a Initialization Vector: cd3a7c42e69915ed7a2a263985640000 RTP header: 8008315ebf2e6fe020e8f5eb RTP Payload: f57af5fd4ae19562976ec57a5a7ad55a 5af5c5e5c5fdf5c55ad57a4a7272d572 62e9729566ed66e97ac54a4a5a7ad5e1 5ae5fdd5fd5ac5d56ae56ad5c572d54a e54ac55a956afd6aed5a4ac562957a95 16991691d572fd14e97ae962ed7a9f4a 955af572e162f57a956666e17ae1f54a 95f566d54a66e16e4afd6a9f7ae1c5c5 5ae5d56afde916c5e94a6ec56695e14a fde1148416e94ad57ac5146ed59d1cc5 A.1.1. SRTP_ARIA_128_CTR_HMAC_SHA1_80 Kim, et al. Expires February 9, 2018 [Page 11] Internet-Draft ARIA Algorithm for SRTP August 2017 Session Key: 0c5ffd37a11edc42c325287fc0604f2e Encrypted RTP Payload: 1bf753f412e6f35058cc398dc851aae3 a6ccdcb463fbed9cfb3de2fb76fdffa9 e481f5efb64c92487f59dabbc7cc72da 092485f3fbad87888820b86037311fa4 4330e18a59a1e1338ba2c21458493a57 463475c54691f91cec785429119e0dfc d9048f90e07fecd50b528e8c62ee6e71 445de5d7f659405135aff3604c2ca4ff 4aaca40809cb9eee42cc4ad232307570 81ca289f2851d3315e9568b501fdce6d Authenticated portion || Rollover Counter: 8008315ebf2e6fe020e8f5eb1bf753f4 12e6f35058cc398dc851aae3a6ccdcb4 63fbed9cfb3de2fb76fdffa9e481f5ef b64c92487f59dabbc7cc72da092485f3 fbad87888820b86037311fa44330e18a 59a1e1338ba2c21458493a57463475c5 4691f91cec785429119e0dfcd9048f90 e07fecd50b528e8c62ee6e71445de5d7 f659405135aff3604c2ca4ff4aaca408 09cb9eee42cc4ad23230757081ca289f 2851d3315e9568b501fdce6d00000000 Authentication Tag: f9de4e729054672b0e35 A.1.2. SRTP_ARIA_256_CTR_HMAC_SHA1_80 Kim, et al. Expires February 9, 2018 [Page 12] Internet-Draft ARIA Algorithm for SRTP August 2017 Session Key: 0c5ffd37a11edc42c325287fc0604f2e 3e8cd5671a00fe3216aa5eb105783b54 Encrypted RTP Payload: c424c59fd5696305e5b13d8e8ca76566 17ccd7471088af9debf07b55c750f804 a5ac2b737be48140958a9b420524112a e72e4da5bca59d2b1019ddd7dbdc30b4 3d5f046152ced40947d62d2c93e7b8e5 0f02db2b6b61b010e4c1566884de1fa9 702cdf8157e8aedfe3dd77c76bb50c25 ae4d624615c15acfdeeb5f79482aaa01 d3e4c05eb601eca2bd10518e9d46b021 16359232e9eac0fabd05235dd09e6dea Authenticated portion || Rollover Counter: 8008315ebf2e6fe020e8f5ebc424c59f d5696305e5b13d8e8ca7656617ccd747 1088af9debf07b55c750f804a5ac2b73 7be48140958a9b420524112ae72e4da5 bca59d2b1019ddd7dbdc30b43d5f0461 52ced40947d62d2c93e7b8e50f02db2b 6b61b010e4c1566884de1fa9702cdf81 57e8aedfe3dd77c76bb50c25ae4d6246 15c15acfdeeb5f79482aaa01d3e4c05e b601eca2bd10518e9d46b02116359232 e9eac0fabd05235dd09e6dea00000000 Authentication Tag: 192f515fab04bbb4e62c A.2. ARIA-GCM Test Vectors Common values are organized as follows: Kim, et al. Expires February 9, 2018 [Page 13] Internet-Draft ARIA Algorithm for SRTP August 2017 Rollover Counter: 00000000 Sequence Number: 315e SSRC: 20e8f5eb Encryption Salt: 000000000000000000000000 Initialization Vector: 000020e8f5eb00000000315e RTP Payload: f57af5fd4ae19562976ec57a5a7ad55a 5af5c5e5c5fdf5c55ad57a4a7272d572 62e9729566ed66e97ac54a4a5a7ad5e1 5ae5fdd5fd5ac5d56ae56ad5c572d54a e54ac55a956afd6aed5a4ac562957a95 16991691d572fd14e97ae962ed7a9f4a 955af572e162f57a956666e17ae1f54a 95f566d54a66e16e4afd6a9f7ae1c5c5 5ae5d56afde916c5e94a6ec56695e14a fde1148416e94ad57ac5146ed59d1cc5 Associated Data: 8008315ebf2e6fe020e8f5eb The length of encrypted payload is larger than that of payload by 16 octets that is the length of the tag from GCM. A.2.1. SRTP_AEAD_ARIA_128_GCM Key: e91e5e75da65554a48181f3846349562 Encrypted RTP Payload: 4d8a9a0675550c704b17d8c9ddc81a5c d6f7da34f2fe1b3db7cb3dfb9697102e a0f3c1fc2dbc873d44bceeae8e444297 4ba21ff6789d3272613fb9631a7cf3f1 4bacbeb421633a90ffbe58c2fa6bdca5 34f10d0de0502ce1d531b6336e588782 78531e5c22bc6c85bbd784d78d9e680a a19031aaf89101d669d7a3965c1f7e16 229d7463e0535f4e253f5d18187d40b8 ae0f564bd970b5e7e2adfb211e89a953 5abace3f37f5a736f4be984bbffbedc1 A.2.2. SRTP_AEAD_ARIA_256_GCM Kim, et al. Expires February 9, 2018 [Page 14] Internet-Draft ARIA Algorithm for SRTP August 2017 Key: 0c5ffd37a11edc42c325287fc0604f2e 3e8cd5671a00fe3216aa5eb105783b54 Encrypted RTP Payload: 6f9e4bcbc8c85fc0128fb1e4a0a20cb9 932ff74581f54fc013dd054b19f99371 425b352d97d3f337b90b63d1b082adee ea9d2d7391897d591b985e55fb50cb53 50cf7d38dc27dda127c078a149c8eb98 083d66363a46e3726af217d3a00275ad 5bf772c7610ea4c23006878f0ee69a83 97703169a419303f40b72e4573714d19 e2697df61e7c7252e5abc6bade876ac4 961bfac4d5e867afca351a48aed52822 e210d6ced2cf430ff841472915e7ef48 A.3. Key Derivation Test Vector 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 16/24/32 octet session encryption key according to the session encryption key length and 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. A.3.1. ARIA_128_CTR_PRF The inputs to the key derivation function are the 16 octet master key and the 14 octet master salt: master key: e1f97a0d3e018be0d64fa32c06de4139 master salt: 0ec675ad498afeebb6960b3aabe6 index DIV kdr: 000000000000 label: 00 master salt: 0ec675ad498afeebb6960b3aabe6 ----------------------------------------------- xor: 0ec675ad498afeebb6960b3aabe6 (x, PRF input) x*2^16: 0ec675ad498afeebb6960b3aabe60000 (ARIA-CTR input) cipher key: dbd85a3c4d9219b3e81f7d942e299de4 (ARIA-CTR output) Kim, et al. Expires February 9, 2018 [Page 15] Internet-Draft ARIA Algorithm for SRTP August 2017 ARIA-CTR protection profile requires a 14 octet cipher salt while ARIA-GCM protection profile requires a 12 octet cipher salt. index DIV kdr: 000000000000 label: 02 master salt: 0ec675ad498afeebb6960b3aabe6 ---------------------------------------------- xor: 0ec675ad498afee9b6960b3aabe6 (x, PRF input) x*2^16: 0ec675ad498afee9b6960b3aabe60000 (ARIA-CTR input) 9700657f5f34161830d7d85f5dc8be7f (ARIA-CTR output) cipher salt: 9700657f5f34161830d7d85f5dc8 (ARIA-CTR profile) 9700657f5f34161830d7d85f (ARIA-GCM profile) index DIV kdr: 000000000000 label: 01 master salt: 0ec675ad498afeebb6960b3aabe6 ----------------------------------------------- xor: 0ec675ad498afeeab6960b3aabe6 (x, PRF input) x*2^16: 0ec675ad498afeeab6960b3aabe60000 (ARIA-CTR input) Below, the auth key is shown on the left, while the corresponding ARIA input blocks are shown on the right. auth key ARIA input blocks d021877bd3eaf92d581ed70ddc050e03 0ec675ad498afeeab6960b3aabe60000 f11257032676f2a29f57b21abd3a1423 0ec675ad498afeeab6960b3aabe60001 769749bdc5dd9ca5b43ca6b6c1f3a7de 0ec675ad498afeeab6960b3aabe60002 4047904bcf811f601cc03eaa5d7af6db 0ec675ad498afeeab6960b3aabe60003 9f88efa2e51ca832fc2a15b126fa7be2 0ec675ad498afeeab6960b3aabe60004 469af896acb1852c31d822c45799 0ec675ad498afeeab6960b3aabe60005 A.3.2. ARIA_256_CTR_PRF The inputs to the key derivation function are the 32 octet master key and the 14 octet master salt: Kim, et al. Expires February 9, 2018 [Page 16] Internet-Draft ARIA Algorithm for SRTP August 2017 master key: 0c5ffd37a11edc42c325287fc0604f2e 3e8cd5671a00fe3216aa5eb105783b54 master salt: 0ec675ad498afeebb6960b3aabe6 index DIV kdr: 000000000000 label: 00 master salt: 0ec675ad498afeebb6960b3aabe6 ----------------------------------------------- xor: 0ec675ad498afeebb6960b3aabe6 (x, PRF input) x*2^16: 0ec675ad498afeebb6960b3aabe60000 (ARIA-CTR input) cipher key: 0649a09d93755fe9c2b2efba1cce930a (ARIA-CTR 1st output) f2e76ce8b77e4b175950321aa94b0cf4 (ARIA-CTR 2nd output) ARIA-CTR protection profile requires a 14 octet cipher salt while ARIA-GCM protection profile requires a 12 octet cipher salt. index DIV kdr: 000000000000 label: 02 master salt: 0ec675ad498afeebb6960b3aabe6 ---------------------------------------------- xor: 0ec675ad498afee9b6960b3aabe6 (x, PRF input) x*2^16: 0ec675ad498afee9b6960b3aabe60000 (ARIA-CTR input) 194abaa8553a8eba8a413a340fc80a3d (ARIA-CTR output) cipher salt: 194abaa8553a8eba8a413a340fc8 (ARIA-CTR profile) 194abaa8553a8eba8a413a34 (ARIA-GCM profile) index DIV kdr: 000000000000 label: 01 master salt: 0ec675ad498afeebb6960b3aabe6 ----------------------------------------------- xor: 0ec675ad498afeeab6960b3aabe6 (x, PRF input) x*2^16: 0ec675ad498afeeab6960b3aabe60000 (ARIA-CTR input) Below, the auth key is shown on the left, while the corresponding ARIA input blocks are shown on the right. Kim, et al. Expires February 9, 2018 [Page 17] Internet-Draft ARIA Algorithm for SRTP August 2017 auth key ARIA input blocks e58d42915873b71899234807334658f2 0ec675ad498afeeab6960b3aabe60000 0bc460181d06e02b7a9e60f02ff10bfc 0ec675ad498afeeab6960b3aabe60001 9ade3795cf78f3e0f2556d9d913470c4 0ec675ad498afeeab6960b3aabe60002 e82e45d254bfb8e2933851a3930ffe7d 0ec675ad498afeeab6960b3aabe60003 fca751c03ec1e77e35e28dac4f17d1a5 0ec675ad498afeeab6960b3aabe60004 80bdac028766d3b1e8f5a41faa3c 0ec675ad498afeeab6960b3aabe60005 Authors' Addresses Woo-Hwan Kim National Security Research Institute P.O.Box 1, Yuseong Daejeon 34188 Korea EMail: whkim5@nsr.re.kr Jungkeun Lee National Security Research Institute P.O.Box 1, Yuseong Daejeon 34188 Korea EMail: jklee@nsr.re.kr Je-Hong Park National Security Research Institute P.O.Box 1, Yuseong Daejeon 34188 Korea EMail: jhpark@nsr.re.kr Daesung Kwon National Security Research Institute P.O.Box 1, Yuseong Daejeon 34188 Korea EMail: ds_kwon@nsr.re.kr Kim, et al. Expires February 9, 2018 [Page 18] Internet-Draft ARIA Algorithm for SRTP August 2017 Dong-Chan Kim Kookmin University 77 Jeongneung-ro, Seongbuk-gu Seoul 02707 Korea EMail: dckim@kookmin.ac.kr Kim, et al. Expires February 9, 2018 [Page 19]