Date: Tue, 22 May 2012 10:18:27 +0200
From: Magnus Westerlund <magnus.westerlund <at> ericsson.com>
To: draft-ietf-avtcore-srtp-aes-gcm <at> tools.ietf.org
Cc: IETF AVTCore WG <avt <at> ietf.org>
Subject: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-00
Message-ID: <4FBB4BD3.9000909 <at> ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"

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 <at> ericsson.com
----------------------------------------------------------------------



------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt


End of avt Digest, Vol 97, Issue 11
***********************************