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

[Magnus Westerlund <[e-mail]>]

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