RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams

Publisher

IETF / RFC Editor

URL

https://www.rfc-editor.org/rfc/rfc4568.html

Published

2006-07-01

Updated

unknown

Accessed

2026-09-23

HTTP status

200

License

IETF Trust Legal Provisions (BCP 78); no-redistribution; short excerpts and locators only

Source notes citing this source

• When every offered stream is rejected for lack of an acceptable crypto suite, the SIP-level result is most likely a 488 to the INVITE, by combining RFC 4568 stream rejection with RFC 6337 offer-rejection guidance; RFC 4568 itself names no SIP response code. inferred in context
• Because SDES carries keying material in clear SDP, RFC 4568 requires confidentiality and integrity protection of the signaling and says SIP deployments should use SIPS or S/MIME. in context
• If an offer carries crypto attributes but none is valid or supported, the answerer must reject that media stream. in context
• SDES a=crypto attributes are defined only for SRTP transports such as RTP/SAVP and RTP/SAVPF, not for plain RTP/AVP. in context
• The SDP a=crypto attribute carries SRTP keying material, and RFC 4568 requires the SDP carrying it to be protected by S/MIME or a lower-layer service such as TLS or IPsec. in context
• With SDP Security Descriptions (SDES), the SRTP master key and salt travel inline in the SDP crypto attribute, and RFC 4568 requires the signaling carrying them to be protected for confidentiality and integrity (for example by TLS or S/MIME). in context
• Recovering SDES-keyed SRTP media from a capture first requires decrypting the SIP-over-TLS signaling that carries the SDP keys, so TLS decryption limits also bound media analysis. inferred in context
• Under RFC 4568 offer/answer, the answerer must accept exactly one of the offered crypto attributes and return that attribute's tag and crypto suite in the answer. in context
• RFC 4568 carries SRTP keying in the SDP media-level attribute a=crypto:<tag> <crypto-suite> <key-params> [<session-params>], where the tag is a decimal identifier unique within the media line. in context
• RFC 4568 requires the master keys in an SDES answer to differ from those in the offer, to avoid keystream reuse. in context
• The only SRTP key method RFC 4568 defines is 'inline', formatted as inline:<key||salt>[|lifetime][|MKI:length], with the base64 master key and salt concatenated. in context
• If none of the offered crypto attributes is acceptable, RFC 4568 requires the answerer to reject the offered media stream. in context
• Because SDES puts the master key in cleartext SDP, RFC 4568 requires the signalling to be protected with message authentication and encryption, for example TLS, IPsec or S/MIME. in context
• RFC 4568 defines optional session parameters, including UNENCRYPTED_SRTP, UNENCRYPTED_SRTCP and UNAUTHENTICATED_SRTP, that switch off encryption or authentication for a stream. in context
• RFC 4568 defines three SRTP crypto suites: AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32 and F8_128_HMAC_SHA1_80. in context

Cite this source record

APA

WarmTransfer. (2006, July 1). RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams. WarmTransfer. https://warmtransfer.net/knowledge/sources/rfc-4568-sdes

BibTeX

@misc{warmtransfer-rfc-4568-sdes,
  title  = {RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams},
  author = {{WarmTransfer}},
  year   = {2006},
  url    = {https://warmtransfer.net/knowledge/sources/rfc-4568-sdes},
  note   = {IETF / RFC Editor, accessed 2026-09-23}
}