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