Subject: [MMUSIC] Question on SDP security parameters

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Nov 2002 10:08:56 -0500

This is a followup to my questions and comments on 
draft-baugher-mmusic-sdpmediasec-00.txt during the mmusic session this 
morning.

It is my understanding that the specification allows for different 
parameters - session parameters, keys, algorithms - on a codec by codec 
basis, within a single media stream. For example, the draft has the 
following example:

  m=audio 49230 RTP/SAVP 96 97 98
    a=rtpmap:96 L8/8000
    a=rtpmap:97 L16/8000
    a=rtpmap:98 L16/11025/2
    a=crypto: transport=RTP/SAVP format=98 format=97
       mkey=(uri)"https://keyserver.com/SDPSeminar/"
    a=crypto: transport=RTP/SAVP format=96 crypto_suite=null

this appears to define a specific key for the two L16 codecs, and no 
security at all for the L8 codec.

My comment was, why do this? Why have different security parameters on a 
codec-by-codec in a single media stream? There are going to be 
complications. The one I mentioned was synchronization. It is possible 
to change codecs dynamically within RTP. This would then seem to require 
a change in the security parameters, including the key itself. How does 
the receiver know that this change has taken place? You can't look at 
the payload type field, since it may have been encrypted.

There will also be complications with offer/answer, which you have 
already stumbled upon.

It would be my proposal that these parameters exist at the media level, 
and apply to all codecs within a stream, or at the session level, in 
which case they apply to all streams which don't have a stream-level set 
of security parameters. This is similar to the way other SDP attributes 
have been done.

This would appear to eliminate the need for the format parameter, and 
possibly the transport parameter (I'm not sure why that was ever there, 
so its hard to say if it can be removed).

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Mark Baugher <[email-masked]>
Date: Tue, 19 Nov 2002 04:17:20 -0800

Thanks for raising this promptly.  My responses are inline.

At 10:08 AM 11/18/2002 -0500, Jonathan Rosenberg wrote:
>draft-baugher-mmusic-sdpmediasec-00.txt during the mmusic session this morning.
>
>codec-by-codec in a single media stream?

I think I made a mistake based on a misconception:  I now see this as a 
single SSRC that has 3 codec alternatives.  Thus, we cannot use a=crypto as 
in the above example because an SRTP cryptographic context is identified by 
the RTP source/destination transport addresses and SSRC, not the payload type.

>There are going to be complications. The one I mentioned was 
>synchronization. It is possible to change codecs dynamically within RTP. 
>This would then seem to require a change in the security parameters, 
>including the key itself. How does the receiver know that this change has 
>taken place? You can't look at the payload type field, since it may have 
>been encrypted.

The PT is not encrypted in SRTP.  But this won't work for SRTP if the codec 
outputs are multiplexed on the same SSRC since an SRTP crypto context is 
not identified by payload type.

>There will also be complications with offer/answer, which you have already 
>stumbled upon.

I admit that.

>and apply to all codecs within a stream, or at the session level, in which 
>case they apply to all streams which don't have a stream-level set of 
>security parameters. This is similar to the way other SDP attributes have 
>been done.

I think you're right.

>possibly the transport parameter (I'm not sure why that was ever there, so 
>its hard to say if it can be removed).

I think you're right about the format parameter.  The transport parameter 
is needed for the case where the a=crypto appears at the SDP session 
level.  That is, we cannot have a session-level a=crypto without 
identifying the transport.  Whether we need a session-level a=crypto is 
something that we should discuss.

thanks, Mark