[AVTCORE] Comments on draft-ietf-avtcore-aria-srtp-01

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed  draft-ietf-avtcore-aria-srtp-01 and have some comments.
Please review these and don't hesitate to ask for clarification or
disagree with them.

1) Section 2:
                                                              (1) ARIA
   in Counter Mode, (2) ARIA in Counter with CBC-MAC (CCM) Mode and (3)
   ARIA in Galois/Counter Mode (GCM).

As you in the next heading are using ARIA-CTR shouldn't (CTR) be added
as acronym for (1)?

2) Section 2.1 and 4:

What are the security implications of using a 256 bit key length for the
crypto but have as weak integrity protection as SAH1 32 bits? I think
you need to discuss the implications of this, it doesn't appear to be
particular balanced.

3) Section 2.2:

   The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use
   of AES-GCM and AES-CCM with SRTP.  The use of ARIA-CCM and ARIA-GCM
   with SRTP is defined the same as that of AES-CCM and AES-GCM.

Looking in AES-GCM it appears to define a generic AEAD procedures for
SRTP cipher suits. Can you please be more explicit and clear on how you
use that generic procedure?

4) Section 2.1, 2.2:

These procedures are define by reference to existing algorithms like
these sentences:

    ARIA counter modes are
   defined in a similar manner, and are denoted by ARIA_128_CTR,
   ARIA_192_CTR and ARIA_256_CTR respectively, according to the key
   lengths.  The plaintext inputs to the block cipher are formed as in
   AES-CTR(AES_CM, AES_192_CM, AES_256_CM) and the block cipher outputs
   are processed as in AES-CTR.

   The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use
   of AES-GCM and AES-CCM with SRTP.  The use of ARIA-CCM and ARIA-GCM
   with SRTP is defined the same as that of AES-CCM and AES-GCM.

I think using words as "similar" and not being very explicit about what
procedures from the other specification that applies here provide some
risk for misunderstanding. I hope you can be more explicit and clear on
which procedures and usage are applicable.

5) Section 3):
The ARIA-
   CTR PRF is defined in a similar manner, but with each invocation of
   AES replaced with an invocation of ARIA.

Similar to the above comment, using "similar" rather than same. Please
be normative defining here.

6) Cipher suit definitions:

According to Section 8.2 of RFC 3711 the following parameters are
defined and have the specified default values:

   Parameter                     Mandatory-to-support    Default
   ---------                     --------------------    -------

   SRTP and SRTCP encr transf.       AES_CM, NULL         AES_CM
   (Other possible values: AES_f8)

   SRTP and SRTCP auth transf.       HMAC-SHA1           HMAC-SHA1

   SRTP and SRTCP auth params:
     n_tag (tag length)                 80                 80
     SRTP prefix_length                  0                  0

   Key derivation PRF                 AES_CM              AES_CM

   Key material params
   (for each master key):
     master key length                 128                128
     n_e (encr session key length)     128                128
     n_a (auth session key length)     160                160
     master salt key
     length of the master salt         112                112
     n_s (session salt key length)     112                112
     key derivation rate                 0                  0

     key lifetime
        SRTP-packets-max-lifetime      2^48               2^48
        SRTCP-packets-max-lifetime     2^31               2^31
        from-to-lifetime <From, To>
     MKI indicator                       0                 0
     length of the MKI                   0                 0
     value of the MKI

Are really these default value correct for these cipher suits. For
example is still a 112 bit salt used for 256 bits keylengts? For
ARIA_256_CTR clearly the key derivation PRF is not AES_CM?

Thus I would suggest that you include the actual tables for the
different cipher suits that you define with their relevant values.

7) Section 5.

A) I would suggest creating different sub-section for each registry that
is being manipulated.

B) You are not providing the explicit names for the IANA Registries that
you are adding into. Please go to IANA and copy and paste the names from
the relevant registries into IANA section.

For example:

IANA is requested to add the below crypto suites to the "SRTP Crypto
Suite Registrations" created by [RFC4568], at time of writing located on
the following IANA page:
http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xml#sdp-security-descriptions-3

Thus making it very clear which registry the listed values should be
added to.

8) Section 5:

Looking in RFC 5764 in Section 4.1.2 the registered SRTP protection
profiles for DTLS each have a block defined like this:

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

See also the AES-GCM draft that also includes tehm including some AEAD
specifics like this one:

 AEAD_AES_256_GCM_8
        cipher:                 AES_256_GCM
        cipher_key_length:      256 bits
        cipher_salt_length:     96 bits
        aead_auth_tag_length:   8 octets
        auth_function:          NULL
        auth_key_length:        N/A
        auth_tag_length:        N/A
        maximum lifetime:       at most 2^31 SRTCP packets and
                                at most 2^48 SRTP packets

I would recommend that you add these.

9) Section 5:

   [RFC3830] and [RFC5748] define encryption algorithms and PRFs for the
   SRTP policy in MIKEY.  In order to allow the use of the algorithms
   defined in this document in MIKEY, IANA is requested to allocate the
   following numbers in the MIKEY sub-registries.

                       SRTP Enc. alg  | Value
                       ----------------------
                       NULL           |     0
                       AES-CM         |     1
                       AES-F8         |     2
                       SEED-CTR       |     3
                       SEED-CCM       |     4
                       SEED-GCM       |     5
                       ARIA-128-CTR   |     6 (NEW)
                       ARIA-128-CCM   |     7 (NEW)
                       ARIA-128-GCM   |     8 (NEW)
                       ARIA-128-GCM-8 |     9 (NEW)
                       ARIA-128-GCM-12|     10 (NEW)

                Figure 4: Figure 1 from RFC 5748 (revised)

A) Please don't suggest new values that hasn't been formally assigned
yet, better to write them as TBA or TBD (To Be Assigned / Decided).

B) To my understanding with MIKEY's structure the above registry
(Encryption algorithm (Value 0)) actually should not include the
key-length as that is a separate parameter in MIKEY. See MIKEY Security
Protocol Parameters on the
http://www.iana.org/assignments/mikey-payloads/mikey-payloads.xml IANA page.

C) You should definitely look at the AES-GCM drafts IANA section,
especially Section 14.3:

14.3. MIKEY

   In accordance with "MIKEY: Multimedia Internet KEYing" [RFC3830],
   IANA maintains several Payload Name Spaces under Multimedia Internet
   KEYing (MIKEY).  This document requires additions to two of the lists
   maintained under MIKEY Security Protocol Parameters.

   On the SRTP policy Type/Value list (derived from Table 6.10.1.a of
   [RFC3830]) we request the following addition:

      Type | Meaning                         | Possible values
      ----------------------------------------------------------------
       TBD | AEAD authentication tag length  | 8, 12, or 16 (in octets)


   On the Encryption Algorithm List (derived from Table 6.10.1.b of
   [RFC3830]) we request the following additions:

       SRTP encr alg. | Value | Default Session Encr. Key Length
       -----------------------------------------------------------
         AES-CCM      |  TBD  |        16 octets
         AES-GCM      |  TBD  |        16 octets

   The SRTP encryption algorithm, session encryption key length, and
   AEAD authentication tag values received from MIKEY fully determine
   the AEAD algorithm (e.g., AEAD_AES_256_GCM_8).  The exact mapping is
   described in section 15.


10) Test Vectors
Have you considered including test vectors like RFC 6188?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------