SDP Security Descriptions for Media Streams draft-ietf-mmusic-sdescriptions-02.txt November 14, 2003 Flemming Andreasen Mark Baugher Dan Wing

Overview of Changes Recap: –Establish secure media streams by sending security descriptions with ciphers, keys, etc. in SDP Generalize into a core framework and an SRTP- specific part: –High-level Operation and parameter definition –Use with Offer/Answer –Use outside Offer/Answer –Grammar Numerous editorial changes throughout

More Detailed Changes 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 to SRTP profile

More Detailed Changes, cont. Extension rules: –Key methods (general) –SRTP crypto-suites –SRTP session parameters IANA considerations and registration procedures Updated grammar

Open Issues Multicast streams SRC Parameter (SSRC, ROC, SEQ) Hierarchical/layered encoding schemes “Use” parameter to specify encryption, decryption or both

Issue #1 - Multicast Streams Several problems: –Shared key versus per-participant specific key. –When key is shared we must ensure unique SSRCs: problematic unless we have other means available to ensure this (cf. issue #2 which has more multicast problems) –If per-participant specific key, then sdescriptions will need each participant to convey its key separately –Support for hierarchical/layered encoding schemes Unclear there is a single good solution for all of these that would work well across all multicast usage scenarios. Proposal:Leave multicast streams for further study.

Issue #2 - SRC Parameter Unique SSRC needed when master key is shared to prevent two-time pad issue ROC and SEQ needed for successful authentication and decryption but can in general not be derived algorithmically from the SRTP stream alone: –Consider a participant joining an existing session –Consider what happens when initial sequence number is close to wrapping and first few packets are lost SRC Parameter contains one or more of: –SSRC:Identifies the crypto context –Roll Over Counter (ROC) and Sequence Number (SEQ): Signals the current ROC and SEQ for a crypto context

Issue #2 - SRC parameter, cont. What does it mean to signal an SRC parameter ? –Meaning of SRC parameter is to instantiate a crypto context –In the multicast case, should we allow this as a way of instantiating crypto contexts for all the participants: Scaling issues - where do we draw the line ? Only works when key is shared between participants –Alternatively, should sdescriptions only be allowed to instantiate a single crypto context: Each participant will then have to send its own sdescription (which may or may not use a unique key) Should suffice for unicast (unless you want to have multiple SSRCs for a unicast session) For unicast, use of different encryption and decryption keys negates need for the SSRC part of the parameter.

Issue #2 - SRC parameter, cont. Handling “SRC collisions”, i.e. signaled SSRC collides with existing SSRC: –Currently, we simply reject such offers. –Would be nice if offerer understood why offer was rejected (especially in the multicast case) –Quickly end up duplicating normal RTP SSRC collision detection and resolution –Again, this is mostly an issue for multicast streams with many participants –For unicast, collision is easily resolved by simply picking another SSRC Proposal: Support unicast and singly single crypto context only. Consider removing SSRC part.

Issue #3: Hierarchical Streams Current draft does not consider hierarchical/layered encoding schemes Only an issue for multicast streams Proposal: Leave for further study for multicast.

Issue #4: “Use” Parameter “Use” parameter was removed: –Allowed a key to be specified as “encryption”, “decryption”, or “both” –Lead to more complicated offer/answer rules with additional room for errors. New rule is to infer usage from context: –Unicast offer contains offerer's encryption key –Unicast answer contains answerer's encryption key –Multicast offer and answer must use the same key (encryption and decryption) –Advertising just advertises the key Is there a need for the “use” parameter ? Proposal: Not needed for unicast.

Next Steps Propose to issue update without multicast No other known issues then Ready for WGLC ?

Security Preconditions for SDP Media Stream draft-andreasen-mmusic-securityprecondition-00.txt November 14, 2003 Flemming Andreasen Mark Baugher Dan Wing

Overview Problem –Offerer suggests more than one security description. –Answerer picks one and starts sending secure media accordingly. –Offerer receives secure media before answer and cannot determine which security description to use (crypto-suite, key, etc.) Solution –Define a security precondition (RFC 3312)

Next Steps Adopt as WG item ?