Security Preconditions for Session Description Protocol (SDP) Media Streams
RFC 5027
Document | Type |
RFC - Proposed Standard
(October 2007; No errata)
Updates RFC 3312
|
|
---|---|---|---|
Authors | Flemming Andreasen , Dan Wing | ||
Last updated | 2015-10-14 | ||
Replaces | draft-andreasen-mmusic-securityprecondition | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5027 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Jon Peterson | ||
Send notices to | (None) |
Network Working Group F. Andreasen Request for Comments: 5027 D. Wing Updates: 3312 Cisco Systems Category: Standards Track October 2007 Security Preconditions for Session Description Protocol (SDP) Media Streams Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. Table of Contents 1. Introduction ....................................................2 2. Notational Conventions ..........................................2 3. Security Precondition Definition ................................2 4. Examples ........................................................6 4.1. SDP Security Descriptions Example ..........................6 4.2. Key Management Extension for SDP Example ...................9 5. Security Considerations ........................................11 6. IANA Considerations ............................................13 7. Acknowledgements ...............................................13 8. Normative References ...........................................13 9. Informative References .........................................14 Andreasen & Wing Standards Track [Page 1] RFC 5027 Security Preconditions October 2007 1. Introduction The concept of a Session Description Protocol (SDP) [RFC4566] precondition is defined in [RFC3312] as updated by [RFC4032]. A precondition is a condition that has to be satisfied for a given media stream in order for session establishment or modification to proceed. When a (mandatory) precondition is not met, session progress is delayed until the precondition is satisfied or the session establishment fails. For example, RFC 3312 defines the Quality-of-Service precondition, which is used to ensure availability of network resources prior to establishing (i.e., alerting) a call. Media streams can either be provided in cleartext and with no integrity protection, or some kind of media security can be applied, e.g., confidentiality and/or message integrity. For example, the Audio/Video profile of the Real-Time Transfer Protocol (RTP) [RFC3551] is normally used without any security services whereas the Secure Real-time Transport Protocol (SRTP) [SRTP] is always used with security services. When media stream security is being negotiated, e.g., using the mechanism defined in SDP Security Descriptions [SDESC], both the offerer and the answerer [RFC3264] need to know the cryptographic parameters being used for the media stream; the offerer may provide multiple choices for the cryptographic parameters, or the cryptographic parameters selected by the answerer may differ from those of the offerer (e.g., the key used in one direction versus the other). In such cases, to avoid media clipping, the offerer needs to receive the answer prior to receiving any media packets from the answerer. This can be achieved by using a security precondition, which ensures the successful negotiation of media stream security parameters for a secure media stream prior to session establishment or modification. 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Security Precondition Definition The semantics for a security precondition are that the relevant cryptographic parameters (cipher, key, etc.) for a secure media stream are known to have been negotiated in the direction(s) required. If the security precondition is used with a non-secure media stream, the security precondition is by definition satisfied. A secure media stream is here defined as a media stream that uses some kind of security service (e.g., message integrity, Andreasen & Wing Standards Track [Page 2] RFC 5027 Security Preconditions October 2007 confidentiality, or both), regardless of the cryptographic strength of the mechanisms being used.Show full document text