[AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 22 May 2012 08:18 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 9230C21F8564 for <avt@ietfa.amsl.com>; Tue, 22 May 2012 01:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.098
X-Spam-Level:
X-Spam-Status: No, score=-106.098 tagged_above=-999 required=5 tests=[AWL=0.151, 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 9mDIwpmOnW7X for <avt@ietfa.amsl.com>; Tue, 22 May 2012 01:18:32 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2723B21F8552 for <avt@ietf.org>; Tue, 22 May 2012 01:18:30 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fac6d000002e89-9b-4fbb4bd56ffd
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3E.F7.11913.5DB4BBF4; Tue, 22 May 2012 10:18:29 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Tue, 22 May 2012 10:18:28 +0200
Message-ID: <4FBB4BD3.9000909@ericsson.com>
Date: Tue, 22 May 2012 10:18:27 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZGfG3Vveq925/gwvTLCxe9qxkt1h7JNGB yWPJkp9MHl8uf2YLYIrisklJzcksSy3St0vgyph1/ANzwYe8ionHrjM2ME4N6GLk5JAQMJF4 dPgUO4QtJnHh3nq2LkYuDiGBU4wSZ+auZARJCAksZ5T4ey8SxOYV0JZ49G42E4jNIqAqcWn2 UVYQm03AQuLmj0Y2EFtUIFjixZ4rrBD1ghInZz5hAbFFBIwkdp5/CRZnFlCSmLv0NXMXIweH sIC5xKuzfBA3SEoc/HeNHaJET2LK1RZGCFteonnrbGaIc7QlGpo6WCcwCsxCsmEWkpZZSFoW MDKvYhTOTczMSS831EstykwuLs7P0ytO3cQIDMeDW37r7mA8dU7kEKM0B4uSOO9mg13+QgLp iSWp2ampBalF8UWlOanFhxiZODilGhhLLVzOnhcO1vG5eGKK+qq3HN7cE9Nfzz2mllVR6hHN slCL4azwtsrSqRwxX3j/XDvx8vrcusqfabdMny45nWx4nvuHMGPENw7GrlOCdX88Nm9Pnrpm 5b1rz//HOttJ/OfzDjjAKnCg9KZNqtg1Hg5m1crco1IzhKb1p/Ozs+cxfepL4rBYsUWJpTgj 0VCLuag4EQCfEFC7FQIAAA==
Cc: IETF AVTCore WG <avt@ietf.org>
Subject: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00
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: Tue, 22 May 2012 08:18:33 -0000
Hi, I got a request to progress this document towards WG last call. So while we chairs are cleaning up some administrative stuff, like getting a milestone in place. I thought the authors should get something to do and thus reviewed the draft. 1) Section 1.1 "Crypto Context For the purposes of this document a crypto context is the outcome of any process which results in authentication of each participant in the SRTP session and possession by each partcipant of a shared secret master key and a shared master salt." What is the definition of participant here, SSRC, endpoint, user, or system? Please correct the "partcipant" spelling error also. 2) Section 1.1, crypto context: " Ciper Contest" I guess should be Crypto Context. 3) Section 1.1. is the text for crypto context really accurate as the document does define protection profiles for both DTLS-SRTP and Security description. 4) I am missing protection profiles for MIKEY. I think they should be defined as MIKEY is the third key-management protocol and are used in a lot of cases which neither DTLS-SRTP and Security Description are suitable for. 5) Section 1.1 Instantiation: "each participant in the SRTP/SRTCP session will need four instantiations of the AEAD algorithm; one for inbound SRTP traffic, one for outbound SRTP traffic source, one for inbound SRTCP traffic, and one for outbound SRTCP traffic source. " Is this really correct. This seems to be limiting the use of AEAD to point to point scenarios? The other crypto transforms for SRTP are capable of handling group scenarios. DTLS-SRTP with EKT for example would allow each end-point to distribute its own master key that it will use for the SSRCs it sends. There are also scenarios where one use a common master key for all participants. 6) Section 1.2: Associated Data This is data that is to be authenticated but not encrypted. In SRTP, the associated data consists of the entire RTP header, including the list of CSRC identifiers (if present) and the RTP header extension (if present), as shown in Figure 3. Shouldn't this point to and discuss the relation to draft-ietf-avtcore-srtp-encrypted-header-ext-01 7. Section 1.2: Associated Data This is data that is to be authenticated but not encrypted. In SRTP, the associated data consists of the entire RTP header, including the list of CSRC identifiers (if present) and the RTP header extension (if present), as shown in Figure 3. Plaintext Data that is to be both encrypted and authenticated. In SRTP this consists of the RTP payload, the RTP padding and the RTP pad count fields (if the latter two fields are present) as shown in Figure 3. The padding service provided by RTP is not needed by the AEAD encryption algorithm, so the RTP padding and RTP pad count fields SHOULD be omitted. Why are these paragraphs not discussing RTCP? 8. Section 1.2.1: (Note that this means that the cipher text will be longer than the plain text by precisely the length of the AEAD authentication tag.) This needs more extensive discussion as it needs to be taken into account in RTP/RTCP when determine packet sizes both for generating right sized RTP that don't violate MTU and that they are included in the RTCP avg_rtcp_size parameter part of the scheduling algorithm. 9. Section 1.2.2: For confirmation: Packet Counter Each AEAD instantiation MUST maintain a 6 octet zero-based packet counter which is incremented each time an SRTP packet is sent. As we shall see below, the packet counter is used to insure each SRTP packet gets a unique initialization vector. Can this use the "ROC" distribution mechanism (RFC4771) or what the key-management provide to correctly deduce the field, or will it have problems with late joiners in a group communication? 10. Section 1.2.2 Packet Counter: "zero-based packet counter" Does this mean that the 6 octet long field is initialized to 0 and thus violate the recommendation of RTP sequence number requirement of random start position. 11. Section 1.5: I don't like using the figure to indicate what is of different types. Two reasons. The first is that it doesn't explicitly enumerate protocol fields, instead 32-bytes octet with fields. Secondly because it make it hard for someone that can't see to correctly interpret this. Think if Sam Hartman would like to read this spec. You made it much more difficult for him. You had a description earlier that with a bit more precision would be correct, after having dealt with comment 6 and what needs to be included due to that. 12. Section 1.6. AEAD Processing of SRTCP Packets All SRTCP packets MUST be authenticated, but unlike SRTP, SRTCP packet encryption is optional. A sender can select which packets to encrypt, and indicates this choice with a 1-bit encryption flag (located in the leftmost bit of the 32-bit word that contains the SRTCP index) I think it is important to write "SRTCP packet" as SRTCP compount packet. As each individual RTCP packet can't be individually encrypted or not in the same compound packet. 13. Section 1.6.1 and 1.6.2. Same as comment 11 on this section. Here you may have to talk about octets as it is defined as the first of 32-bit words of the first RTCP packet part of the compound that are unencrypted. 14. Section 1.8. Prevention of IV Reuse For a given key it is critical that the IV not repeat. This reduces to the problem of insuring neither the Packet Counter nor the SRTCP index do not repeat before the AEAD instantiation is rekeyed. Processing MUST cease if either the 48-bit Packet Counter or the 31-bit SRTCP index cycles back to their initial value. Processing MUST NOT resume until a new SRTP/SRTCP session has been established using a new shared secret master key and shares master salt. Ideally, a rekey should be done well before either of these counters cycle. This section fails to discuss another issue where IV reuse could arise. Namely SSRC collision. If more than a single end-point uses the same SSRC there can be collision. This either put stringent requirements on how one key this crypto transform in different topologies or the usage of SSRC assignment rules. As the later is not really present it might be worth defining rules and be clear on the impact of an SSRC collision. 15. Section 2.1: C_MAX maximum ciphertext MUST be at most 2^16-40 octets length per invocation SHOULD be at least 2232 I think the lower bound reasonsing is flawed. First of all there is RTCP that has only IPv4/UDP + 2 32-bits word of none plaintext RTCP headers thus making it 38 bytes. In addition what about IP Jumbogram (RFC 2675) which support packet sizes of 2^32 bytes. I think the max should be set to what the upper limit where something breaks. Is 2^32 a working limit from crypto perspective, in that case I think you should use that. 16. Minimal value for C_MAX Similarly the lower bound on C_MAX is based on the maximum transmission unit (MTU) of 2272 octets in IEEE 802.11. Because many RTP applications use very short payloads (for example, the G.729 codec used in VoIP can be as short as 20 octets), implementations that only support a maximum ciphertext length smaller than 2232 octets are permitted under this RFC. However, in the interest of maximizing interoperability between various AEAD implementations, the use of C_MAX values less than 2232 is discouraged. I actually think the minimum value should be that a C_MAX value of 2234 MUST be supported. My reasoning is that it must be 2 bytes larger to support full MTU RTCP. Then it really should be a MUST to ensure that one knows that a counter part can support that size of plaintext. I would like to point out that the current key-management systems aren't the greatest for negotiating a lot of sub-parameters. For example my understanding is that DTLS-SRTP only support negoptiating whole profiles, not sub-parameters at all. So if you are not specifying a hard limit what packet size a receiver must support how do you know that you can interoperate? At the same time I realize that this is not optimal for a very constrained device that sends encrypted real-time payloads of some type that are much smaller and actually don't have the buffering space for so large packets. Maybe the way forward is to separate the C_max value boundary and the minimal value supported for the defiended profiles and make it clear that the protection profiles defined in 2.2 and 2.3 actually requires a C_max that is 2234. 17. Section 2.1: For sake of clarity we specify two additional parameters: Authentication Tag Length MUST be either 8, 12, or 16 octets Maximum number of invocations MUST be at most 2^48 for SRTP for a given instantiation MUST be at most 2^31 for SRTCP As these parameters are for AEAD algorithms in general, how can you be certain that no one likes an authentication tag length longer than 16 bytes or for that matter one that is 14 bytes? I guess the maximum number of invocations also comes from an assumption around the IV construction. Which I am not certain holds as you clearly defined the IV specifically for the algorithms and other AEAD algorithms can make a different choice for IV including an explicit one, can't they? Thus does these max values really hold? 18. Section 2.2 In addition to the Packet Counter used in the formation of IVs, each instantiation of AES-GCM has a block counter which is incremented each time AES is called to produce a 16-octet output block. I would prefer that you where more explicit about the lenght of the block counters length, i.e ... AES-GCM has a block counter (32-bit) which ... This also applies to the corresponding text in 2.3. 19. Section 2.3: For AES-CCM in SRTP/SRTCP, the flag octet has the hex value 5A if an 8-octet authentication tag is used, 6A if a 12-octet authentication tag is used, and 7A if a 16-octet authentication tag is used. The flag octet is one of the inputs to AES during the counter mode encryption of the plaintext. Considering that the table only defines the modes that has 16-octet auth tags, whats the point of mentioning the other lengths? 20. Section 4: RFC 4568 defines SRTP "crypto suites" I would prefer that one instead of just using the "RFC 4568" as handle to the specification instead included the title or an abbreviated one at least. Like this: Security Descriptions [RFC4586] defines SRTP "crypto suites" This I think is much more clear as I don't have to go to the reference section if I don't directly remember what the RFC number is. 21. Section 4: RFC 4568 defines SRTP "crypto suites"; a crypto suite corresponds to a particular AEAD algorithm in SRTP. In order to allow SDP to signal the use of the algorithms defined in this document, IANA will register the following crypto suites into the subregistry for SRTP crypto suites under the SRTP transport of the SDP Security Descriptions: srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / "AEAD_AES_256_GCM" / "AEAD_AES_128_GCM_8" / "AEAD_AES_256_GCM_8" / "AEAD_AES_128_GCM_12" / "AEAD_AES_256_GCM_12" / "AEAD_AES_128_CCM" / "AEAD_AES_256_CCM" / Igoe and McGrew Informational [Page 15] Internet Draft AES-GCM and AES-CCM for SRTP Feb 17, 2012 srtp-crypto-suite-ext I don't think this fulfills the registration requirement in that it hasn't made it clear how the key-salt structure for inline method are constructed. How many bits of keys, and how many bits of salt is to be included in the structure. 22. Section 4: When it comes to DTLS-SRTP the protection profiles defined in RFC 5764 has the following information defined in its section 4.1.2 SRTP_AES128_CM_HMAC_SHA1_80 cipher: AES_128_CM cipher_key_length: 128 cipher_salt_length: 112 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 80 I believe this information is present, but maybe it should be collected together. It also doesn't define how the AEAD parameters defined in this specification actually are parameterized when needed. 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 ----------------------------------------------------------------------
- [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes… Magnus Westerlund
- Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp… Wyss, Felix
- Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp… Woo-Hwan Kim
- Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp… Woo-Hwan Kim