SDP Security Descriptions for Media Streams

1
SDP Security Descriptions for Media Streams

• draft-ietf-mmusic-sdescriptions-02.txt
• November 14, 2003
• Flemming Andreasen (fandreas_at_cisco.com)
• Mark Baugher (mbaugher_at_cisco.com)
• Dan Wing (dwing_at_cisco.com)

2
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

3
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 ltFrom,Togt to SRTP
  profile

4
More Detailed Changes, cont.

• Extension rules
• Key methods (general)
• SRTP crypto-suites
• SRTP session parameters
• IANA considerations and registration procedures
• Updated grammar

5
Open Issues

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

6
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.

7
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

8
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.

9
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.

10
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.

11
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.

12
Next Steps

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

13
Security Preconditions for SDP Media Stream

• draft-andreasen-mmusic-securityprecondition-00.txt
  
• November 14, 2003
• Flemming Andreasen (fandreas_at_cisco.com)
• Mark Baugher (mbaugher_at_cisco.com)
• Dan Wing (dwing_at_cisco.com)

14
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)

15
Next Steps

• Adopt as WG item ?