Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00

[Woo-Hwan Kim <[e-mail]>]

Hi,

I have some more comments.

For the length of MAC tag of GCM, there is a guidelines in the NIST SP
document.
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf

In Appendix C, constraints with 64 bit tags are suggested, which is
reflecting Ferguson's comment.
(It also specifies SRTP as an example which may be appropriate for short
tags.)

In section 3 of the draft, it is better to address the above rather than
Ferguson's document.

In the previous posting, I wrote on the caption of Figure 6.
I also agree with Westerlund's oipinion because it is necessary to clarify
the difference between GCM and CCM.

> 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.

Thanks,

Woo-Hwan Kim



> Date: Tue, 22 May 2012 14:05:30 +0000
> From: "Wyss, Felix" <[e-mail]>
> To: 'Magnus Westerlund' <[e-mail]>,
>        "'[e-mail]'"
>        <[e-mail]>
> Cc: 'IETF AVTCore WG' <[e-mail]>
> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00
> Message-ID:
>        <[e-mail]
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Magnus Westerlund
> > Sent: Tuesday, May 22, 2012 04:18
> > To: [e-mail]
> > 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
> >
>