draft-ietf-mmusic-sdescriptions-03.txt   draft-ietf-mmusic-sdescriptions-04.txt 
Internet Engineering Task Force Flemming Andreasen Internet Engineering Task Force Flemming Andreasen
MMUSIC Working Group Mark Baugher MMUSIC Working Group Mark Baugher
INTERNET-DRAFT Dan Wing INTERNET-DRAFT Dan Wing
EXPIRES: August 2004 Cisco Systems EXPIRES: November 2004 Cisco Systems
February, 2004 May, 2004
Session Description Protocol Security Descriptions Session Description Protocol Security Descriptions
for Media Streams for Media Streams
<draft-ietf-mmusic-sdescriptions-03.txt> <draft-ietf-mmusic-sdescriptions-04.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
security protocol to secure the SDP message. security protocol to secure the SDP message.
Table of Contents Table of Contents
1. Notational Conventions............................................3 1. Notational Conventions............................................3
2. Introduction......................................................3 2. Introduction......................................................3
3. SDP "Crypto" Attribute and Parameters.............................5 3. SDP "Crypto" Attribute and Parameters.............................5
3.1 Tag.............................................................5 3.1 Tag.............................................................5
3.2 Crypto-suite....................................................5 3.2 Crypto-suite....................................................5
3.3 Key Parameters..................................................6 3.3 Key Parameters..................................................6
3.4 Session Parameters..............................................6 3.4 Session Parameters..............................................7
3.5 Example.........................................................7 3.5 Example.........................................................7
4. General Use of the crypto Attribute...............................7 4. General Use of the crypto Attribute...............................8
4.1 Use With Offer/Answer...........................................8 4.1 Use With Offer/Answer...........................................8
4.1.1 Generating the Initial Offer - Unicast Streams............8 4.1.1 Generating the Initial Offer - Unicast Streams............8
4.1.2 Generating the Initial Answer - Unicast Streams...........9 4.1.2 Generating the Initial Answer - Unicast Streams...........9
4.1.3 Offerer Processing of the Initial Answer - Unicast Streams10 4.1.3 Offerer Processing of the Initial Answer - Unicast Streams10
4.1.4 Modifying the Session....................................10 4.1.4 Modifying the Session....................................10
4.2 Use Outside Offer/Answer.......................................10 4.2 Use Outside Offer/Answer.......................................10
4.3 General Backwards Compatibility Considerations.................10 4.3 General Backwards Compatibility Considerations.................10
5. SRTP Security Descriptions.......................................11 5. SRTP Security Descriptions.......................................11
5.1 SRTP Key Parameter.............................................12 5.1 SRTP Key Parameter.............................................12
5.2 Crypto-suites..................................................14 5.2 Crypto-suites..................................................14
5.2.1 AES_CM_128_HMAC_SHA1_80..................................15 5.2.1 AES_CM_128_HMAC_SHA1_80..................................15
5.2.2 AES_CM_128_HMAC_SHA1_32..................................15 5.2.2 AES_CM_128_HMAC_SHA1_32..................................15
5.2.3 F8_128_HMAC_SHA1_80......................................16 5.2.3 F8_128_HMAC_SHA1_80......................................16
5.2.4 Adding new Crypto-suite Definitions......................16 5.2.4 Adding new Crypto-suite Definitions......................16
5.3 Session Parameters.............................................16 5.3 Session Parameters.............................................16
5.3.1 KDR=n....................................................16 5.3.1 KDR=n....................................................16
5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................16 5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP...................16
5.3.3 UNAUTHENTICATED_SRTP.....................................17 5.3.3 UNAUTHENTICATED_SRTP.....................................17
5.3.4 FEC_ORDER=order..........................................17 5.3.4 FEC_ORDER=order..........................................17
5.3.5 Window Size Hint (WSH)...................................17 5.3.5 FEC_KEY=key-params.......................................17
5.3.6 Defining New SRTP Session Parameters.....................18 5.3.6 Window Size Hint (WSH)...................................18
5.3.7 Defining New SRTP Session Parameters.....................18
5.4 SRTP Crypto Context Initialization.............................18 5.4 SRTP Crypto Context Initialization.............................18
5.5 Removal of Crypto Contexts.....................................20 5.5 Removal of Crypto Contexts.....................................20
6. SRTP-Specific Use of the crypto Attribute........................21 6. SRTP-Specific Use of the crypto Attribute........................21
6.1 Use with Offer/Answer..........................................21 6.1 Use with Offer/Answer..........................................21
6.1.1 Generating the Initial Offer - Unicast Streams...........21 6.1.1 Generating the Initial Offer - Unicast Streams...........21
6.1.2 Generating the Initial Answer - Unicast Streams..........21 6.1.2 Generating the Initial Answer - Unicast Streams..........22
6.1.3 Offerer Processing of the Initial Answer - Unicast Streams22 6.1.3 Offerer Processing of the Initial Answer - Unicast Streams22
6.1.4 Modifying the Session....................................22 6.1.4 Modifying the Session....................................23
6.1.5 Offer/Answer Example.....................................23 6.1.5 Offer/Answer Example.....................................24
6.2 SRTP-Specific Use Outside Offer/Answer.........................24 6.2 SRTP-Specific Use Outside Offer/Answer.........................25
6.3 Support for SIP Forking........................................24 6.3 Support for SIP Forking........................................25
6.4 SRTP-Specific Backwards Compatibility Considerations...........25 6.4 SRTP-Specific Backwards Compatibility Considerations...........26
6.5 Operation with KEYMGT= and k= lines............................25 6.5 Operation with KEYMGT= and k= lines............................26
7. Security Considerations..........................................26 7. Security Considerations..........................................26
7.1 Authentication of packets......................................26 7.1 Authentication of packets......................................26
7.2 Keystream Reuse................................................26 7.2 Keystream Reuse................................................27
7.3 Signaling Authentication and Signaling Encryption..............26 7.3 Signaling Authentication and Signaling Encryption..............27
8. Grammar..........................................................28 8. Grammar..........................................................28
8.1 Generic "Crypto" Attribute Grammar.............................28 8.1 Generic "Crypto" Attribute Grammar.............................28
8.2 SRTP "Crypto" Attribute Grammar................................28 8.2 SRTP "Crypto" Attribute Grammar................................29
9. IANA Considerations..............................................29 9. IANA Considerations..............................................30
9.1 Registration of the "crypto" attribute.........................29 9.1 Registration of the "crypto" attribute.........................30
9.2 New IANA Registries and Registration Procedures................29 9.2 New IANA Registries and Registration Procedures................30
9.2.1 Security Descriptions Key Method Registry and Registration30 9.2.1 Security Descriptions Key Method Registry and Registration31
9.2.2 Security Description Media Stream Transport Registry and 9.2.2 Security Description Media Stream Transport Registry and
Registration.....................................................30 Registration.....................................................31
9.3 Initial Registrations..........................................30 9.3 Initial Registrations..........................................31
9.3.1 Key Method...............................................30 9.3.1 Key Method...............................................31
9.3.2 SRTP Media Stream Transport..............................31 9.3.2 SRTP Media Stream Transport..............................31
10. Acknowledgements................................................32 10. Acknowledgements................................................32
11. Authors' Addresses..............................................32 11. Authors' Addresses..............................................33
12. Normative References............................................32 12. Normative References............................................33
13. Informative References..........................................33 13. Informative References..........................................34
Intellectual Property Statement.....................................35 Intellectual Property Statement.....................................35
Acknowledgement.....................................................36 Acknowledgement.....................................................36
1. Notational Conventions 1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [RFC2119]. The terminology in this be interpreted as described in [RFC2119]. The terminology in this
document conforms to [RFC2828], "Internet Security Glossary". document conforms to [RFC2828], "Internet Security Glossary".
n^r is exponentiation where n is multiplied by itself r times; n and n^r is exponentiation where n is multiplied by itself r times; n and
r are integers. 0..k is an integer range of all integers from 0 r are integers. 0..k is an integer range of all integers from 0
through k inclusive. through k inclusive.
The terms 'transport' and 'media transport' are used to mean
'transport protocol' as defined in RFC2327, page 20.
Explanatory notes are provided in several places throughout the Explanatory notes are provided in several places throughout the
document; these notes are indented two spaces from the surrounding document; these notes are indented two spaces from the surrounding
text. text.
2. Introduction 2. Introduction
The Session Description Protocol (SDP) [SDP] describes multimedia The Session Description Protocol (SDP) [SDP] describes multimedia
sessions, which can be audio, video, whiteboard, fax, modem, and sessions, which can be audio, video, whiteboard, fax, modem, and
other media streams. Security services such as data origin other media streams. Security services such as data origin
authentication, integrity and confidentiality are often needed for authentication, integrity and confidentiality are often needed for
skipping to change at page 4, line 6 skipping to change at page 4, line 9
to configure SRTP beyond using default values. This document to configure SRTP beyond using default values. This document
specifies a new SDP attribute called "crypto", which is used to specifies a new SDP attribute called "crypto", which is used to
signal and negotiate cryptographic parameters for media streams in signal and negotiate cryptographic parameters for media streams in
general, and SRTP in particular. The definition of the crypto general, and SRTP in particular. The definition of the crypto
attribute in this document is limited to two-party unicast media attribute in this document is limited to two-party unicast media
streams where each source has a unique cryptographic key; support streams where each source has a unique cryptographic key; support
for multicast media streams or multipoint unicast streams is for for multicast media streams or multipoint unicast streams is for
further study. further study.
The crypto attribute is defined in a generic way to enable its use The crypto attribute is defined in a generic way to enable its use
with secure transports besides SRTP that can establish cryptographic with SRTP and any other secure transports that can establish
parameters with only a single message or in a single round-trip cryptographic parameters with only a single message or in a single
exchange using the offer/answer model [RFC3264]. Extension to other round-trip exchange using the offer/answer model [RFC3264].
transports, however, is beyond the scope of this document. Each Extension to transports other than SRTP, however, is beyond the
type of secure SDP media transport needs its own specification for scope of this document. Each type of secure media transport needs
the crypto-attribute parameter. These definitions are frequently its own specification for the crypto-attribute parameter. These
unique to the particular type of transport and must be specified in definitions are frequently unique to the particular type of
an Internet RFC and registered with IANA according to the procedures transport and must be specified in a Standards Track RFC and
defined in Section 9. This document defines the security parameters registered with IANA according to the procedures defined in Section
and keying material for SRTP only. 9. This document defines the security parameters and keying
material for SRTP only.
It would be self-defeating not to secure cryptographic keys and It would be self-defeating not to secure cryptographic keys and
other parameters at least as well as the data is secured. Data other parameters at least as well as the data is secured. Data
security protocols such as SRTP rely upon a separate key management security protocols such as SRTP rely upon a separate key management
system to securely establish encryption and/or authentication keys. system to securely establish encryption and/or authentication keys.
Key management protocols provide authenticated key establishment Key management protocols provide authenticated key establishment
(AKE) procedures to authenticate the identity of each endpoint and (AKE) procedures to authenticate the identity of each endpoint and
protect against man-in-the-middle, reflection/replay, connection protect against man-in-the-middle, reflection/replay, connection
hijacking and some denial of service attacks [skeme]. Along with hijacking and some denial of service attacks [skeme]. Along with
the key, an AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK the key, an AKE protocol such as MIKEY [mikey], GDOI [GDOI], KINK
[kink], IKE [ike] or TLS securely disseminates information [kink], IKE [ike], Secure Multiparts [s/mime, pgp/mime] or TLS [TLS]
describing both the key and the data-security session (for example, securely disseminates information describing both the key and the
whether SRTCP payloads are encrypted or unencrypted in an SRTP data-security session. AKE is needed because it is pointless to
session). AKE is needed because it is pointless to provide a key provide a key over a medium where an attacker can snoop the key,
over a medium where an attacker can snoop the key, alter the alter the definition of the key to render it useless, or change the
definition of the key to render it useless, or change the parameters parameters of the security session to gain unauthorized access to
of the security session to gain unauthorized access to session- session-related information.
related information.
SDP, however, was not designed to provide AKE services, and the SDP, however, was not designed to provide AKE services, and the
media security descriptions defined in this document do not add AKE media security descriptions defined in this document do not add AKE
services to SDP. This specification is no replacement for a key services to SDP. This specification is no replacement for a key
management protocol or for the conveyance of key management messages management protocol or for the conveyance of key management messages
in SDP [keymgt]. The SDP security descriptions defined here are in SDP [keymgt]. The SDP security descriptions defined here are
suitable for restricted cases only where IPsec, TLS, or some other suitable for restricted cases only where IPsec, TLS, or some other
encapsulating data-security protocol (e.g., SIP secure multiparts) encapsulating data-security protocol (e.g., SIP secure multiparts)
protects the SDP message. This document adds security descriptions protects the SDP message. This document adds security descriptions
to those encrypted and/or authenticated SDP messages through the new to those encrypted and/or authenticated SDP messages through the new
SDP "crypto" attribute, which provides the cryptographic parameters SDP "crypto" attribute, which provides the cryptographic parameters
of a media stream. of a media stream.
The "crypto" attribute can be adapted to any media transport, but The "crypto" attribute can be adapted to any media transport, but
its precise definition is frequently unique to a particular its precise definition is unique to a particular transport.
transport.
In Section 3, we introduce the general SDP crypto attribute, and in In Section 3, we introduce the general SDP crypto attribute, and in
Section 4 we define how it is used with and without the offer/answer Section 4 we define how it is used with and without the offer/answer
model. In Section 5, we define the crypto attribute details needed model. In Section 5, we define the crypto attribute details needed
for SRTP, and in Section 6 we define SRTP-specific use of the for SRTP, and in Section 6 we define SRTP-specific use of the
attribute with and without the offer/answer model. Section 7 attribute with and without the offer/answer model. Section 7
recites security considerations, and Section 8 gives an Augmented- recites security considerations, and Section 8 gives an Augmented-
BNF grammar for the general crypto attribute as well as the SRTP- BNF grammar for the general crypto attribute as well as the SRTP-
specific use of the crypto attribute. IANA considerations are specific use of the crypto attribute. IANA considerations are
provided in Section 9. provided in Section 9.
3. SDP "Crypto" Attribute and Parameters 3. SDP "Crypto" Attribute and Parameters
A new media-level SDP attribute called "crypto" describes the A new media-level SDP attribute called "crypto" describes the
cryptographic suite, key parameters, and session parameters for the cryptographic suite, key parameters, and session parameters for the
preceding unicast media line. The "crypto" attribute MUST only preceding unicast media line. The "crypto" attribute MUST only
appear at the SDP media level (not the session level). The "crypto" appear at the SDP media level (not at the session level). The
attribute follows the format (see Section 8.1 for the formal ABNF "crypto" attribute follows the format (see Section 8.1 for the
grammar): formal ABNF grammar):
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>] a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
The fields tag, crypto-suite, key-params, and session-params are The fields tag, crypto-suite, key-params, and session-params are
described in the following sub-sections. Below we show an example described in the following sub-sections. Below we show an example
of the crypto attribute for the "RTP/SAVP" transport, i.e., the of the crypto attribute for the "RTP/SAVP" transport, i.e., the
secure RTP extension to the Audio/Video Profile [srtp] (newlines secure RTP extension to the Audio/Video Profile [srtp]. In the
included for formatting reasons only): following, newlines are included for formatting reasons only:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32
The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined The crypto-suite is AES_CM_128_HMAC_SHA1_80, key-params is defined
by the text starting with "inline:", and session-params is omitted. by the text starting with "inline:", and session-params is omitted.
3.1 Tag 3.1 Tag
The tag is a decimal number (see Section 8.1 for details) used as an The tag is a decimal number used as an identifier for a particular
identifier for a particular crypto attribute. The tag MUST be crypto attribute (see Section 8.1 for details). The tag MUST be
unique among all crypto attributes for a given media stream. It is unique among all crypto attributes for a given media line. It is
used with the offer/answer model (see Section 4.1) to determine used with the offer/answer model to determine which of several
which of several offered crypto attributes were chosen by the offered crypto attributes were chosen by the answerer (see Section
answerer. 4.1).
In the offer/answer model, the tag is a negotiated parameter. In the offer/answer model, the tag is a negotiated parameter.
3.2 Crypto-suite 3.2 Crypto-suite
The crypto-suite field is an identifier (see Section 8.1 for The crypto-suite field is an identifier that describes the
details) that describes the encryption and authentication algorithms encryption and authentication algorithms (e.g.,
(e.g., AES_CM_128_HMAC_SHA1_80) for the transport in question. The AES_CM_128_HMAC_SHA1_80) for the transport in question (see Section
possible values for the crypto-suite parameter are defined within 8.1 for details). The possible values for the crypto-suite
the context of the transport, i.e., each transport defines a parameter are defined within the context of the transport, i.e.,
separate namespace for the set of crypto-suites. For example, the each transport defines a separate namespace for the set of crypto-
crypto-suite "AES_CM_128_HMAC_SHA1_80" defined within the context suites. For example, the crypto-suite "AES_CM_128_HMAC_SHA1_80"
"RTP/SAVP" transport applies to Secure RTP only; the string may be defined within the context "RTP/SAVP" transport applies to Secure
reused for another transport (e.g., "RTP/SAVPF" [srtpf]), but a RTP only; the string may be reused for another transport (e.g.,
separate definition would be needed. "RTP/SAVPF" [srtpf]), but a separate definition would be needed.
In the offer/answer model, the crypto-suite is a negotiated In the offer/answer model, the crypto-suite is a negotiated
parameter. parameter.
3.3 Key Parameters 3.3 Key Parameters
The key-params field provides one or more sets of keying material The key-params field provides one or more sets of keying material
for the crypto-suite in question. The field consists of a method for the crypto-suite in question. The field consists of a method
indicator followed by a colon, and the actual keying information as indicator followed by a colon, and the actual keying information as
shown below (the formal grammar is provided in Section 8.1): shown below (the formal grammar is provided in Section 8.1):
key-params = <key-method> ":" <key-info> key-params = <key-method> ":" <key-info>
Keying material might be provided by different means than key- Keying material might be provided by different means than key-
params, however this is out of the scope of this document. Only one params, however this is out of scope. Only one method is defined in
method is defined in this document, namely "inline", which indicates this document, namely "inline", which indicates that the actual
that the actual keying material is provided in the key-info field keying material is provided in the key-info field itself. There is
itself. There is a single name space for the key-method, i.e., the a single name space for the key-method, i.e., the key-method is
key-method is transport independent. New key-methods (e.g., use of transport independent. New key-methods (e.g., use of a URL) may be
a URL) may be defined in an IETF Standards Track RFC in the future. defined in a Standards Track RFC in the future. Although the key-
Although the key-method itself may be generic, the accompanying key- method itself may be generic, the accompanying key-info definition
info definition is specific not only to the key-method, but also to is specific not only to the key-method, but also to the transport in
the transport in question. New key methods MUST be registered with question. New key methods MUST be registered with the IANA
the IANA according to the procedures defined in Section 9.2.1. according to the procedures defined in Section 9.2.1.
Key-info is defined as a general character string (see Section 8.1 Key-info is defined as a general character string (see Section 8.1
for details); further transport and key-method specific syntax and for details); further transport and key-method specific syntax and
semantics MUST be provided in an IETF RFC for each combination of semantics MUST be provided in a Standards Track RFC for each
transport and key-method that wants to use it; definitions for SRTP combination of transport and key-method that use it; definitions for
are provided in Section 5. Note that such definitions are provided SRTP are provided in Section 5. Note that such definitions are
within the context of both a particular transport (e.g., "RTP/SAVP") provided within the context of both a particular transport (e.g.,
and a specific key-method (e.g., "inline"). IANA will register the "RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will
list of supported key methods for each transport. register the list of supported key methods for each transport.
When multiple keys are included in the key parameters, it MUST be When multiple keys are included in the key parameters, it MUST be
possible to determine which of the keys is being used in a given possible to determine which of the keys is being used in a given
media packet by a simple inspection of the media packet received; a media packet by a simple inspection of the media packet received; a
trial-and-error approach between the possible keys MUST NOT be trial-and-error approach between the possible keys MUST NOT be
required. performed.
For SRTP, this could for example be achieved by use of Master Key For SRTP, this could be achieved by use of Master Key Identifiers
Identifiers (MKI), or <"From", "To"> values [srtp]. (MKI), or <"From", "To"> values [srtp].
In the offer/answer model, the key parameter is a declarative In the offer/answer model, the key parameter is a declarative
parameter. parameter.
3.4 Session Parameters 3.4 Session Parameters
Session parameters are specific to a given transport and use of them Session parameters are specific to a given transport and use of them
is OPTIONAL in the general framework, where they are just defined as is OPTIONAL in the security descriptions framework, where they are
a general character string. If session parameters are to be used just defined as general character strings. If session parameters
for a given transport, then transport-specific syntax and semantics are to be used for a given transport, then transport-specific syntax
MUST be provided in an IETF RFC; definitions for SRTP are provided and semantics MUST be provided in a Standards Track RFC; definitions
in Section 5. for SRTP are provided in Section 5.
In the offer/answer model, session parameters may be either In the offer/answer model, session parameters may be either
negotiated or declarative; the definition of specific session negotiated or declarative; the definition of specific session
parameters MUST indicate whether they are negotiated or declarative. parameters MUST indicate whether they are negotiated or declarative.
Negotiated parameters apply to data sent in both directions, whereas Negotiated parameters apply to data sent in both directions, whereas
declarative parameters apply only to media sent by the entity that declarative parameters apply only to media sent by the entity that
generated the SDP. Thus, a declarative parameter in an offer generated the SDP. Thus, a declarative parameter in an offer
applies to media sent by the offerer, whereas a declarative applies to media sent by the offerer, whereas a declarative
parameter in an answer applies to media sent by the answerer. parameter in an answer applies to media sent by the answerer.
3.5 Example 3.5 Example
The first example shows use of the crypto attribute for the This example shows use of the crypto attribute for the "RTP/SAVP"
"RTP/SAVP" media transport type (as defined in Section 4). The media transport type (as defined in Section 4). The "a=crypto" line
"a=crypto" line is actually one long line; it is shown as two lines is actually one long line; it is shown as two lines due to page
due to page formatting: formatting:
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 161.44.17.12/127 c=IN IP4 161.44.17.12/127
t=2873397496 2873404696 t=2873397496 2873404696
m=video 51372 RTP/SAVP 31 m=video 51372 RTP/SAVP 31
skipping to change at page 8, line 39 skipping to change at page 8, line 45
apply to media in the direction from the offerer to the answerer; if apply to media in the direction from the offerer to the answerer; if
the media stream is marked as "recvonly", a key MUST still be the media stream is marked as "recvonly", a key MUST still be
provided. provided.
This is done for consistency. Also, in the case of SRTP, for This is done for consistency. Also, in the case of SRTP, for
example, secure RTCP will still be flowing in both the send and example, secure RTCP will still be flowing in both the send and
receive direction for a unidirectional stream. receive direction for a unidirectional stream.
The offer may include session parameters. There are no general The offer may include session parameters. There are no general
offer rules for the session parameters; instead, specific rules may offer rules for the session parameters; instead, specific rules may
be provided as part of the transport specific definitions of any be provided as part of the transport-specific definitions of any
session parameters. session parameters.
When issuing an offer, the offerer MUST be prepared to support media When issuing an offer, the offerer MUST be prepared to support media
security in accordance with any of the crypto attributes included in security in accordance with any of the crypto attributes included in
the offer. There are however two problems associated with this. the offer. There are however two problems associated with this.
First of all, the offerer does not know which key the answerer will First of all, the offerer does not know which key the answerer will
be using for media sent to the offerer. Since media may arrive be using for media sent to the offerer. Second, the offerer may not
prior to the answer, delay or clipping can occur. If this is be able to deduce which of the offered crypto attributes were
unacceptable to the offerer, the offerer SHOULD use a mechanism accepted. Since media may arrive prior to the answer, delay or
outside the scope of this document to prevent the above problem. clipping can occur. If this is unacceptable to the offerer, the
offerer SHOULD use a mechanism outside the scope of this document to
prevent the above problem.
For example, in SIP [RFC3261], a "security" precondition as For example, in SIP [RFC3261], a "security" precondition as
defined in [sprecon] could solve the above problem. defined in [sprecon] could solve the above problem.
Another problem can occur when the offerer includes multiple crypto
attributes: The offerer may not be able to deduce which of the
offered crypto attributes was accepted by the answerer until the
answer is received, yet media may arrive before the answer.
If this is unacceptable to the offerer, the offerer either SHOULD
NOT include multiple crypto attributes in the offer, or a mechanism
outside the scope of this document SHOULD be used to prevent the
above problem (e.g., a "security" precondition).
4.1.2 Generating the Initial Answer - Unicast Streams 4.1.2 Generating the Initial Answer - Unicast Streams
When the answerer receives the initial offer with one or more crypto When the answerer receives the initial offer with one or more crypto
attributes for a given unicast media stream, the answerer MUST attributes for a given unicast media stream, the answerer MUST
either accept exactly one of the offered crypto attributes, or the either accept exactly one of the offered crypto attributes, or the
offered stream MUST be rejected. offered stream MUST be rejected.
If the answerer wishes to indicate support for other crypto If the answerer wishes to indicate support for other crypto
attributes, those can be listed by use of the SDP Simple attributes, those can be listed by use of the SDP Simple
Capability Declaration [RFC3407] extensions. Capability Declaration [RFC3407] extensions.
skipping to change at page 10, line 16 skipping to change at page 10, line 14
4.1.3 Offerer Processing of the Initial Answer - Unicast Streams 4.1.3 Offerer Processing of the Initial Answer - Unicast Streams
When the offerer receives the answer, the offerer MUST verify, that When the offerer receives the answer, the offerer MUST verify, that
one of the initially offered crypto suites and its accompanying tag one of the initially offered crypto suites and its accompanying tag
was accepted and echoed in the answer. Also, the answer MUST was accepted and echoed in the answer. Also, the answer MUST
include one or more keys, which will be used for media sent from the include one or more keys, which will be used for media sent from the
answerer to the offerer. answerer to the offerer.
If the offer contained any mandatory negotiated session parameters If the offer contained any mandatory negotiated session parameters
(see section 5.3.6), the offerer MUST verify that said parameters (see section 5.3.7), the offerer MUST verify that said parameters
are included in the answer. If the answer contains any mandatory are included in the answer and support them. If the answer contains
declarative session parameters, the offerer MUST be able to support any mandatory declarative session parameters, the offerer MUST be
those. able to support those.
If any of the above fails, the negotiation MUST be deemed to have If any of the above fails, the negotiation MUST fail.
failed.
4.1.4 Modifying the Session 4.1.4 Modifying the Session
Once a media stream has been established, it MAY be modified at any Once a media stream has been established, it MAY be modified at any
time, as described in RFC 3264, Section 8. Such a modification MAY time, as described in RFC 3264, Section 8. Such a modification MAY
be triggered by the security service, e.g., in order to perform a be triggered by the security service, e.g., in order to perform a
re-keying or change the crypto-suite. If media stream security re-keying or change the crypto-suite. If media stream security
using the general security descriptions defined here is still using the general security descriptions defined here is still
desired, the crypto attribute MUST be included in these new desired, the crypto attribute MUST be included in these new
offer/answer exchanges. The procedures are similar to those defined offer/answer exchanges. The procedures are similar to those defined
skipping to change at page 11, line 5 skipping to change at page 10, line 52
security description that it deems most secure for its purposes. security description that it deems most secure for its purposes.
4.3 General Backwards Compatibility Considerations 4.3 General Backwards Compatibility Considerations
In the offer/answer model, it is possible that the answerer supports In the offer/answer model, it is possible that the answerer supports
a given secure transport (e.g., "RTP/SAVP") and accepts the offered a given secure transport (e.g., "RTP/SAVP") and accepts the offered
media stream, yet the answerer does not support the crypto attribute media stream, yet the answerer does not support the crypto attribute
defined in this document and hence ignores it. The offerer can defined in this document and hence ignores it. The offerer can
recognize this situation by seeing an accepted media stream in the recognize this situation by seeing an accepted media stream in the
answer that does not include a crypto line. In that case, the answer that does not include a crypto line. In that case, the
security negotiation defined here MUST be deemed to have failed. security negotiation defined here MUST fail.
Similar issues exist when security descriptions are used outside of Similar issues exist when security descriptions are used outside of
the offer/answer model. the offer/answer model. But the source of a non-negotiated security
description has no indication that the receiver has ignored the
crypto attribute.
5. SRTP Security Descriptions 5. SRTP Security Descriptions
In this section, we provide definitions for security descriptions In this section, we provide definitions for security descriptions
for SRTP media streams. In the next section, we define how to use for SRTP media streams. In the next section, we define how to use
SRTP security descriptions with and without the offer/answer model. SRTP security descriptions with and without the offer/answer model.
SRTP security descriptions for a media stream MUST only be used for SRTP security descriptions MUST only be used with the SRTP transport
media streams that use the SRTP transport (e.g., "RTP/SAVP" or (e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies security
"RTP/SAVPF") in the media (m=) line and SHALL apply to that media descriptions for the "RTP/SAVP" profile defined in [srtp], however
stream only. The following specifies rules for the "RTP/SAVP" it is expected that other secure RTP profiles (e.g., "RTP/SAVPF")
profile defined in [srtp], however it is expected that other secure can use the same descriptions, which are in accordance with the SRTP
RTP profiles (e.g., "RTP/SAVPF") can use the same rules. protocol specification [srtp].
There is no assurance that an endpoint is capable of configuring its There is no assurance that an endpoint is capable of configuring its
SRTP service with a particular crypto attribute parameter, but SRTP SRTP service with a particular crypto attribute parameter, but SRTP
guarantees minimal interoperability among SRTP endpoints through the guarantees minimal interoperability among SRTP endpoints through the
default SRTP parameters [srtp]. More capable SRTP endpoints support default SRTP parameters [srtp]. More capable SRTP endpoints support
a variety of parameter values beyond the SRTP defaults and these a variety of parameter values beyond the SRTP defaults and these
values can be configured by the SRTP security descriptions defined values can be configured by the SRTP security descriptions defined
here. An endpoint that does not support the crypto attribute will here. An endpoint that does not support the crypto attribute will
ignore it according to the SDP. Hence the endpoint will simply ignore it according to the SDP. Hence the endpoint will simply
assume use of default SRTP parameters, if it supports SRTP. Such an assume use of default SRTP parameters, if it supports SRTP but not
endpoint will not correctly process the particular media stream. By the crypto attribute. Such an endpoint will not correctly process
using the Offer/Answer model, the offerer and answerer can negotiate the particular media stream. By using the Offer/Answer model, the
the crypto parameters to be used before commencement of the offerer and answerer can negotiate the crypto parameters to be used
multimedia session (see Section 6.1). before commencement of the multimedia session (see Section 6.1).
There are over twenty cryptographic parameters listed in the SRTP There are over twenty cryptographic parameters listed in the SRTP
specification. Many of these parameters have fixed values for specification. Many of these parameters have fixed values for
particular cryptographic transforms. At the time of session particular cryptographic transforms. At the time of session
establishment, moreover, there is usually no need to provide unique establishment, however, there is usually no need to provide unique
settings for many of the SRTP parameters, such as salt length and settings for many of the SRTP parameters, such as salt length and
pseudo-random function (PRF). Thus, it is possible to simplify the pseudo-random function (PRF). Thus, it is possible to simplify the
list of parameters by defining "cryptographic suites" that fix a set list of parameters by defining "cryptographic suites" that fix a set
of SRTP parameter values for the security session. This approach is of SRTP parameter values for the security session. This approach is
followed by the SRTP security descriptions, which uses the general followed by the SRTP security descriptions, which uses the general
security description parameters as follows: security description parameters as follows:
* crypto-suite: Identifies the encryption and authentication * crypto-suite: Identifies the encryption and authentication
transforms transforms
* key parameter: SRTP keying material and parameters * key parameter: SRTP keying material and parameters
* session parameters: The following parameters are defined: * session parameters: The following parameters are defined:
- KDR: The SRTP Key Derivation Rate is the rate that a - KDR: The SRTP Key Derivation Rate is the rate that a
pseudo-random function is applied to a master key pseudo-random function is applied to a master key
- UNENCRYPTED_SRTP: SRTP messages are not encrypted - UNENCRYPTED_SRTP: SRTP messages are not encrypted
- UNENCRYPTED_SRTCP: SRTCP messages are not encrypted - UNENCRYPTED_SRTCP: SRTCP messages are not encrypted
- UNAUTHENTICATED_SRTP: SRTP messages are not authenticated - UNAUTHENTICATED_SRTP: SRTP messages are not authenticated
- FEC_ORDER: Order of forward error correction (FEC) - FEC_ORDER: Order of forward error correction (FEC)
relative to SRTP services relative to SRTP services
- FEC_KEY: Master Key for FEC when the FEC stream is sent
to a separate address and/or port.
- WSH: Window Size Hint - WSH: Window Size Hint
- Extensions: Extension parameters can be defined - Extensions: Extension parameters can be defined
Please refer to the SRTP specification for a complete list of Please refer to the SRTP specification for a complete list of
parameters and their descriptions [Section 8.2, srtp]. The key parameters and their descriptions [Section 8.2, srtp]. The key
parameter, the crypto-suite, and the session parameters shown above parameter, the crypto-suite, and the session parameters shown above
are described in detail in the following subsections. are described in detail in the following subsections.
5.1 SRTP Key Parameter 5.1 SRTP Key Parameter
skipping to change at page 16, line 18 skipping to change at page 16, line 18
cipher is F8 [srtp]. cipher is F8 [srtp].
The length of the base64 decoded key and salt value for this crypto- The length of the base64 decoded key and salt value for this crypto-
suite MUST be 30 characters, i.e. 240 bits; otherwise the crypto suite MUST be 30 characters, i.e. 240 bits; otherwise the crypto
attribute is considered invalid. attribute is considered invalid.
5.2.4 Adding new Crypto-suite Definitions 5.2.4 Adding new Crypto-suite Definitions
If new transforms are added to SRTP, new definitions for those If new transforms are added to SRTP, new definitions for those
transforms SHOULD be given for the SRTP security descriptions and transforms SHOULD be given for the SRTP security descriptions and
published in an IETF RFC. Sections 5.2.1 through 5.2.3 illustrate published in a Standards Track RFC. Sections 5.2.1 through 5.2.3
how to define crypto-suite values for particular cryptographic illustrate how to define crypto-suite values for particular
transforms. Any new crypto-suites MUST be registered with IANA cryptographic transforms. Any new crypto-suites MUST be registered
following the procedures in section 9. with IANA following the procedures in section 9.
5.3 Session Parameters 5.3 Session Parameters
SRTP security descriptions define a set of "session" parameters, SRTP security descriptions define a set of "session" parameters,
which OPTIONALLY may be used to override SRTP session defaults for which OPTIONALLY may be used to override SRTP session defaults for
the SRTP and SRTCP streams. These parameters configure an RTP the SRTP and SRTCP streams. These parameters configure an RTP
session for SRTP services. The session parameters provide session- session for SRTP services. The session parameters provide session-
specific information to establish the SRTP cryptographic context. specific information to establish the SRTP cryptographic context.
5.3.1 KDR=n 5.3.1 KDR=n
skipping to change at page 17, line 29 skipping to change at page 17, line 29
The SRTP specification requires use of message authentication for The SRTP specification requires use of message authentication for
SRTCP, but not for SRTP [srtp]. SRTCP, but not for SRTP [srtp].
In the offer/answer model, this parameter is negotiated. In the offer/answer model, this parameter is negotiated.
5.3.4 FEC_ORDER=order 5.3.4 FEC_ORDER=order
FEC_ORDER signals the use of forward error correction for the RTP FEC_ORDER signals the use of forward error correction for the RTP
packets [rfc2733]. The forward error correction values for "order" packets [rfc2733]. The forward error correction values for "order"
are FEC_SRTP, SRTP_FEC, or SPLIT [mikey]. FEC_SRTP signals that FEC are FEC_SRTP or SRTP_FEC. FEC_SRTP signals that FEC is applied
is applied before SRTP processing by the sender of the SRTP media before SRTP processing by the sender of the SRTP media and after
and after SRTP processing by the receiver of the SRTP media; SRTP processing by the receiver of the SRTP media; FEC_SRTP is the
FEC_SRTP is the default. SRTP_FEC is the reverse processing. SPLIT default. SRTP_FEC is the reverse processing.
signals that the sender performs SRTP encryption, followed by FEC
processing, followed by SRTP authentication; processing is reversed
on the receiver.
In the offer/answer model, FEC_ORDER is a declarative parameter. In the offer/answer model, FEC_ORDER is a declarative parameter.
5.3.5 Window Size Hint (WSH) 5.3.5 FEC_KEY=key-params
FEC_KEY signals the use of separate master key(s) for a Forward
Error Correction (FEC) stream. The master key(s) are specified with
the exact same format as the SRTP Key Parameter defined in Section
5.1, and the semantic rules are the same - in particular, the master
key(s) MUST be different from all other master key(s) in the SDP. A
FEC_KEY MUST be specified when the FEC stream is sent to a different
IP-address and/or port than the media stream to which it applies
(i.e., the "m=" line), e.g., as described in RFC 2733 Section 11.1.
When a FEC stream is sent to the same IP-address and port as the
media stream to which it applies, a FEC_KEY MUST NOT be specified.
If a FEC_KEY is specified in this latter case, the crypto attribute
in question MUST be considered invalid.
In the offer/answer model, FEC_KEY is a declarative parameter.
5.3.6 Window Size Hint (WSH)
SRTP defines the SRTP-WINDOW-SIZE [srtp, section 3.3.2] parameter to SRTP defines the SRTP-WINDOW-SIZE [srtp, section 3.3.2] parameter to
protect against replay attacks. The minimum value is 64 [srtp], protect against replay attacks. The minimum value is 64 [srtp],
however this value may be considered too low for some applications however this value may be considered too low for some applications
(e.g., video). (e.g., video).
The Window Size Hint (WSH) session parameter provides a hint for how The Window Size Hint (WSH) session parameter provides a hint for how
big this window should be to work satisfactorily (e.g., based on big this window should be to work satisfactorily (e.g., based on
sender knowledge of number of packets per second). However, there sender knowledge of number of packets per second). However, there
might be enough information given in SDP attributes like might be enough information given in SDP attributes like
"a=maxprate" and the bandwidth modifiers to allow a receiver to "a=maxprate" and the bandwidth modifiers to allow a receiver to
derive the parameter satisfactorily. Consequently, this value is derive the parameter satisfactorily. Consequently, this value is
only considered a hint to the receiver of the SDP which MAY choose only considered a hint to the receiver of the SDP which MAY choose
to ignore the value provided. to ignore the value provided.
In the offer/answer model, WSH is a declarative parameter. In the offer/answer model, WSH is a declarative parameter.
5.3.6 Defining New SRTP Session Parameters 5.3.7 Defining New SRTP Session Parameters
New SRTP session parameters for the SRTP security descriptions can New SRTP session parameters for the SRTP security descriptions can
be defined in an IETF RFC and registered with IANA according to the be defined in a Standards Track RFC and registered with IANA
registration procedures defined in Section 9. according to the registration procedures defined in Section 9.
New SRTP session parameters are by default mandatory. A newly- New SRTP session parameters are by default mandatory. A newly-
defined SRTP session parameter that is prefixed with the dash defined SRTP session parameter that is prefixed with the dash
character ("-") however is considered optional and MAY be ignored. character ("-") however is considered optional and MAY be ignored.
If an SDP crypto attribute is received with an unknown session If an SDP crypto attribute is received with an unknown session
parameter that is not prefixed with a "-" character, that crypto parameter that is not prefixed with a "-" character, that crypto
attribute MUST be considered invalid. attribute MUST be considered invalid.
5.4 SRTP Crypto Context Initialization 5.4 SRTP Crypto Context Initialization
skipping to change at page 18, line 36 skipping to change at page 18, line 52
* SSRC: Synchronization source * SSRC: Synchronization source
* ROC: Roll-over counter for a given SSRC * ROC: Roll-over counter for a given SSRC
* SEQ: Sequence number for a given SSRC * SEQ: Sequence number for a given SSRC
In a unicast session, as defined here, there are three constraints In a unicast session, as defined here, there are three constraints
on these values. on these values.
The first constraint is on the SSRC, which makes an SRTP keystream The first constraint is on the SSRC, which makes an SRTP keystream
be unique from other participants. As explained in SRTP, the be unique from other participants. As explained in SRTP, the
keystream MUST NOT be reused on two or more different pieces of keystream MUST NOT be reused on two or more different pieces of
plaintext. Keystream reuse makes the ciphertext vulnerable. One plaintext. Keystream reuse makes the ciphertext vulnerable to
vulnerability is that known-plaintext fields in one stream can cryptanalysis. One vulnerability is that known-plaintext fields in
expose portions of the reused keystream and this could further one stream can expose portions of the reused keystream and this
expose more plaintext in other streams. Since all current SRTP could further expose more plaintext in other streams. Since all
encryption transforms use keystreams, key sharing is a general current SRTP encryption transforms use keystreams, key sharing is a
problem [srtp]. SRTP mitigates this problem by including the SSRC general problem [srtp]. SRTP mitigates this problem by including
of the sender in the keystream. But SRTP does not solve this the SSRC of the sender in the keystream. But SRTP does not solve
problem in its entirety because Real-time Transport Protocol has this problem in its entirety because Real-time Transport Protocol
SSRC collisions, which are very rare [rtp], but quite possible. has SSRC collisions, which are very rare [rtp] but quite possible.
During a collision, two or more SSRCs that share a master key will During a collision, two or more SSRCs that share a master key will
have identical keystreams for overlapping portions of the RTP have identical keystreams for overlapping portions of the RTP
sequence-number space. SRTP Security Descriptions avoids keystream sequence-number space. SRTP Security Descriptions avoids keystream
reuse by making unique master keys REQUIRED for the sender and reuse by making unique master keys REQUIRED for the sender and
receiver of the security description. Thus, the first constraint is receiver of the security description. Thus, the first constraint is
satisfied. satisfied.
Also note, that there is a second problem with SSRC collisions: Also note, that there is a second problem with SSRC collisions:
The SSRC is used to identify the crypto context and thereby the The SSRC is used to identify the crypto context and thereby the
cipher, key, ROC, etc. to process incoming packets. In case of cipher, key, ROC, etc. to process incoming packets. In case of
skipping to change at page 19, line 36 skipping to change at page 19, line 52
might not recognize that its ROC needs to be incremented. By might not recognize that its ROC needs to be incremented. By
restricting the initial SEQ to the range of 0..2^15-1, SRTP packet- restricting the initial SEQ to the range of 0..2^15-1, SRTP packet-
index determination will find the correct ROC value, unless all of index determination will find the correct ROC value, unless all of
the first 2^15 packets are lost (which seems, if not impossible, the first 2^15 packets are lost (which seems, if not impossible,
then rather unlikely). See Section 3.3.1 of the SRTP specification then rather unlikely). See Section 3.3.1 of the SRTP specification
regarding packet-index determination [srtp]. regarding packet-index determination [srtp].
The packet index, therefore, depends on the SSRC, the SEQ of an The packet index, therefore, depends on the SSRC, the SEQ of an
incoming packet and the ROC, which is an SRTP crypto context incoming packet and the ROC, which is an SRTP crypto context
variable. Thus, SRTP has a big security dependency on SSRC variable. Thus, SRTP has a big security dependency on SSRC
uniqueness. This fact might lead one to consider establishing the uniqueness.
SSRC by an entity that keeps these values from colliding. One
problem with this approach, however, is that the SSRC belongs to the
transport (RTP or SRTP) and not to the signaling. It would be an
imposition on RTP and SRTP to require that the SSRC be read and
written by an external system such as SDP.
Given the above constraints, unicast SRTP crypto contexts can be Given the above constraints, unicast SRTP crypto contexts can be
established without the need to negotiate SSRC values in the SRTP established without the need to negotiate SSRC values in the SRTP
security descriptions. Instead, an approach called "late binding" security descriptions. Instead, an approach called "late binding"
is RECOMMENDED by this specification. When a packet arrives, the is RECOMMENDED by this specification. When a packet arrives, the
SSRC that is contained in it can be bound to the crypto context at SSRC that is contained in it can be bound to the crypto context at
the time of session commencement (i.e., SRTP packet arrival) rather the time of session commencement (i.e., SRTP packet arrival) rather
than at the time of session signaling (i.e., receipt of an SDP). than at the time of session signaling (i.e., receipt of an SDP).
With the arrival of the packet containing the SSRC, all the data With the arrival of the packet containing the SSRC, all the data
items needed for the SRTP crypto context are held by the receiver items needed for the SRTP crypto context are held by the receiver
skipping to change at page 20, line 29 skipping to change at page 20, line 41
otherwise, the crypto context is not instantiated. otherwise, the crypto context is not instantiated.
* Media packets are not authenticated: Crypto context is * Media packets are not authenticated: Crypto context is
automatically instantiated. automatically instantiated.
It should be noted, that use of late binding when there is no It should be noted, that use of late binding when there is no
authentication of the SRTP media packets is subject to numerous authentication of the SRTP media packets is subject to numerous
security attacks and consequently it is NOT RECOMMENDED (of course, security attacks and consequently it is NOT RECOMMENDED (of course,
this can be said for unauthenticated SRTP in general). this can be said for unauthenticated SRTP in general).
Note that use of late binding without authentication results in Note that use of late binding without authentication will result
local state being created as a result of receiving a packet from in local state being created as a result of receiving a packet
any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT from any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT
RECOMMENDED because it invites easy denial-of-service attack. In RECOMMENDED because it invites easy denial-of-service attack. In
contrast, late binding with authentication does not suffer from contrast, late binding with authentication does not suffer from
this weakness. this weakness.
With the constraints and procedures described above, it is not With the constraints and procedures described above, it is not
necessary to explicitly signal the SSRC, ROC and SEQ for a unicast necessary to explicitly signal the SSRC, ROC and SEQ for a unicast
SRTP session. SRTP session.
5.5 Removal of Crypto Contexts 5.5 Removal of Crypto Contexts
skipping to change at page 21, line 6 skipping to change at page 21, line 15
context contains information that can not automatically be recovered context contains information that can not automatically be recovered
(e.g., ROC), it is important that the sender and receiver agree on (e.g., ROC), it is important that the sender and receiver agree on
when a crypto context can be removed, and perhaps more importantly when a crypto context can be removed, and perhaps more importantly
when it cannot. when it cannot.
Even when late binding is used for a unicast stream, the ROC is Even when late binding is used for a unicast stream, the ROC is
lost and cannot be recovered automatically (unless it is zero) lost and cannot be recovered automatically (unless it is zero)
once the crypto context is removed. once the crypto context is removed.
We resolve this problem as follows. When SRTP security descriptions We resolve this problem as follows. When SRTP security descriptions
are being used, crypto contexts removal MUST follow the same rules are being used, crypto-context removal MUST follow the same rules as
as SSRC removal from the member table [RFC 3550]; note that this can SSRC removal from the member table [RFC 3550]; note that this can
happen as the result of an SRTCP BYE packet or a simple time-out due happen as the result of an SRTCP BYE packet or a simple time-out due
to inactivity. Inactive session participants that wish to ensure to inactivity. Inactive session participants that wish to ensure
their crypto contexts are not timed out MUST thus send SRTCP packets their crypto contexts are not timed out MUST thus send SRTCP packets
at regular intervals. at regular intervals.
6. SRTP-Specific Use of the crypto Attribute 6. SRTP-Specific Use of the crypto Attribute
Section 4 describes general use of the crypto attribute, and this Section 4 describes general use of the crypto attribute, and this
section completes it by describing SRTP-specific use. section completes it by describing SRTP-specific use.
skipping to change at page 21, line 36 skipping to change at page 21, line 45
and multipoint unicast streams is for further study. and multipoint unicast streams is for further study.
6.1.1 Generating the Initial Offer - Unicast Streams 6.1.1 Generating the Initial Offer - Unicast Streams
When the initial offer is generated, the offerer MUST follow the When the initial offer is generated, the offerer MUST follow the
steps in Section 4.1.1 as well as the following steps. steps in Section 4.1.1 as well as the following steps.
For each unicast media line (m=) using the secure RTP transport For each unicast media line (m=) using the secure RTP transport
where the offerer wants to specify cryptographic parameters, the where the offerer wants to specify cryptographic parameters, the
offerer MUST provide at least one valid SRTP security description offerer MUST provide at least one valid SRTP security description
("a=crypto" line), as defined in Section 5. ("a=crypto" line), as defined in Section 5. If the media stream
includes Forward Error Correction with a different IP-address and/or
port than the media stream itself, a FEC_KEY parameter MUST be
included, as described in Section 5.3.5.
The offerer MAY include one or more other SRTP session parameters as The offerer MAY include one or more other SRTP session parameters as
defined in Section 5.3. Note however, that if any SRTP session defined in Section 5.3. Note however, that if any SRTP session
parameters are included that are not known to the answerer, but are parameters are included that are not known to the answerer, but are
nonetheless mandatory (see Section 5.3.6), the negotiation will fail nonetheless mandatory (see Section 5.3.6), the negotiation will fail
if the answerer does not support them. if the answerer does not support them.
6.1.2 Generating the Initial Answer - Unicast Streams 6.1.2 Generating the Initial Answer - Unicast Streams
When the initial answer is generated, the answerer MUST follow the When the initial answer is generated, the answerer MUST follow the
steps in Section 4.1.2 as well as the following steps. steps in Section 4.1.2 as well as the following steps.
For each unicast media line which uses the secure RTP transport and For each unicast media line which uses the secure RTP transport and
contains one or more "a=crypto" lines in the offer, the answerer contains one or more "a=crypto" lines in the offer, the answerer
MUST either accept one (and only one) of the crypto lines for that MUST either accept one (and only one) of the crypto lines for that
media stream, or it MUST reject the media stream. Only "a=crypto" media stream, or it MUST reject the media stream. Only "a=crypto"
lines that are considered valid SRTP security descriptions as lines that are considered valid SRTP security descriptions as
defined in Section 5 can be accepted. Furthermore, all parameters defined in Section 5 can be accepted. Furthermore, all parameters
(crypto-suite, key parameter, and mandatory session parameters) MUST (crypto-suite, key parameter, and mandatory session parameters) MUST
be acceptable to the answerer in order for the offered media stream be acceptable to the answerer in order for the offered media stream
to be accepted. to be accepted. Note that if the media stream includes Forward
Error Correction with a different IP-address and/or port than the
media stream itself, a FEC_KEY parameter MUST be included, as
described in Section 5.3.5.
When the answerer accepts an SRTP unicast media stream with a crypto When the answerer accepts an SRTP unicast media stream with a crypto
line, the answerer MUST include one or more master keys appropriate line, the answerer MUST include one or more master keys appropriate
for the selected crypto algorithm; the master key(s) included in the for the selected crypto algorithm; the master key(s) included in the
answer MUST be different from those in the offer. answer MUST be different from those in the offer.
When the master key(s) are not shared between the offerer and When the master key(s) are not shared between the offerer and
answerer, SSRC collisions between the offerer and answerer will answerer, SSRC collisions between the offerer and answerer will
not lead to keystream reuse, and hence SSRC collisions do not not lead to keystream reuse, and hence SSRC collisions do not
necessarily have to be prevented. necessarily have to be prevented.
If Forward Error Correction to a separate IP-address and/or port is
included, the answer MUST include a FEC_KEY parameter, as described
in Section 5.3.5.
Declarative session parameters may be added to the answer as usual, Declarative session parameters may be added to the answer as usual,
however the answerer SHOULD NOT add any mandatory session parameter however the answerer SHOULD NOT add any mandatory session parameter
(see Section 5.3.6) that might be unknown to the offerer. (see Section 5.3.6) that might be unknown to the offerer.
If the answerer cannot find any valid crypto line that it supports, If the answerer cannot find any valid crypto line that it supports,
or if its configured policy prohibits any cryptographic key or if its configured policy prohibits any cryptographic key
parameter (e.g., key length) or cryptographic session parameter parameter (e.g., key length) or cryptographic session parameter
(e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it (e.g., KDR, FEC_ORDER), it MUST reject the media stream, unless it
is able to successfully negotiate use of SRTP by other means outside is able to successfully negotiate use of SRTP by other means outside
the scope of this document (e.g., by use of MIKEY [mikey]). the scope of this document (e.g., by use of MIKEY [mikey]).
6.1.3 Offerer Processing of the Initial Answer - Unicast Streams 6.1.3 Offerer Processing of the Initial Answer - Unicast Streams
When the offerer receives the answer, it MUST perform the steps in When the offerer receives the answer, it MUST perform the steps in
Section 4.1.3 as well as the following steps for each SRTP media Section 4.1.3 as well as the following steps for each SRTP media
stream it offered with one or more crypto lines in it. stream it offered with one or more crypto lines in it.
If the media stream was accepted and it contains a crypto line, it If the media stream was accepted and it contains a crypto line, it
MUST be checked that the crypto line is valid according to the MUST be checked that the crypto line is valid according to the
constraints specified in Section 5. constraints specified in Section 5 (including any FEC constraints).
If the offerer either does not support or is not willing to honor If the offerer either does not support or is not willing to honor
one or more of the SRTP parameters in the answer, the offerer MUST one or more of the SRTP parameters in the answer, the offerer MUST
consider the crypto line invalid. consider the crypto line invalid.
If the crypto line is not valid, or the offerer's configured policy If the crypto line is not valid, or the offerer's configured policy
prohibits any cryptographic key parameter (e.g. key length) or prohibits any cryptographic key parameter (e.g. key length) or
cryptographic session parameter, the SRTP security negotiation MUST cryptographic session parameter, the SRTP security negotiation MUST
be deemed to have failed. be deemed to have failed.
skipping to change at page 23, line 27 skipping to change at page 23, line 47
RFC 3264 defines a couple of techniques to address this problem, RFC 3264 defines a couple of techniques to address this problem,
e.g., changing the payload types used and/or the transport e.g., changing the payload types used and/or the transport
addresses. Note however that a change in transport addresses may addresses. Note however that a change in transport addresses may
have an impact on Quality of Service as well as firewall and NAT have an impact on Quality of Service as well as firewall and NAT
traversal. The SRTP security descriptions offers two other ways traversal. The SRTP security descriptions offers two other ways
of dealing with this; use the MKI (which adds a few bytes to each of dealing with this; use the MKI (which adds a few bytes to each
SRTP packet) or the <"From","To"> mechanism (which doesn't add SRTP packet) or the <"From","To"> mechanism (which doesn't add
bytes to each SRTP packet) as described in Section 5.1. For bytes to each SRTP packet) as described in Section 5.1. For
further details on MKI and "<"From","To">, please refer to [srtp]. further details on MKI and "<"From","To">, please refer to [srtp].
* If the answerer changes its master key, the offerer will not be * If the answerer changes its master key, the offerer will not
able to process packets secured via this master key until the be able to process packets secured via this master key until the
answer is received. answer is received. This could be addressed by using a security
"precondition" [sprecon].
As noted in Section 4.1.1, this could for example be addressed by If the offerer includes an IP address and/or port that differs from
using a security "precondition" [sprecon]. that used previously for a media stream (or FEC stream), the offerer
MUST include a new master key with the offer (and in so doing, it
will be creating a new crypto context with the ROC set to zero).
Similarly, if the answerer includes an IP address and/or port that
differs from that used previously for a media stream (or FEC
stream), the answerer MUST include a new master key with the offer
(and hence create a new crypto context with the ROC set to zero).
The reason for this is, that when the answerer receives an offer, or
the offerer receives an answer, with an updated IP address and/or
port, it is not possible to determine if the other side has access
to the old crypto context parameters (and in particular the ROC) or
not. For example, if one side is a decomposed gateway, or a back-
to-back user agent is involved, it is possible that the media
endpoint changed and no longer has access to the old crypto context.
By always requiring a new master key in this case, the
answerer/offerer will know that the ROC is zero for this
offer/answer, and any key lifetime constraints will trivially be
satisfied too. Another consideration here applies to media relays;
if the relay changes the media endpoint on one side transparently to
the other side, the relay cannot operate as a simple packet
reflector but will have to actively engage in SRTP packet processing
and transformation (i.e., decryption and re-encryption, etc.).
Finally note, that if the new offer is rejected, the old crypto Finally note, that if the new offer is rejected, the old crypto
parameters remain in place. parameters remain in place.
6.1.5 Offer/Answer Example 6.1.5 Offer/Answer Example
In this example, the offerer supports two crypto suites (F8 and In this example, the offerer supports two crypto suites (F8 and
AES). The a=crypto line is actually one long line, although it is AES). The a=crypto line is actually one long line, although it is
shown as two lines in this document due to page formatting. shown as two lines in this document due to page formatting.
skipping to change at page 24, line 41 skipping to change at page 25, line 18
t=2873397526 2873405696 t=2873397526 2873405696
m=audio 32640 RTP/SAVP 0 m=audio 32640 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4
In this case, the session would use the AES_CM_128_HMAC_SHA1_80 In this case, the session would use the AES_CM_128_HMAC_SHA1_80
crypto suite for the RTP and RTCP traffic. crypto suite for the RTP and RTCP traffic.
6.2 SRTP-Specific Use Outside Offer/Answer 6.2 SRTP-Specific Use Outside Offer/Answer
These are the same as Section 4.2. Use of SRTP security descriptions outside the offer/answer model is
not defined.
Use of SRTP security descriptions outside offer/answer could have
been defined for sendonly media streams, however, there would not
be a way to indicate the key to use for SRTCP by the receiver of
said media stream.
6.3 Support for SIP Forking 6.3 Support for SIP Forking
As mentioned earlier, the security descriptions defined here do not As mentioned earlier, the security descriptions defined here do not
support multicast media streams or multipoint unicast streams. support multicast media streams or multipoint unicast streams.
However, in the SIP protocol, it is possible to receive several However, in the SIP protocol, it is possible to receive several
answers to a single offer due to the use of forking (see [SIP]). answers to a single offer due to the use of forking (see [SIP]).
Receiving multiple answers leads to a couple of problems for the Receiving multiple answers leads to a couple of problems for the
SRTP security descriptions: SRTP security descriptions:
skipping to change at page 29, line 17 skipping to change at page 29, line 47
ftval = roc ":" seq ; packet index expressed in terms ftval = roc ":" seq ; packet index expressed in terms
; of ROC and SEQ. ; of ROC and SEQ.
roc = 1*DIGIT ; range 0..2^32-1 roc = 1*DIGIT ; range 0..2^32-1
seq = 1*DIGIT ; range 0..2^16-1 seq = 1*DIGIT ; range 0..2^16-1
srtp-session-param = kdr / srtp-session-param = kdr /
"UNENCRYPTED_SRTP" / "UNENCRYPTED_SRTP" /
"UNENCRYPTED_SRTCP" / "UNENCRYPTED_SRTCP" /
"UNAUTHENTICATED_SRTP" / "UNAUTHENTICATED_SRTP" /
fec-order / fec-order /
fec-key /
wsh / wsh /
srtp-session-extension srtp-session-extension
kdr = "KDR=" 1*2(DIGIT) ; range 0..24, power of two kdr = "KDR=" 1*2(DIGIT) ; range 0..24, power of two
fec-order = "FEC_ORDER=" fec-type fec-order = "FEC_ORDER=" fec-type
fec-type = "FEC_SRTP" / "SRTP_FEC" / "SPLIT" fec-type = "FEC_SRTP" / "SRTP_FEC"
fec-key = "FEC_KEY=" key-params
wsh = "WSH=" 2*DIGIT ; minimum value is 64 wsh = "WSH=" 2*DIGIT ; minimum value is 64
base64 = ALPHA / DIGIT / "+" / "/" / "=" base64 = ALPHA / DIGIT / "+" / "/" / "="
srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_") srtp-crypto-suite-ext = 1*(ALPHA / DIGIT / "_")
srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC2234] srtp-session-extension = ["-"] 1*(VCHAR) ;visible chars [RFC2234]
; first character must not be dash ("-") ; first character must not be dash ("-")
9. IANA Considerations 9. IANA Considerations
skipping to change at page 30, line 26 skipping to change at page 31, line 9
| | | |
| +- session parameters | +- session parameters
| |
+- Transport2 +- Transport2
: : : :
9.2.1Security Descriptions Key Method Registry and Registration 9.2.1Security Descriptions Key Method Registry and Registration
The IANA is hereby requested to create a new subregistry for SDP The IANA is hereby requested to create a new subregistry for SDP
security description key methods. An IANA key method registration security description key methods. An IANA key method registration
MUST be documented in an IETF Standards Track RFC and it MUST MUST be documented in an RFC in accordance with the RFC 2434
provide the name of the key method in accordance with the grammar Standards Action and it MUST provide the name of the key method in
for key-method-ext defined in Section 8.1. accordance with the grammar for key-method-ext defined in Section
8.1.
9.2.2Security Description Media Stream Transport Registry and 9.2.2Security Description Media Stream Transport Registry and
Registration Registration
The IANA is hereby requested to create a new subregistry for SDP The IANA is hereby requested to create a new subregistry for SDP
security description Media Stream Transports. An IANA media stream security description Media Stream Transports. An IANA media stream
transport registration MUST be documented in an RFC in accordance transport registration MUST be documented in an RFC in accordance
with the procedures defined in Section 3 and 4 of this document. with the RFC 2434 Standards Action and the procedures defined in
The registration MUST provide the name of the transport and a list Section 3 and 4 of this document. The registration MUST provide the
of supported key methods. name of the transport and a list of supported key methods.
In addition, each new media stream transport registry must contain a In addition, each new media stream transport registry must contain a
crypto-suite registry and a session parameter registry as well as crypto-suite registry and a session parameter registry as well as
IANA instructions for how to populate these registries. IANA instructions for how to populate these registries.
9.3 Initial Registrations 9.3 Initial Registrations
9.3.1 Key Method 9.3.1 Key Method
The following security descriptions key methods are hereby The following security descriptions key methods are hereby
skipping to change at page 31, line 20 skipping to change at page 31, line 52
description for SRTP is this document. description for SRTP is this document.
9.3.2.1 SRTP Crypto Suite Registry and Registration 9.3.2.1 SRTP Crypto Suite Registry and Registration
The IANA is hereby requested to create a new subregistry for SRTP The IANA is hereby requested to create a new subregistry for SRTP
crypto suites under the SRTP transport of the SDP Security crypto suites under the SRTP transport of the SDP Security
Descriptions. An IANA SRTP crypto suite registration MUST indicate Descriptions. An IANA SRTP crypto suite registration MUST indicate
the crypto suite name in accordance with the grammar for srtp- the crypto suite name in accordance with the grammar for srtp-
crypto-suite-ext defined in Section 8.2. crypto-suite-ext defined in Section 8.2.
The semantics of the SRTP crypto suite MUST be described in an IETF The semantics of the SRTP crypto suite MUST be described in an RFC
RFC, including the semantics of the "inline" key-method and any in accordance with the RFC 2434 Standards Action, including the
special semantics of parameters. semantics of the "inline" key-method and any special semantics of
parameters.
The following SRTP crypto suites are hereby registered: The following SRTP crypto suites are hereby registered:
AES_CM_128_HMAC_SHA1_80 AES_CM_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_32 AES_CM_128_HMAC_SHA1_32
F8_128_HMAC_SHA1_80 F8_128_HMAC_SHA1_80
The reference for these crypto-suites is provided in this document. The reference for these crypto-suites is provided in this document.
9.3.2.2 SRTP Session Parameter Registration 9.3.2.2 SRTP Session Parameter Registration
The IANA is hereby requested to create a new subregistry for SRTP The IANA is hereby requested to create a new subregistry for SRTP
session parameters under the SRTP transport of the SDP Security session parameters under the SRTP transport of the SDP Security
Descriptions. An IANA SRTP session parameter registration MUST Descriptions. An IANA SRTP session parameter registration MUST
indicate the session parameter name (srtp-session-extension as indicate the session parameter name (srtp-session-extension as
defined in Section 8.2); the name MUST NOT begin with the dash defined in Section 8.2); the name MUST NOT begin with the dash
character ("-"). character ("-").
The semantics of the parameter MUST be described in an IETF RFC. If The semantics of the parameter MUST be described in an RFC in
values can be assigned to the parameter, then the format and accordance with the RFC 2434 Standards Action. If values can be
possible values that can be assigned MUST be described in the IETF assigned to the parameter, then the format and possible values that
RFC as well. Also, it MUST be specified whether the parameter is can be assigned MUST be described in the RFC in accordance with the
declarative or negotiated in the offer/answer model. RFC 2434 Standards Action as well. Also, it MUST be specified
whether the parameter is declarative or negotiated in the
offer/answer model.
The following SRTP session parameters are hereby registered: The following SRTP session parameters are hereby registered:
SRC
KDR KDR
UNENCRYPTED_SRTP UNENCRYPTED_SRTP
UNENCRYPTED_SRTCP UNENCRYPTED_SRTCP
UNAUTHENTICATED_SRTP UNAUTHENTICATED_SRTP
FEC_ORDER FEC_ORDER
FEC_KEY
WSH WSH
The reference for these parameters is this document. The reference for these parameters is this document.
10. Acknowledgements 10. Acknowledgements
This document is a product of the IETF MMUSIC working group and has This document is a product of the IETF MMUSIC working group and has
benefited from comments from its participants. This document also benefited from comments from its participants. This document also
benefited from discussions with Elisabetta Cararra, Earl Carter, benefited from discussions with Elisabetta Cararra, Earl Carter,
Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David Bill Foster, Matt Hammer, Cullen Jennings, Paul Kyzivat, David
McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer, McGrew, Mats Naslund, Dave Oran, Jonathan Rosenberg, Dave Singer,
Mike Thomas, Brian Weis, and Magnus Westerlund. These people shared Mike Thomas, Brian Weis, and Magnus Westerlund. These people shared
skipping to change at page 33, line 5 skipping to change at page 33, line 40
12. Normative References 12. Normative References
[RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC 3550, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550,
July 2003, http://www.ietf.org/rfc/rfc3550.txt. July 2003, http://www.ietf.org/rfc/rfc3550.txt.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF," RFC 2234, November 1997, Specifications: ABNF," RFC 2234, November 1997,
http://www.ietf.org/rfc/rfc2234.txt. http://www.ietf.org/rfc/rfc2234.txt.
[SDP] M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description [SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol",
Protocol", Work in Progress. RFC 2327, April 1998.
[RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for [RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999, Generic Forward Error Correction", RFC 2733, December 1999,
http://www.ietf.org/rfc/rfc2733.txt. http://www.ietf.org/rfc/rfc2733.txt.
[RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May [RFC2828] R. Shirey, "Internet Security Glossary", RFC 2828, May
2000, http://www.ietf.org/rfc/rfc2828.txt. 2000, http://www.ietf.org/rfc/rfc2828.txt.
[RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with [RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2202, the Session Description Protocol (SDP)", RFC 3264, June 2202,
http://www.ietf.org/rfc/rfc3264.txt. http://www.ietf.org/rfc/rfc3264.txt.
[srtp] M. Baugher, R. Blom, E. Carrara, D. McGrew, M. Naslund, K. [srtp] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman,
Norrman, D. Oran, "The Secure Real-time Transport Protocol", Work in "The Secure Real-time Transport Protocol", RFC 3711, March 2004.
Progress.
[RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness [RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994, Recommendations for Security", RFC 1750, December 1994,
http://www.ietf.org/rfc/rfc1750.txt. http://www.ietf.org/rfc/rfc1750.txt.
[RFC3548] S. Josefsson, "The Base16, Base32, and Base64 Data [RFC3548] S. Josefsson, "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003. Encodings", RFC 3548, July 2003.
[RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
13. Informative References 13. Informative References
[RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple
Capability Declaration", RFC 3407, October 2002, Capability Declaration", RFC 3407, October 2002,
http://www.ietf.org/rfc/rfc3407.txt. http://www.ietf.org/rfc/rfc3407.txt.
[Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security [Bellovin] Steven M. Bellovin, "Problem Areas for the IP Security
Protocols," in Proceedings of the Sixth Usenix Unix Security Protocols," in Proceedings of the Sixth Usenix Unix Security
Symposium, pp. 1-16, San Jose, CA, July 1996. Symposium, pp. 1-16, San Jose, CA, July 1996.
skipping to change at page 34, line 7 skipping to change at page 34, line 44
[ike] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC [ike] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC
2409, November 1998, http://www.ietf.org/rfc/rfc2409.txt. 2409, November 1998, http://www.ietf.org/rfc/rfc2409.txt.
[ipsec] Kent, S. and R. Atkinson, "Security Architecture for the [ipsec] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998, Internet Protocol", RFC 2401, November 1998,
http://www.ietf.org/rfc/rfc2401.txt. http://www.ietf.org/rfc/rfc2401.txt.
[s/mime] Ramsdell B., "S/MIME Version 3 Message Specification", RFC [s/mime] Ramsdell B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999, http://www.ietf.org/rfc/rfc2633.txt. 2633, June 1999, http://www.ietf.org/rfc/rfc2633.txt.
[pgp/mime] M. Elkins, "MIME Security with Pretty Good Privacy
(PGP)", RFC 2015, October 1996, http://www.ietf.org/rfc/rfc2015.txt.
[tls] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [tls] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999, http://www.ietf.org/rfc/rfc2246.txt. 2246, January 1999, http://www.ietf.org/rfc/rfc2246.txt.
[keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, [keymgt] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman,
"Key Management Extensions for SDP and RTSP", Work in Progress. "Key Management Extensions for SDP and RTSP", Work in Progress.
[mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, [mikey] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman,
"MIKEY: Multimedia Internet KEYing", Work in Progress. "MIKEY: Multimedia Internet KEYing", Work in Progress.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/