Re: [secdir] secdir review of draft-ietf-avt-rtp-h264-rcdo-07

[Patrick Luthi <[e-mail]>]

Tom,

Your proposed text sounds good to me!

Regards,

Patrick

At 13:46 05/11/2010, Tom Kristensen wrote:
>On 11/04/2010 05:31 PM, Scott G. Kelly wrote:
>>I have reviewed this document as part of the security directorate's 
>>ongoing effort to review all IETF documents being processed by the 
>>IESG.  These comments were written primarily for the benefit of the 
>>security area directors.  Document editors and WG chairs should 
>>treat these comments just like any other last call comments.
>>
>>This draft describes a new RTP payload format, extending existing 
>>RTP capabilities. Based on my limited understanding of RTP, this 
>>introduces no new security considerations.
>>
>>The security considerations section starts off by saying this, but 
>>then goes on to talk about various security properties that could 
>>be added by various means. I found the text to be a little 
>>confusing, especially when it makes recommendations without 
>>detailing any particular threats.
>
>I can understand this conclusion. A simplification makes sense as 
>the recommendations given here is described better within a security 
>context in the RTP RFC and associated specifications. However, I'd 
>like to keep the reference to the H.264 security considerations, 
>with its codec specific details. My proposed text for the security 
>considerations at bottom.
>
>>I would suggest simplifying the security considerations. Here is 
>>the current text:
>>
>>    "RTP packets using the payload format defined in this specification
>>     are subject to the security considerations discussed in the RTP
>>     specification [6], and in any applicable RTP profile.  The main
>>     security considerations for the RTP packet carrying the RTP payload
>>     format defined within this document are confidentiality, integrity
>>     and source authenticity.  Confidentiality is achieved by encryption
>>     of the RTP payload.  Integrity of the RTP packets through suitable
>>     cryptographic integrity protection mechanism.  Cryptographic system
>>     may also allow the authentication of the source of the payload.  A
>>     suitable security mechanism for this RTP payload format should
>>     provide confidentiality, integrity protection and at least source
>>     authentication capable of determining if an RTP packet is from a
>>     member of the RTP session or not.
>>
>>     Note that the appropriate mechanism to provide security to RTP and
>>     payloads following this document may vary.  It is dependent on the
>>     application, the transport, and the signalling protocol employed.
>>     Therefore a single mechanism is not sufficient.  Usage of data origin
>>     authentication and data integrity protection of at least the RTP
>>     packet is RECOMMENDED, for example by use of the Secure Real-time
>>     Transport Protocol (SRTP) [12].  Other mechanisms that may be used
>>     are IPsec [13] and Transport Layer Security (TLS) [14] (RTP over
>>     TCP), but other alternatives may exist.
>>
>>     Refer also to section 9 of RFC YYYY [3], as no reasons for separate
>>     considerations are introduced in this document."
>>
>>
>>I would suggest the following simplified text:
>>
>>    "RTP packets using the payload format defined in this specification
>>     are subject to the security considerations discussed in the RTP
>>     specification [6], and in any applicable RTP profile.  No additional
>>     security considerations are introduced by this specification."
>>
>>(or something like this).
>
>I would like to keep the reference to the security considerations 
>section of RFC YYYY/RFC3984bis in, as specific H.264 threats and 
>recommendations are included there. Cf.:
>http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-12#section-9
>
>So, something like this should be fine:
>
>   "RTP packets using the payload format defined in this specification
>    are subject to the security considerations discussed in the RTP
>    specification [6], and in any applicable RTP profile. Refer also
>    to section 9 of RFC YYYY [3]. No additional security
>    considerations are introduced by this specification."
>
>As a side note. One might consider altering the "template security 
>considerations" section in the "How to Write an RTP Payload Format" 
>draft according to the preferred security directorate/IESG policy 
>for the RTP payload format specifications later on. Cf.:
>http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-06#appendix-A.13
>
>-- Tom