Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00
"Wyss, Felix" <Felix.Wyss@inin.com> Tue, 22 May 2012 14:05 UTC
Return-Path: <Felix.Wyss@inin.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 8CFC921F85F1 for <avt@ietfa.amsl.com>; Tue, 22 May 2012 07:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 I4f7He1TTbe5 for <avt@ietfa.amsl.com>; Tue, 22 May 2012 07:05:33 -0700 (PDT)
Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by ietfa.amsl.com (Postfix) with ESMTP id AD32C21F85DD for <avt@ietf.org>; Tue, 22 May 2012 07:05:32 -0700 (PDT)
Received: from hub1.i3domain.inin.com [172.17.60.36] by smtpedge.inin.com - Websense Email Security (7.3.0); Tue, 22 May 2012 10:05:30 -0400
Received: from MAILDB2.i3domain.inin.com ([fe80::1c14:d969:a21a:e887]) by Hub1.i3domain.inin.com ([fe80::fc5a:f565:b6c5:4f42%11]) with mapi id 14.01.0289.001; Tue, 22 May 2012 10:05:31 -0400
From: "Wyss, Felix" <Felix.Wyss@inin.com>
To: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, "'draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org'" <draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org>
Thread-Topic: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00
Thread-Index: AQHNN/OQaXHhEAzfokaQDbHlzpg6eJbV0dzw
Date: Tue, 22 May 2012 14:05:30 +0000
Message-ID: <E314A44C69CF594E89147F3BEFE3ADF943ACB678@MAILDB2.i3domain.inin.com>
References: <4FBB4BD3.9000909@ericsson.com>
In-Reply-To: <4FBB4BD3.9000909@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.17.101.222]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1
X-SEF-Processed: 7_3_0_01181__2012_05_22_10_05_30
Cc: 'IETF AVTCore WG' <avt@ietf.org>
Subject: Re: [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 14:05:34 -0000
Furthermore, the issues raised in the following document should be addressed in section #3: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf It basically means the modes with authentication tags smaller than 16 octets MUST NOT be used with AES-GCM. In light of that, I question the value of supporting a GCM based mode for SRTP. Thanks, --Felix > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: Tuesday, May 22, 2012 04:18 > To: draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org > Cc: IETF AVTCore WG > Subject: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00 > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt
- [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