Re: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-01
"Igoe, Kevin M." <kmigoe@nsa.gov> Wed, 08 August 2012 17:54 UTC
Return-Path: <kmigoe@nsa.gov>
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 2F48A11E80F4 for <avt@ietfa.amsl.com>; Wed, 8 Aug 2012 10:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 X-jIweOuKMM9 for <avt@ietfa.amsl.com>; Wed, 8 Aug 2012 10:54:06 -0700 (PDT)
Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id C93FE11E80BA for <avt@ietf.org>; Wed, 8 Aug 2012 10:54:05 -0700 (PDT)
X-TM-IMSS-Message-ID: <860c2740000523ec@nsa.gov>
Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 860c2740000523ec ; Wed, 8 Aug 2012 13:53:55 -0400
Received: from MSIS-GH1-UEA02.corp.nsa.gov (10.215.225.44) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server id 14.1.289.1; Wed, 8 Aug 2012 13:53:49 -0400
Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSIS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Aug 2012 13:53:48 -0400
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD758E.C3652E3B"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 08 Aug 2012 13:53:48 -0400
Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C70@MSIS-GH1-UEA06.corp.nsa.gov>
In-Reply-To: <CAMRi9Ce8Cn=HpY6sCos_-Jmi7Y0z1OA-ff58aoumXA8BRdnd0A@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-01
Thread-Index: Ac1jFrdWK/01SeYRS0GjqISoVYllLgSdwrxA
References: <CAMRi9Ce8Cn=HpY6sCos_-Jmi7Y0z1OA-ff58aoumXA8BRdnd0A@mail.gmail.com>
From: "Igoe, Kevin M." <kmigoe@nsa.gov>
To: Woo-Hwan Kim <whkim5@ensec.re.kr>, avt@ietf.org, draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org
X-OriginalArrivalTime: 08 Aug 2012 17:53:48.0759 (UTC) FILETIME=[C364EE70:01CD758E]
Cc: Daesung Kwon <ds_kwon@ensec.re.kr>, Je Hong Park <jhpark@ensec.re.kr>
Subject: Re: [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: Wed, 08 Aug 2012 17:54:09 -0000
I'd like to thank Woo-Hwang Kim for the effort he put into reviewing draft-ietf-avtcore-srtp-aes-gcm-01. He raised many valid points, and the authors have a -02 draft nearing completion that addresses his observations. Many thanks to Woo-Hwan and the AVTCORE mailing list. From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Woo-Hwan Kim Sent: Monday, July 16, 2012 1:49 AM To: avt@ietf.org; draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org Cc: Daesung Kwon; Je Hong Park Subject: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-01 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
- [AVTCORE] Comments on the draft-ietf-avtcore-srtp… Woo-Hwan Kim
- Re: [AVTCORE] Comments on the draft-ietf-avtcore-… Igoe, Kevin M.