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

[Russ Housley <[e-mail]>]

I'm happy to see the draft-ietf-avt-srtp-not-mandatory coming 
along.  I do not want to hold this document to wait for it. I do not 
know what others think, but either 3 or 5 would work for me.

Russ


At 04:11 AM 12/9/2008, Magnus Westerlund wrote:
>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