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

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 31 October 2013 14:54 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4B11E8149 for <avt@ietfa.amsl.com>; Thu, 31 Oct 2013 07:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.422
X-Spam-Level:
X-Spam-Status: No, score=-105.422 tagged_above=-999 required=5 tests=[AWL=0.827, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXJ0dA3IAgFZ for <avt@ietfa.amsl.com>; Thu, 31 Oct 2013 07:54:26 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 06E2C21F9DAF for <avt@ietf.org>; Thu, 31 Oct 2013 07:54:25 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-9f-52726f2056ca
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F6.C1.23787.02F62725; Thu, 31 Oct 2013 15:54:24 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.328.9; Thu, 31 Oct 2013 15:54:24 +0100
Message-ID: <52726F60.9060207@ericsson.com>
Date: Thu, 31 Oct 2013 15:55:28 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: <draft-ietf-avtcore-aria-srtp@tools.ietf.org>, IETF AVTCore WG <avt@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJJMWRmVeSWpSXmKPExsUyM+Jvja5CflGQwdsGXYuXPSvZLSZPFnBg 8liy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4MnofPmcr6FKrmLJ+CVsD4wK5LkZODgkBE4mH i1+wQ9hiEhfurWfrYuTiEBI4xCjxsHsBO4SznFHi6ayZrF2MHBy8AtoS92ZHgDSwCKhK/L7/ mxXEZhOwkLj5o5ENxBYVCJa4sewQmM0rIChxcuYTFpBWEaD43m2FIGFhARuJH6ufg4UlBMQl ehqDQMLMAnoSU662MELY8hLNW2czg9hCQEsbmjpYJzDyz0IydBaSlllIWhYwMq9iZM9NzMxJ LzfcxAgMroNbfuvuYDx1TuQQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GBMUN+/6VqKkybDKOdJO+f//lRZBJ0qDbrjKy6Z8cI9S/lbm76agfKCU722GWTzj0fPXmV+3 ebtFbvwmtvnyresW3a9aksXyzFmWb+f1vlJwQ9y04c12iR2bO5e9PbS57FTKdXaPSXPDGQ2u hN2aed+Hc+8Bvv+iLzdJholGnvgudCFB+6cbuxJLcUaioRZzUXEiAL6ygR78AQAA
Subject: [AVTCORE] Writeup comments on draft-ietf-avtcore-aria-srtp-05
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2013 14:54:32 -0000

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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------