Subject: [AVTCORE] Re: Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03

From: Woo-Hwan Kim <[email-masked]>
Date: Tue, 4 Dec 2012 13:31:53 +0900

Hi.

Here are some comments on draft-ietf-avtcore-srtp-aes-gcm-03

1. Typos

Sec. 5.3
- Validation Error flag raised =>  Validity_Flag is to be FALSE

Sec. 6
- the plaintext to form cipher => the plaintext to form ciphertext
- this apllication => this application
- A (first_key_block, keystream) pair => A (first_key_block, key_stream)
pair
- These keystream generation processes allows for => These keystream
generation processes allow for
- up to (2^24)-16 octets for AES-CCM and => up to (2^28)-16 octets for
AES-CCM and

Sec. 7
- AEAD_AEC => AEAD_AES

Sec. 8.1
- the older authentication methods redundant => the older authentication
mechanisms redundant
- Some applications use the SRTP/SRTCP Authentication Tag as => Some
applications use the SRTP/SRTCP authentication tag field as

Sec. 8.2
- Neither AES-GCM not AES-CCM => Neither AES-GCM nor AES-CCM
- RECOMENDED => RECOMMENDED

Sec. 9.1
- used by both AES-GCM and AES-CCM SRTP is => used by both AES-GCM and
AES-CCM in SRTP is
- and the two octet sequence number SEQ. => and the 2-octet sequence number
SEQ.

Sec. 9.2 & 10.2
- AEAD cipher, ~containing the cipher, the resulting cipher => AEAD
ciphertext, ~containing the ciphertext, the resulting ciphertext

Sec. 9.2, 10.2 & 10.3 (similar meaning, different writing)
- The data fields within the SRTP packets are broken into Associated Data,
Plaintext and Raw Data as follows (see figure 2):
- the SRTCP packet is broken into plaintext, associated data, and raw
(untouched) data as listed below (see figure 4):
- the SRTCP compound packet is broken into plaintext, associated data, and
raw (untouched) data as follows (see figure 5):

Sec. 10.3
- returns a cipher field which ~, This cipher ~, the Encryption flag => a
ciphertext which ~, This ciphertext ~, the encryption flag

Sec. 11.1
- GCM: MUST be at most 2^36-16 octets CCM: MUST be at most 2^24+16 octets
=> GCM: MUST be at most 2^36-32 octets CCM: MUST be at most 2^28-16 octets

Sec. 11.2 & 11.3
- Any implementation of AES-GCM(AES-CCM) SRTP SHOULD ~ => Any
implementation of AES-GCM(AES-CCM) in SRTP SHOULD ~

Sec. 11.3
- in counter node encryptionn, AES-CCM authentications also useus => ~ in
counter mode encryption, AES-CCM authentications also uses ~

Sec. 12
- AEAD_AES_128(256)_CCM(GCM) algorithms => AEAD_AES_128(256)_CCM(GCM)

Sec. 13.1
- after each block key has => after each encryption key has

2. Editing
Sec. 1 3rd and 4th paragraphs

- In 3rd paragraph, 2nd sentence 'Two families of ~ based upon AES.' is
repeated in 4th paragraph.
So it may be better to remove this sentence, and to modify the last
sentence as follows:
'This specification uses GCM and CCM with AES, which we call AES-GCM and
AES-CCM respectively)'

Sec. 8.1 1st and 2nd sentences

When an AEAD algorithm is used for SRTP/SRTCP, the AEAD message
authentication mechanism MUST be the primary message authentication
mechanism.

3. Length vs Size

It may be good to unify the words 'length' and 'size'

4. CCM authentication tag length

Though the CCM specification adapted by NIST and IETF uses the tag length
to format the message,
basically there is no difference between CCM and GCM to deal with
authentication tag length.
As GCM, CCMs with different tag length (ex. CCM_8, CCM_12) should be
considered separately.
AEAD Parameters managed by IANA also show it.

In addition, it is not necessary to consider the capability of handling
variable-length authentication tags
because this draft restricts the length of authenticated tag to be 8, 12,
or 16.
And tag length should be shared by key manage process based on SDES, DTLS
or MIKEY.
Though MIKEY explicitly supports authentication tag length parameter as
specified in Section 14.3,
SDES and DTLS do not.
Instead, the choice of cipher suite (or protection profile) implies the
authentication tag length directly.
So I think that cipher suites for SDES should be corresponded to protection
profiles for DTLS,
and that is the reason why I recommend to add cipher suites of CCM with
authentication tag length 8 and 12.

Because the authentication tag length is shared during key and parameters
negotiation,
I think that Encrypt/Decrypt mode described in Section 5.2 does not need to
use the term 'Tag_Size_Flag' explicitly.
The above also holds for the Decrypt Mode in 5.2.2.

Thanks.

Best Regards,

Woo-Hwan Kim

> Date: Tue, 27 Nov 2012 15:20:46 +0100
> From: Magnus Westerlund <[email-masked]>
> To: IETF AVTCore WG <[email-masked]>
> Subject: [AVTCORE] Working group last call on
> draft-ietf-avtcore-srtp-aes-gcm-03
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> WG,
>
> This announces the WG last call on AES-GCM and AES-CCM Authenticated
> Encryption in Secure RTP (SRTP)
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/
>
> Please provide any comments no later than the 12th of December. Also
> comments of the nature of "I have read it and have no comments and think
> it should be published" are highly valuable.
>
> 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: [email-masked]
> ----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Dec 2012 14:25:39 +0100

WG, Authors

EKR, please look at issue 8 and 16 below.

> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/

I have made a personal review of this document. My comments are the
following. I have not checked for overlap with already made comments.

1) In the front page header: "Intended Status: Informational" Please
change this to standards track.

2) Section 1: The first mentioning of SRTP, RTP etc should have
references, that also applies to AES and the AES-GCM, AES-CCM.

3) Section 4)

      Instantiation   In AEAD, an instantiation is an (Encryption_key,
                      salt) pair together with all of the data
                      structures (for example, counters) needed for it
                      to function properly.  In SRTP/SRTCP, each
                      endpoint will need two instantiations of the AEAD
                      algorithm for each master key in its possession,
                      one for SRTP and one for SRTCP.

When reading this I got hang up on this. I realized why when getting
further one. First of all I had forgotten about the fact that the SSRC
is provided at invocation time through the IV, rather than at
Instantiation. So I don't think this text is wrong, I think the issue
might be in Section 3, that needs an bullet 4 that maps down to
invocation level by making clear that a particular packet is processed
by forming the IV for that packet using SSRC, Roll-over counter and SSRC
combined with selecting the instantiation that is relevant for this packet.

4) Section 6.
   In both GCM and CCM, each outbound packet uses a 12-octet IV and an
   encryption key to form two outputs, a 16-octet first_key_block which
   is used informing the authentication tag and keystream of octets
   which is XORed to the plaintext to form cipher.

I guess "informing" should be "in forming"? Is a "the" needed before
"keystream"?

5) Section 6:
   When GCM is used, the concatenation of a 12-octet IV, with a 4-octet
   block counter forms the input to AES.  This is used to build a
   key_stream as follows:

Please add a forward pointer to where the IV is defined.

6) Section 6, page 7: The example code, is clearly not full code, but
does it allow usage of some commonly available code? If so I think the
authors needs to consider if they can offer this code as "Code
component" following the IPR license from the trust for Code Components.
Please see:
http://trustee.ietf.org/license-info/

7. Section 6,
   These keystream generation processes allows for a keystream of length
   of up to (2^24)-16 octets for AES-CCM and up to (2^36)-32 octets for
   AES-GCM.

I wonder if the decimal values should be included in the above sentence
to ease for humans.

8. Section 8.1. SRTP/SRTCP Authentication Field

I think this section is attempting the wrong approach to this issue.
First of all as the algorithms include authentication I think they
fulfill the mandates from SRTP on requiring authentication on RTCP.
Secondly, I think the right approach to deal with the issue that you
have no data is to have the algorithms define there usage of the
authentication tag to be zero length. All the defined algorithm
identifiers includes both key lengths and auth tag lengths. Thus writing
this as "SHOULD NOT" is very strange, as all the other CIPHERS include
the encryption + authentication with one ID. This one is no different.

This would then have implications on Section 9.2, 10.3, etc which
mentions this field.

9. Section 9.2 and 9.3: please consider to use some separator between
the defined term and the definition, like:

    Counter Management: A rekey MUST be performed to establish a new
                        master key before the (ROC,SEQ) pair cycles back
                        to its original value.

10. Section 9.3:
     SSRC Management    The set of all SSRC values must be partitioned
                        into disjoint pools, one pool for each endpoint
                        using the master key to originate outbound
                        data.  Each such endpoint MUST only issue SSRC
                        values from the pool it has been assigned.
                        Further, each endpoint MUST maintain a history
                        of outbound SSRC identifiers that it has issued
                        within the lifetime of the current master key,
                        and when a new synchronization source requests
                        an SSRC identifier it MUST NOT be given an
                        identifier that has been previously issued.  A
                        rekey MUST be performed before its pool of SSRC
                        values is exhausted.

I wonder if one should specifically discuss the cases where each
end-point has its own master key and thus can use any SSRC value from a
crypto perspective. This clearly apply to Security Description and
DTLS-SRTP.

11. Section 10.1:

                  0  1  2  3  4  5  6  7  8  9 10 11
                +--+--+--+--+--+--+--+--+--+--+--+--+
                |00|00|    SSRC   |00|00|0+SRTCP Idx|---+
                +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                        |
                +--+--+--+--+--+--+--+--+--+--+--+--+   |
                |         Encryption Salt           |->(+)
                +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                        |
                +--+--+--+--+--+--+--+--+--+--+--+--+   |
                |       Initialization Vector       |<--+
                +--+--+--+--+--+--+--+--+--+--+--+--+

Please clarify in this figure and text above that the Salt is the one
derived for the SRTCP.

12. Section 10.1:

   Using the terminology of section 8.2.1.  of [GCM], the first eight
   octets of the IV are the fixed field and the last four octets are the
   invocation field.

As I haven't look at the ref, this might be correct. But compared to the
definition of Invocation in Section 3:

      Invocation      SRTP/SRTCP data streams are broken into packets.
                      Each packet is processed by a single invocation of
                      the appropriate instantiation of the AEAD
                      algorithm.

This can't be correct. As an end-point can use multiple SSRC
simultaneously, it looks like the SSRC should be considered an
Invocation field, or?

13.  Section 11.1:

The lower bound on C_MAX is obtained by subtracting
   away a 20-octet IP header, 8-octet UDP header, and 12-octet RTP
   header from the maximum transmission unit (MTU) of 2272.

Who's MTU is 2272? Considering SRTP I don't think there is any
definition of "THE MTU" as stated in the above sentence.

14. Section 11.3

In addition to the flag octet used in counter node encryptionn,
   AES-CCM authentications also useus a flag octet that conveys
   information about the length of the authentication tag, length of the
   block counter, and presence of additional authenticated data (see
   section 2.2 of [RFC 3610]).

"counter node encryption" I guess this should be "mode"

15. Section 14.2:

   AEAD_AES_128_CCM_8
        cipher:               AES_128_CCM
        cipher_key_length:    128 bits
        cipher_salt_length:   96 bits
        maximum lifetime:     at most 2^31 SRTCP packets and
                              at most 2^48 SRTP packets

Shouldn't this read for cipher: AES_128_CCM_8?

Same errors exist for all the shorter tag lengths.

16.
  AEAD_AES_128_CCM
        cipher:               AES_128_CCM
        cipher_key_length:    128 bits
        cipher_salt_length:   96 bits
        maximum lifetime:     at most 2^31 SRTCP packets and
                              at most 2^48 SRTP packets

Shouldn't these definition include the following values also:

auth_function: NULL
auth_key_length: 0
auth_tag_length: 0

Thus completing the definitions that you are not using the regular
authentication tag length?

That was all.

I think there is some few issues that absolutely must be sorted out
before publishing this document. But I think it is in fairly good shape.
I would expect a second WG last call on the changes before we proceed.
But lets start with discussing the changes.

Cheers

Magnus Westerlund

Färögatan 6                | Mobile +46 73 0949079