Re: [AVTCORE] WGLC on Encryption of Header Extensions in SRTP

[Magnus Westerlund <[e-mail]>]

Hi,
(as individual)

I done a review and found the following issues that I believe should be
addressed prior to requesting publication of this document. I do support
the publication of this document when the issues has been addressed.


1. Title:

Encryption of Header Extensions in the Secure  Real-Time Transport
                            Protocol (SRTP)

Contains spurious space between Secure and Real-Time.

2. Section 1 and ref-list:
The client-mixer and mixer-client audio levels references need to be
updated to the RFCs. Also the reference to the AES-GCM draft needs to be
updated.

3. Section 3.
   For SRTP encryption transforms that operate by generating a
   keystream, a header keystream is generated for each packet containing
   an encrypted header, using the same encryption transform and
   Initialization Vector (IV) as is used for the SRTP payload, except
   that the SRTP encryption and salting keys k_e and k_s are replaced by
   the SRTP header encryption and header salting keys k_he and k_hs,
   respectively.

I wished this section used; SHALL use the same encryption transform to
further enforce and clarify this. This is of high importance both from
security perspective and the avoidance of any new crypto suit parameters
that would need to be retroactively fit to the key-managagement systems.

4. Section 3.

Due to the requirement on any SRTP crypto suit that doesn't generate a
keystream to specify how the header encryption transform is uniquly
determined based on the selected crypto suit I do think this document
may in fact have to update RFC 3711.

That would mean the following additions to the draft.

1. Updates in front page header
2. Explicit mention it in introduction and header.
3. Add a section that makes clear what the additional requirements this
document put on the crypto suite rules defined in RFC 3711.

5. Section 3.
"... for each packet containing
   an encrypted header, ..."

Is really singular form the right form here. As there might be one or
more header extensions that are included in the given packet? For me
"encrypted headers" seems more accurate.

6. Section 3.
   For those octets indicated in the encryption mask, the SRTP
   participant bitwise exclusive-ors the header extension with the
   keystream to produce the ciphertext version of the header extension.

Although the above sentence is correct it appears to me a bit easy to
misunderstand as it is not the straightforward method of doing it. To me
you take the header mask and AND it with the header extension keystream
generated for this packets IV. Then you take that masked keystream and
XOR with the plaintext header extensions to create the cipher text. The
below is missing one step in that process.

   Those octets not indicated in the encryption mask are left
   unmodified.  Thus, conceptually, the encryption mask is logically
   ANDed with the keystream to produce a masked keystream.  The sender
   and receiver MUST use the same encryption mask.  The set of extension
   elements to be encrypted is communicated between the sender and the
   receiver using the signaling mechanisms described in Section 4.

The MUST in the above also seems a bit strange. They should be the same
if both the encryptor and the decryptor are equally configured. So I
don't see how this is something that can be mandated to work, at least
not without a specification part that says how this is ensured.

7. I wonder if there should be any mentioning that also non RFC 5285
header extensions can also not be protected. Along these lines shouldn't
the 3.1 section example actually contain the first RFC 3550 header
extension word including the keyword. Otherwise if one takes the RFC
3550 definition of header extension and apply the mask as outlined, your
off-set with 4 bytes.

8. Section 4.

So if I understand this specification correctly, the header extensions
can only be encrypted by also encrypting the full RTP payload. The
combination of encrypting a header extension but not the payload is not
possible as the crypto algorithm for the encryption in that case would
be NULL. Does this need to be pointed out?

9. Section 4.
Shouldn't there be ABNF for the specific usage of the extension
attribute that this document usages?

What I can see the proposal will clearly fall into the allowed syntax by
RFC 5285, however, shouldn't one clarify that

extensionattributes = byte-string
                    / enc-extensionattributes

enc-extensionattributes = extensionname [SP extensionattributes]

10. Section 4.1:
(Note that, as always, users of best-
   effort encryption MUST be cautious of bid-down attacks, and ensure,
   for example, that signaling is integrity-protected.)

I think a reference to an explanation of bid-down attack would be good.
Or alternatively some more words on the attack. I also think there needs
to be discussion on what type of integrity protection you actually need
to prevent that. And the answer there is that is depends on the threat
model if it needs to be end-to-end or can be hop by hop.

11. Section 5:
   If a middlebox does not have access to the SRTP authentication keys,
   it has no way to verify the authenticity of unencrypted RTP header
   extension elements (or the unencrypted RTP header), even though it
   can monitor them.  Therefore, such middleboxes MUST treat such
   headers as untrusted and potentially generated by an attacker.

I am curious of the MUST here. It seems strange. If you are a middlebox
and you don't have access to the security context for this stream. Why
should the header extensions be treated differently than non integrity
protected packets? They are equally vulnerable from an attack
perspective. I think the warning is good, but is the MUST really warranted?

12. Section A.

As a warning. I haven't checked these values. Has anyone beyond the
author sat down and made the calculations?

Cheers

Magnus


On 2012-02-17 14:09, Roni Even wrote:
> Hi,
> 
> I would like to start a WGLC on  Encryption of Header Extensions in the
> Secure  Real-Time Transport  Protocol (SRTP) in
> http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-header-ext-01
> 
>  
> 
> This is the abstract of the draft:
> 
>  
> 
> "The Secure Real-Time Transport Protocol (SRTP) provides  authentication, but not encryption, of the headers of Real-Time Transport Protocol (RTP) packets.  However, RTP header extensions may  carry sensitive information for which participants in multimedia  sessions want confidentiality.  This document provides a mechanism,  extending the mechanisms of SRTP, to selectively encrypt RTP header  extensions in SRTP."
> 
>  
> 
>  
> 
> Please send any comments  by March 8^th .
> 
>  
> 
> Thanks
> 
> Roni Even
> 
>  
> 
>  
> 


-- 

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