[AVTCORE] draft-ietf-avtcore-rtp-security-options-07 review

[John Mattsson <[e-mail]>]

Hi,

I reviewed draft-ietf-avtcore-rtp-security-options-07. Sorry for missing the WGLC deadline.

Generally the draft is excellent! Just the kind of document I wish had been available when I read up on RTP security many years ago. I have some comments though:

/John


Comments on draft-ietf-avtcore-rtp-security-options-07
-------------------------------------------------------------------------

- [s2] While the section provides an excellent review of topologies on the RTP user plane, it lacks description of different topologies and trust relationships in the control plane, which very often do not involve the same nodes as the user plane and is equally (or even more) important for the key management. Some information is provided in section 4, but structuring it as in section 2 would be good.

- I suggest slightly refining the sentences about groups with shared security contexts:
[p5] "trusted device that is part of the security context"
[p6] "without needing to be in the security context"
[p6] "needs to be a trusted part of the application security context"
[p7] "that is part of the security context"
[p7] "participants in the group security context"
[p7] "individual sources within the security context"
[p16] "do not include the media server in the security context"
 
At least for SRTP, the identities of the participants are not part of the security context (except maybe for the receiver´s own IP which may be used to identify the context). General suggestions:
"has access/knowledge of the security context"
"is part of/participates in the group sharing the security context"
"needs to be trusted with the security context"

- I would remove the uses of the word symmetric that does not refer to symmetric crypto
[p7] "Thus use of any symmetric security functions fails ..."
[p8] "and a non-symmetrical verification of who sent"

I suggest: 
"Thus use of any group security context fails ..."
"and an individual verification of who sent"

- [p8] The feedback targets FT1 and FT2 in Figure 6 are not mentioned in the text? Why are there exactly 2 and why do they receive traffic from the distribution source?

- [s3.1] The difference between SRTP transforms, SRTP crypto suites, and SRTP protection profiles needs to be explained.
Suggestion:
"SRTP and MIKEY works with transforms where any combination of encryption algorithm, authentication algorithm, and PRF can be used and the authentication tag length can be set to any value. This gives flexibility but requires more security knowledge by the application developer. To simplify things, Security Descriptions and DTLS-SRTP uses SRTP crypto suites and SRTP protection profiles that bundles together transforms and other parameters. This gives less flexibility but it easier to use."

I would recommend that the document first discusses SRTP transforms, and then SRTP crypto suites and SRTP protection profiles.
 
- [p9] "The following transforms are defined..." but then the defined crypto suites are listed...

- [p9] "AES Counter Mode encryption with 128 bits keys combined with 128 bits keyed HMAC-SHA-1 using 80- or 32-bits authentication tags. This is the default cryptographic transform that needs to be supported. Defined in SRTP [RFC3711]."

1. HMAC-SHA-1 uses 160 bit keys so "combined with 160 bits keyed HMAC-SHA-1".
2. 32-bit authentication tags are not default and not mandatory to support.
3. While the mentioned transforms are defined in [RFC3711], the crypto suites were defined in [RFC4568] and the protection profiles in [RFC5764]. 

- [p9] "AES-f8 and HMAC-SHA-1:  AES f8 mode encryption with 128-bits keys combined with keyed HMAC-SHA-1 using 80- or 32-bit authentication. Defined in SRTP [RFC3711]."

While the mentioned transforms are defined in [RFC3711], the crypto suite F8_128_HMAC_SHA1_80 is defined in [RFC4568]. There is no F8_128_HMAC_SHA1_32 crypto suite, and no f8 protection profiles.

- [p9] "The TESLA transform for SRTP is defined in [RFC4383]".
Yes, but if the list is for crypto suites, there are no crypto suites for TESLA (nor protection profile), i.e. you can only use TESLA with MIKEY (or some proprietary protocol). As TESLA is not an ordinary SRTP authentication transforms (it introduces new fields and may be used together with an ordinary SRTP authentication transform), it might be better to describe it in the same part as RFC4771.

- [p9,10] In the bullets on SEED and ARIA. "It has three modes" and "It has also three modes. I know that RFC5669 states that: "We define three modes of running SEED: (1) SEED in counter mode, (2) SEED in counter mode with CBC-MAC" But the word "mode" is a really poor choice (as mode is used to describe blockcipher mode, even it that same sentence) better to use "options", "variants", or "crypto suites".

- [p10] "AES-192 and AES-256:  cryptographic transforms for SRTP based on AES-192 and AES-256 counter mode encryption and 160-bit keyed HMAC-SHA-1 with 80- and 32-bit authentication tags.  Thus providing 192 and 256 bits encryption keys.  Defined in [RFC6188]."

AES-192 and AES-256 are the block ciphers, the transforms would be AES_192_CM and AES_256_CM. Debatable if AES_192_CM and AES_256_CM are different SRTP transforms from AES CM. MIKEY sees them as the AES CM transform with different key lengths. The transforms were defined already in [RFCR3711]. [RFC6188] better describes the use of AES-192, AES-256, provides test data and define the crypto suites. Maybe "Defined in [RFC3711], [RFC6188]"

- [p10] "AES-GCM:  Galois Counter Mode and AES-CCM (Counter with CBC)"
The colon should be moved to include AES-CCM "AES-GCM and AES-CCM:" or "AES-GCM (Galois Counter Mode) and AES-CCM (Counter with CBC-MAC):"
Note that CCM is abbreviation of Counter with CBC-MAC.

- [s3.1] The NULL transforms defined in [RFC3711] should be mentioned somehow.

- [s3.1] The MKI mechanism for rekeying defined in [RFC3711] should be mentioned somehow.

- After "is the most common used" I would suggest adding: 
"AES-GCM, AES_192_CM, and AES_256_CM are expected to gain usage in the future, especially due to the AES- and GCM-specific instructions on new CPUs.

- [s3.1.1, s5.1] I think the texts regarding DTLS-SRTP is a little bit too optimistic, and fails to mention the weaknesses. If used with PKI (or some other trusted third party solution), the security may of course be great, but in practice it is used with self-signed certificates. And while DTLS-SRTP with self-signed certificates might be close to optimal for point-to-point SIP over Internet or WebRTC, it was not chosen because of the perfect security, it was chosen because it offers fair security while not requiring complicated setup or trust in a third party. The normal usage of DTLS-SRTP with self-signed certificates still relies on trust in the signaling or the assumption that nobody was spying during the first call, and for a call over the Internet, you cannot normally make either of these assumptions...

- [p11] "It is mandatory to support in WebRTC"
     -> "to use" or "to support and use"

- [p12] MIKEY might establish a TEK directly without any TGK. Maybe better to just write "cryptographic method used to establish the session keys actually used by the security protocol, like SRTP" Then also change "TGK" to "session key" in the following bullets.

- [p12] Maybe write a little bit more about TICKET. Suggestion:
"TICKET:  [RFC6043] is a MIKEY extension using a trusted centralized key management service (KMS). The Initiator and the Responder do not share any credentials; instead, they trust a third party, the KMS, with which they both have or can establish shared credentials."

- [p13] In the paragraph "MIKEY messages have several ..."
Should mention the application/mikey MIME media type. Suggestion:
"[RFC3830] defines the application/mikey MIME media type allowing MIKEY to be used in e.g. emails and HTTP."

- [p13] In the paragraph "MIKEY with pre-shared ...", it would be good to add:
"IMS media security [T3GPP.33.328] specifies use of the TICKET mode transported over SIP and HTTP."

- [s3.1.3] I suggest adding: "Security Descriptions are used for access protection in IMS Media Security [T3GPP.33.328]."

- [s3.5] I suggest stating that as DTLS build upon TLS, they are almost equivalent from a security perspective (and many other aspects), and then ONLY mention any differences from DTLS.

- [s5] I think IMS media security using Security Descriptions for e2ae security (specified in 3GPP TS 33.328) should be one of examples. The trust and architecture is quite different from SIP over Internet. (If you want I can write the example text).

- [s5.2] Maybe a little bit too detailed; At least the text cannot recommend use of new self-signed certificates each session without discussing the negative security consequences of doing so, i.e. no continuity of authentication. Maybe better to move all privacy discussions to section 4.1.5.

- [s5.3] I would suggest the word "copied" instead of "captured"



Editorial comments on draft-ietf-avtcore-rtp-security-options-07
-------------------------------------------------------------------------

- Varying capitalization/spelling of several terms:
[p4] "Point to point" vs. "point-to-point" 
[p6] "Any source Multicast" -> "Any Source Multicast"
[p7] "Source-Specific Multicast" vs. "Source Specific Multicast" 
[p9] "128 bits keys" vs. "128-bits keys"

- Some figure texts capitalizes first letters in words while others do not.

- [p7] "needs to be trusted device" -> "needs to be a trusted device" or "needs to be trusted"

- [p8] "The goal is to help applications designer by giving reviewing the types of solution that are available."
Something is wrong with this sentence.

- [p9] "membership by not sources" -> "membership but not sources"

- [p13] "It's features" -> "Its features"

- [s5.3] "ISMA Crypt 2.0" -> "ISMACryp 2.0"

- [p28] "[ISMACrypt2]" -> "[ISMACryp2]" And maybe refer to Open IPTV Forum as they are keeping the old ISMA/MPEGIF documents


------------------------------------------------------------------------------------
JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics 
Senior Researcher, Security 

Ericsson AB
Security Research
Färögatan 6
SE-164 80 Stockholm, Sweden
Phone [phone]
SMS/MMS [phone]
john.mattsson at ericsson.com
www.ericsson.com




This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer