[AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-01

Woo-Hwan Kim <whkim5@ensec.re.kr> Mon, 16 July 2012 05:48 UTC

Return-Path: <woohwankim@gmail.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 C789821F8494 for <avt@ietfa.amsl.com>; Sun, 15 Jul 2012 22:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.047
X-Spam-Level:
X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 Qf5fWwa4Q3yZ for <avt@ietfa.amsl.com>; Sun, 15 Jul 2012 22:48:11 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C30EA21F8493 for <avt@ietf.org>; Sun, 15 Jul 2012 22:48:10 -0700 (PDT)
Received: by yenq13 with SMTP id q13so5113514yen.31 for <avt@ietf.org>; Sun, 15 Jul 2012 22:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=/Ti8pMRZdysrfN5LHPDrac+AxgE6lVMvB+HeDzin4Qg=; b=D+W4WIojKGA5Mi5nP764GocLcdcdQDO2XAi3BaB49Rj479A67Aai7hlxHA55LI3vMo mH2qqj37HPlncarsOtK1EGQOLgxgZGQnK9HwSrVFhvWg+x5h5qOiPJ4VnGmFuTOEYx4t I7D1k4qxEmgoy58uP/2lwzsWsxYEhswhXJincQovCQiKTISdtK2Bdzb9/i7L1xARxIs+ +AGQRB8A5VZ0GjNusIwwzpQPwXBE0w7ddjYhPRqf+Ft/1Ov+FjNrVBd3F7YNia2v7yY9 mXq5fytbSH5XntAiGas+gw0Nn2nXuee7UAnOS5biMM8L6TEgYo4E7TK3BYfFZPqTHA7m Zp6A==
MIME-Version: 1.0
Received: by 10.50.186.196 with SMTP id fm4mr4384420igc.34.1342417733917; Sun, 15 Jul 2012 22:48:53 -0700 (PDT)
Sender: woohwankim@gmail.com
Received: by 10.64.104.165 with HTTP; Sun, 15 Jul 2012 22:48:53 -0700 (PDT)
Date: Mon, 16 Jul 2012 14:48:53 +0900
X-Google-Sender-Auth: UdobFCis_YpUR5cb0slulfC400c
Message-ID: <CAMRi9Ce8Cn=HpY6sCos_-Jmi7Y0z1OA-ff58aoumXA8BRdnd0A@mail.gmail.com>
From: Woo-Hwan Kim <whkim5@ensec.re.kr>
To: avt@ietf.org, draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org
Content-Type: multipart/alternative; boundary="14dae9340fe72b9c3504c4ebfcd3"
Cc: Daesung Kwon <ds_kwon@ensec.re.kr>, Je Hong Park <jhpark@ensec.re.kr>
Subject: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-01
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: Mon, 16 Jul 2012 05:48:11 -0000

Hi.

Here are some comments on the draft-ietf-avtcore-srtp-aes-gcm-01.

1. typos and minors

p.4 DTLS -> DTLS-SRTP
p.8 ROS -> ROC
p.11 the corresponding STRCP encrypted -> the corresponding SRTCP encrypted
p.13 C_max -> C_MAX
p.18 AEAD_AES_128_CCM -> AEAD_AES_128_GCM
p.18 AEAD_AES_256_CCM -> AEAD_AES_256_GCM

2. On the CCM decryption

In this draft, there is no separation between GCM and CCM except
"Tag_Size_Flag“.
It means both modes have the same parameters (nonce length, counter block
length etc.) and the same IV format (described in Sections 8.1 and 9.1).
But that does not hold if the authors intend to apply the interfaces of CCM
described in RFC 5116.
For example, the counter block length parameter q is not 4 but 3 when the
length of nonce is 12 octets.

According to the InputFormatting Function proposed in NIST SP 800-38C (and
referred by RFC 5116),
Tag_Size_Flag recommended in this draft is derived when q=3.
Note that such parameter is related to several AEAD parameters, and so a
large portion of the draft should be revised.

3. CCM Tag Validation

Section 5.3 says
"The ciphertext MUST NOT be decrypted until the AEAD tag has been
validated. The associated data
MUST NOT be released until the AEAD tag has been validated."

The above does not hold for CCM mode of operation,
because it is required to decrypt ciphertext before confirming the
validation of the AEAD tag.

4. Ciphertext length expansion for SRTP

Section 9.2 says
"Since the AEAD cipher is larger than the plaintext by exactly the length
of the AEAD authentication
tag, the corresponding STRCP encrypted packet replaces the plaintext field
with a slightly larger
field containing the cipher."

Does this sentence only hold for SRTCP?

5. Input/output data for CCM (Sections 5.2.1 and 5.2.2)

Both input and output data for CCM require Tag_Size_Flag, but that is the
value which can be computed
by three parameters (defined in NIST SP 800-38C). Because Tag_Size_Flag is
not included in SRTP/SRTCP
packets, the only way to share the same Tag_Size_Flag is to fix
authentication tag length and counter
block length in advance.

Additionally, Section 5.2.1 says the only output of "Encrypt Mode" is
"Ciphertext" with bit string length = legnth length(ciphertext)-tag_length.
What is the difference between "ciphertext" and "Ciphertext". If length of
the "Ciphertext" does not consider the length of "authentication tag",
where is authentication tag?


6. CCM tag length specification

Section 10.3

RFC5116 only defines AEAD_AES_128/256_CCM with 16 octets tag length.

Section 13.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."

In IANA AEAD registry, there is no entry for AEAD_AES_128/256_CCM_12.
It means that there is no official reference for AES_CCM with 96-bit
authentication tag. So it is required to define
AEAD_AES_128/256_CCM_12 independently in this document, similar to
AEAD_AES_128/256_CCM_8 defined for
TLS usage(internet draft, AES-CCM Cipher Suites for TLS).

For SDES, it may be necessary to add CCM-related crypto suites with 64- and
96-bit authentication tags.

Thanks.

Woo-Hwan Kim