Subject: [MMUSIC] SDP security descriptions - updates and open issues in -02

From: Flemming Andreasen <[email-masked]>
Date: Wed, 12 Nov 2003 22:06:16 -0500

Greetings

We submitted an update to the SDP Security Descriptions draft which you
can find at:

 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-02.txt

The draft was reworked to more clearly divide it into two:
- A core security description framework
- An SRTP profile of the security description core.

For each of these, details on high-level operation, parameter
definitions, use with and without offer/answer, and a grammar was
provided. Also, the following more detailed changes were introduced:
- Offer/Answer highlights differences between unicast/multicast, and
initial/subsequent offer.
- Rekeying addressed via offer/answer; everything can be changed (not
just keys)
- Additional rules and considerations for communicating the SRTP SRC
parameter (SSRC, SEQ, ROC).
- Removed SRTP “use” parameter (decryption, encryption or both) - now
inferred from context
- Added Window-Size Hint and <From,To> to SRTP profile
- Extension rules were defined for key methods, SRTP crypto-suites, and
SRTP session parameters
- IANA considerations and registration procedures were added
- Grammar was updated

Finally, in Section 9 (and in a couple of places throughout the
document), we identified the following open issues:

1) The use of security descriptions, and in particular SRTP security
descriptions, with multicast streams where offer/answer is being used is
not well understood and results in several complications.

2) Another aspect related to multicast is the SRC parameter which is
used to instantiate crypto contexts. The question is how this parameter
should be used with multicast streams, and in particular if it should be
allowed to instantiate multiple crypto context. There is also an issue
here in how to deal with "SSRC collisions" which is primarily a concern
for multicast.

3) The security descriptions do not deal with hierarchically encoded
streams (or at least they have not been considered). Note that this is
only an issue for multicast streams.

4) The current mechanism does not allow for a key to be specified as
being an encryption or decryption key or both; instead this is inferred
from the context (e.g. unicast offer).  Should there be a mechanism to
allow a key to be tagged as an encryption, decryption
or both key ? Again, this is mostly seen as an issue for multicast
streams.

Support for multicast streams is at the heart of these issues, and
solving them in a way that is satisfactory to multicast in general is
something the authors believe will require considerable work and result
in a significant delay in progressing the draft. We therefore propose to
restrict the scope of the draft to deal with unicast streams only and
leave support for multicast streams for further study. If there is
sufficient interest in solving all the multicast issues, these can then
be worked on in a seperate document that can still use the general
mechanism defined in the current draft.

Please let us know if you disagree with this proposal.

Thanks and regards

            Flemming, Mark, and Dan

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