Re: [secdir] draft-ietf-avt-rtp-g719-04, RTP Payload format for G.719

["Ingemar Johansson S" <[e-mail]>]

Hi

I would spend my 99 cents on alternative 2 below. 

This because I believe it is asking too much from the payload format author to provide with a detailed analysis of threat models and countermeasures (I would not be able to provide with this info).
The drawback with requiring too much of this in each payload format spec is also that people will in the end only copy-paste the text from older specs with the risk that the information is stale or not applicable to the particular codec or usecase. 

One must also keep in mind that it is often not the same people who do the codecs that do the security stuff. For that simple reason it would be better to allow (or maybe require ?) the payload format author to reference to a document that handles these issues. This would help the payload draft writing to become more of an automated process and reduce the time lag from first draft to an RFC.

Regards
Ingemar



> -----Original Message-----
> From: Magnus Westerlund 
> Sent: den 9 december 2008 10:12
> To: Russ Housley
> Cc: Hilarie Orman; Ingemar Johansson S; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Re: [secdir] draft-ietf-avt-rtp-g719-04, RTP Payload 
> format for G.719
> 
> Hi,
> 
> I will add both the AVT chairs and my co-author on 
> draft-ietf-avt-srtp-not-mandatory into this thread. Because 
> it does concern the greater discussion on how to do RTP 
> payload format security consideration sections.
> 
> Russ Housley skrev:
> > I do not see this as a complete solution.  I'd like to see a bit of 
> > discussion about where this mechanism is defined.  Is there 
> an example 
> > of a media stream format that includes authentication?
> 
> I would basically say go read
> http://tools.ietf.org/wg/avt/draft-ietf-avt-srtp-not-mandatory/
> why this turns into a 200-500 word essay assignment. I can do 
> this but the above document has been created to avoid having 
> this happening.
> 
> So SRTP provides authentication in the sense that you can 
> determine if the sender is in the group or outside of it 
> based on if it is keyed or not. If you needed true source 
> authentication then to my knowledge we end up in IPsec or for 
> point to point case TLS/DTLS with or without SRTP  do also 
> work. For RTP mixer and multi-point use cases there is no 
> solution due to that the mixer repackages the material. So 
> the possible trust models prevents true source authentication 
> in this case.
> 
> And to my knowledge there are no format that include 
> authentication, there is one hach by ISMA that provides ADU 
> level encryption in an attempt to do DRM. But they use RTP 
> packet level authentication and I don't think anyone has 
> suggested that you do it at a finer level. If the current 
> text is read to mean that then I would definitely change it.
> Because I don't think the payload format is the right place 
> to do authentication.
> 
> From my perspective we can resolve this in several ways:
> 
> 1. Leave as it is and basically say go find a suitable solution.
> 
> 2. Point to possible solutions in 
> draft-ietf-avt-srtp-not-mandatory with an informative reference.
> 
> 3. List explicitly what potential solutions there are without 
> going into detail, simple provide a list and not comment on 
> when or when they do work. I would also put a disclaimer 
> saying that there might be additional solutions that also can 
> meet the threat model one has.
> 
> 4. Make the essay that tries to provide an overview of the 
> IETF solutions that exist. The big issue is how far into 
> different threat models one can go. If one starts discussing 
> this it is soon a multi-page document in itself.
> 
> 5. I actually uses the template text from 
> http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-howto/
> as that seems to work fine and not be raising objections. At 
> least it went straight through for draft-ietf-avt-rtp-g711wb. 
> The only thing don't covered by the template in my mind is 
> the interleaving issue which is a very minor one.
> 
> I do seem to get some security discussion every time I bring 
> an RTP payload format onto the table. Maybe if I was better 
> at following my own advice in draft-ietf-avt-rtp-howto I 
> would get less issues. It would be good if we could get at 
> least some current agreement about what the right level to 
> discuss issues at are and what additional documentation that 
> do needs to be published so that people doesn't have to 
> repeat it all the time. Even if it needs to be repeated that 
> we agree on some wording that we can put into the template in 
> http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-howto/
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> 

_______________________________________________
secdir mailing list
[e-mail]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/secdir