Re: [AVTCORE] Writeup comments on draft-ietf-avtcore-aria-srtp-05

[Woo-Hwan Kim <[e-mail]>]

Thank you for your comment.

1,2,4,5,7:
We'll revise the draft as your comment.

3:
We'll modify the text as following.

  Note that SRTP Protection Profiles which 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.

6:
We add some paragraph in Section 2.2 and Section 2.3

  When [RFC6904] is in use, a separate keystream to encrypt selected
  RTP header extension elements MUST be generated in the same manner
defined in
  [I-D.ietf-avtcore-srtp-aes-gcm] except that AES-CTR is replaced by
  ARIA-CTR.

We'll upload the revised version.
Thanks.

Sincerely,
Woo-Hwan Kim

-----Original Message-----
From: Magnus Westerlund [mailto:[e-mail]]
Sent: Thursday, October 31, 2013 11:55 PM
To: [e-mail]; IETF AVTCore WG
Subject: Writeup comments on draft-ietf-avtcore-aria-srtp-05

Authors, WG.

These are my comments on the ARIA draft found during my Write-up review.
These needs to be addressed prior to publication request can happen.

1. Section 6.2:
   [I-D.ietf-avtcore-srtp-aes-gcm]
              McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated
              Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-
              aes-gcm-10 (work in progress), September 2013.

Based on the formulations in the draft, this is a normative reference.
Please move it to the right section.



2. Section 5.2:

"IANA is requested to add the below crypto suite to the ..."

Replace "crypto suite" with "protection profiles"

3. Section 5.2:

"Note that these SRTP Protection Profiles do not specify an
   auth_function, auth_key_length, or auth_tag_length because all of
   these profiles use AEAD algorithms, and thus do not use a separate
   auth_function, auth_key, or auth_tag."

Not all of the above SRTP Protection Profiles are AEDA ones, thus I suggest
changing the above sentence to:

   Note that the majority of the SRTP Protection Profiles do not specify an
   auth_function, auth_key_length, or auth_tag_length because all of
   these profiles use AEAD algorithms, and thus do not use a separate
   auth_function, auth_key, or auth_tag.

4. Section 5.3:

   "In order to allow the use of the algorithms
   defined in this document in MIKEY, IANA is requested to add the below
   crypto suites to the "MIKEY Security Protocol Parameters SRTP Type 0
   (Encryption algorithm)" and to add the below PRF to the "MIKEY
   Security Protocol Parameters SRTP Type 5 (Pseudo Random Function)"
   created by [RFC3830], at time of writing located on the following
   IANA page: http://www.iana.org/assignments/mikey-payloads/mikey-
   payloads.xml#mikey-payloads-26 [3]."

There is an issue with using "crypto suites" in the MIKEY context. What you
are registering are parameters for the ARIA SRTP transform, and then you
provide a mapping between the crypto suits to the transform parameter's
values.

Can we find another formulation here? Perhaps:

  "In order to allow the use of the algorithms
   defined in this document in MIKEY, IANA is requested to add three
encryption algorithms to the "MIKEY Security Protocol Parameters SRTP Type 0
   (Encryption algorithm)" and to add the below PRF to the "MIKEY
   Security Protocol Parameters SRTP Type 5 (Pseudo Random Function)"
   created by [RFC3830], at time of writing located on the following
   IANA page: http://www.iana.org/assignments/mikey-payloads/mikey-
   payloads.xml#mikey-payloads-26 [3]."

To further clarify the purpose of Figure 1 and 2 maybe one should modify
this text:

   MIKEY specifies the algorithm family separately from the key length
   (which is specified by the Session Encryption key length) and the
   authentication tag length.

To something like:

   MIKEY specifies the algorithm family separately from the key length
   (which is specified by the Session Encryption key length) and the
   authentication tag length. The SDP Security Descriptions [RFC4568]
   crypto suits and corresponding DTLS-SRTP [RFC5764] protection
   profiles are mapped to MIKEY parameter sets as shown below.


5. Abstract:
This document describes the use of the ARIA block cipher algorithm

I would change "describes" to "defines"

6. Section 2.2, and Section 2.3:
While Seciton 2.1 addresses Jonathan Lennox comments regarding defining
encryption key stream for Header Extensions the GCM and and CCM fails to do
this.

Although AES-GCM document do defines this in Section 9.3, I don't think it
is clear enough which cipher shall be used with ARIA. Thus add an explicit
definition also in these sections for how it is generated.

7. Section 2.1:
ARIA counter modes are
   defined in the same manner except that each invocation of AES is
   replaced by that of ARIA, and are denoted by ARIA_128_CTR,
   ARIA_192_CTR and ARIA_256_CTR respectively, according to the key
   lengths.

I am missing the normative reference to ARIA in the above sentence, is
this: RFC5794?

IF it is please include it here and the other places for the other modes
when you define the crypto as follows:
  this procedure but replace AES with ARIA [RFC5794]

Then also RFC5794 needs to be moved to the normative list.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------