draft-ietf-mmusic-sdescriptions-05.txt   draft-ietf-mmusic-sdescriptions-06.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: December 2004 Cisco Systems EXPIRES: January 2005 Cisco Systems
June, 2004 July, 2004
Session Description Protocol Security Descriptions Session Description Protocol Security Descriptions
for Media Streams for Media Streams
<draft-ietf-mmusic-sdescriptions-05.txt> <draft-ietf-mmusic-sdescriptions-06.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, the authors certify that any
all provisions of Section 10 of RFC2026. applicable patent or other IPR claims of which we are aware have been
disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, the authors accept the provisions
of Section 3 of RFC 3667 (BCP 78).
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
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/lid-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
skipping to change at page 2, line ? skipping to change at page 2, line ?
describes a cryptographic key and other parameters, which serve to describes a cryptographic key and other parameters, which serve to
configure security for a unicast media stream in either a single configure security for a unicast media stream in either a single
message or a roundtrip exchange. The attribute can be used with a message or a roundtrip exchange. The attribute can be used with a
variety of SDP media transports and this document defines how to use variety of SDP media transports and this document defines how to use
it for the Secure Real-time Transport Protocol (SRTP) unicast media it for the Secure Real-time Transport Protocol (SRTP) unicast media
streams. The SDP crypto attribute requires the services of a data streams. The SDP crypto attribute requires the services of a data
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..............................................7 3.4 Session Parameters.............................................7
3.5 Example.........................................................7 3.5 Example........................................................7
4. General Use of the crypto Attribute...............................8 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 Processing of the Initial Answer - Unicast Streams........10 4.1.3 Processing of the Initial Answer - Unicast Streams.......10
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 FEC_KEY=key-params........................................17 5.3.5 FEC_KEY=key-params.......................................17
5.3.6 Window Size Hint (WSH)....................................18 5.3.6 Window Size Hint (WSH)...................................18
5.3.7 Defining New SRTP Session Parameters......................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.4.1 Late Binding of one or more SSRCs to a crypto context....19
6. SRTP-Specific Use of the crypto Attribute........................21 5.4.2 Sharing cryptographic contexts among SSRCs...............20
6.1 Use with Offer/Answer..........................................21 5.5 Removal of Crypto Contexts....................................21
6.1.1 Generating the Initial Offer - Unicast Streams............21 6. SRTP-Specific Use of the crypto Attribute.......................21
6.1.2 Generating the Initial Answer - Unicast Streams...........22 6.1 Use with Offer/Answer.........................................21
6.1.3 Processing of the Initial Answer - Unicast Streams........22 6.1.1 Generating the Initial Offer - Unicast Streams...........21
6.1.4 Modifying the Session.....................................23 6.1.2 Generating the Initial Answer - Unicast Streams..........22
6.1.5 Offer/Answer Example......................................24 6.1.3 Processing of the Initial Answer - Unicast Streams.......23
6.2 SRTP-Specific Use Outside Offer/Answer.........................25 6.1.4 Modifying the Session....................................23
6.3 Support for SIP Forking........................................25 6.1.5 Offer/Answer Example.....................................24
6.4 SRTP-Specific Backwards Compatibility Considerations...........26 6.2 SRTP-Specific Use Outside Offer/Answer........................25
6.5 Operation with KEYMGT= and k= lines............................26 6.3 Support for SIP Forking.......................................26
7. Security Considerations..........................................26 6.4 SRTP-Specific Backwards Compatibility Considerations..........26
7.1 Authentication of packets......................................26 6.5 Operation with KEYMGT= and k= lines...........................27
7.2 Keystream Reuse................................................27 7. Security Considerations.........................................27
7.3 Signaling Authentication and Signaling Encryption..............27 7.1 Authentication of packets.....................................27
8. Grammar..........................................................28 7.2 Keystream Reuse...............................................27
8.1 Generic "Crypto" Attribute Grammar.............................28 7.3 Signaling Authentication and Signaling Encryption.............28
8.2 SRTP "Crypto" Attribute Grammar................................29 8. Grammar.........................................................29
9. IANA Considerations..............................................30 8.1 Generic "Crypto" Attribute Grammar............................29
9.1 Registration of the "crypto" attribute.........................30 8.2 SRTP "Crypto" Attribute Grammar...............................29
9.2 New IANA Registries and Registration Procedures................30 9. IANA Considerations.............................................30
9.2.1 Key Method Registry and Registration......................30 9.1 Registration of the "crypto" attribute........................30
9.2.2 Media Stream Transport Registry and Registration..........31 9.2 New IANA Registries and Registration Procedures...............30
9.3 Initial Registrations..........................................31 9.2.1 Key Method Registry and Registration.....................31
9.3.1 Key Method................................................31 9.2.2 Media Stream Transport Registry and Registration.........31
9.3.2 SRTP Media Stream Transport...............................31 9.3 Initial Registrations.........................................31
10. Acknowledgements................................................32 9.3.1 Key Method...............................................31
11. Authors' Addresses..............................................33 9.3.2 SRTP Media Stream Transport..............................32
12. Normative References............................................33 10. Acknowledgements...............................................33
13. Informative References..........................................34 11. Authors' Addresses.............................................33
Intellectual Property Statement.....................................35 12. Normative References...........................................34
Acknowledgement.....................................................36 13. Informative References.........................................34
14. Full Copyright Statement.......................................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
skipping to change at page 6, line 25 skipping to change at page 6, line 25
key-params = <key-method> ":" <key-info> key-params = <key-method> ":" <key-info>
Keying material might be provided by different means than key-params, Keying material might be provided by different means than key-params,
however this is out of scope. Only one method is defined in this however this is out of scope. Only one method is defined in this
document, namely "inline", which indicates that the actual keying document, namely "inline", which indicates that the actual keying
material is provided in the key-info field itself. There is a single material is provided in the key-info field itself. There is a single
name space for the key-method, i.e., the key-method is transport name space for the key-method, i.e., the key-method is transport
independent. New key-methods (e.g., use of a URL) may be defined in independent. New key-methods (e.g., use of a URL) may be defined in
a Standards Track RFC in the future. Although the key-method itself a Standards Track RFC in the future. Although the key-method itself
may be generic, the accompanying key-info definition is specific not may be generic, the accompanying key-info definition is specific not
only to the key-method, but also to the transport in question. New only to the key-method, but also to the transport in question. Key-
key methods MUST be registered with the IANA according to the info encodes keying material for a crypto suite, which defines that
procedures defined in Section 9.2.1. keying material. New key methods MUST be registered with the IANA
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 a Standards Track RFC for each semantics MUST be provided in a Standards Track RFC for each
combination of transport and key-method that use it; definitions for combination of transport and key-method that use it; definitions for
SRTP are provided in Section 5. Note that such definitions are SRTP are provided in Section 5. Note that such definitions are
provided within the context of both a particular transport (e.g., provided within the context of both a particular transport (e.g.,
"RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will "RTP/SAVP") and a specific key-method (e.g., "inline"). IANA will
register the list of supported key methods for each transport. register the list of supported key methods for each transport.
skipping to change at page 11, line 30 skipping to change at page 11, line 30
use the same descriptions, which are in accordance with the SRTP use the same descriptions, which are in accordance with the SRTP
protocol specification [srtp]. 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. Such an endpoint will not correctly
assume use of default SRTP parameters, if it supports SRTP but not process the particular media stream. By using the Offer/Answer
the crypto attribute. Such an endpoint will not correctly process model, the offerer and answerer can negotiate the crypto parameters
the particular media stream. By using the Offer/Answer model, the to be used before commencement of the multimedia session (see Section
offerer and answerer can negotiate the crypto parameters to be used 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, however, 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
skipping to change at page 14, line 16 skipping to change at page 14, line 16
(MKI) and its byte length. (MKI) and its byte length.
"MKI" is the master key identifier associated with the SRTP master "MKI" is the master key identifier associated with the SRTP master
key. If the MKI is given, then the length of the MKI MUST also be key. If the MKI is given, then the length of the MKI MUST also be
given and separated from the MKI by a colon (":"). The MKI length is given and separated from the MKI by a colon (":"). The MKI length is
the size of the MKI field in the SRTP packet, specified in bytes. If the size of the MKI field in the SRTP packet, specified in bytes. If
the MKI length is not given or its value exceeds 128 (bytes), then the MKI length is not given or its value exceeds 128 (bytes), then
the entire crypto attribute MUST be considered invalid. The the entire crypto attribute MUST be considered invalid. The
substring "1:4" in the first example assigns to the key a master key substring "1:4" in the first example assigns to the key a master key
identifier of 1 that is 4 bytes long, and the second example assigns identifier of 1 that is 4 bytes long, and the second example assigns
a 4-byte master key identifier of 1066 to the key. a 4-byte master key identifier of 1066 to the key. One or more
master keys with their associated MKI can be initially defined, and
then later updated, or deleted and new ones defined.
SRTP offers a second feature for specifying the lifetime of a master SRTP offers a second feature for specifying the lifetime of a master
key in terms of two values, called "From" and "To," which are defined key in terms of two values, called "From" and "To," which are defined
on the SRTP sequence number space [srtp]. This SRTP Security on the SRTP sequence number space [srtp]. This SRTP Security
Descriptions specification, however, does not support the Descriptions specification, however, does not support the
<"From","To"> feature since the lifetime of an AES master key is 2^48 <"From","To"> feature since the lifetime of an AES master key is 2^48
SRTP packets, which means that there is no cryptographic reason to SRTP packets, which means that there is no cryptographic reason to
replace a master key for practical point-to-point applications. For replace a master key for practical point-to-point applications. For
this reason, there is no need to support two means for signaling key this reason, there is no need to support two means for signaling key
update. The MKI is chosen over <"From","To"> by this specification update. The MKI is chosen over <"From","To"> by this specification
skipping to change at page 16, line 39 skipping to change at page 16, line 39
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
KDR specifies the Key Derivation Rate, as described in section 4.3.1 KDR specifies the Key Derivation Rate, as described in section 4.3.1
of [srtp]. of [srtp].
The value n MUST be an integer in the set {1,2,...,24}, which The value n MUST be an integer in the set {1,2,...,24}, which
denotes a power of 2 from 2^1 to 2^24, inclusive. The SRTP key denotes a power of 2 from 2^1 to 2^24, inclusive. The SRTP key
derivation rate controls how frequently a new session key is derived derivation rate controls how frequently a new session key is derived
from an SRTP master key [srtp]. When the key derivation rate is not from an SRTP master key(s) [srtp] given in the declaration. When
specified (i.e., the KDR parameter is omitted), a single initial key the key derivation rate is not specified (i.e., the KDR parameter is
derivation is performed [srtp]. omitted), a single initial key derivation is performed [srtp].
In the offer/answer model, KDR is a declarative parameter. In the offer/answer model, KDR is a declarative parameter.
5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP 5.3.2 UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP
SRTP and SRTCP packet payloads are encrypted by default. The SRTP and SRTCP packet payloads are encrypted by default. The
UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the UNENCRYPTED_SRTCP and UNENCRYPTED_SRTP session parameters modify the
default behavior of the crypto-suites with which they are used: default behavior of the crypto-suites with which they are used:
* UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not * UNENCRYPTED_SRTCP signals that the SRTCP packet payloads are not
skipping to change at page 18, line 16 skipping to change at page 18, line 16
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" [maxprate] and the bandwidth modifiers to allow a
derive the parameter satisfactorily. Consequently, this value is receiver to derive the parameter satisfactorily. Consequently, this
only considered a hint to the receiver of the SDP which MAY choose value is only considered a hint to the receiver of the SDP which MAY
to ignore the value provided. choose 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.7 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 a Standards Track RFC and registered with IANA be defined in a Standards Track RFC and registered with IANA
according to the 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-
skipping to change at page 19, line 48 skipping to change at page 19, line 48
number value and put the receiver in an ambiguous situation: If number value and put the receiver in an ambiguous situation: If
initial packets are lost in transit up to the point that the sequence initial packets are lost in transit up to the point that the sequence
number wraps (i.e., exceeds 2^16-1), then the receiver might not number wraps (i.e., exceeds 2^16-1), then the receiver might not
recognize that its ROC needs to be incremented. By restricting the recognize that its ROC needs to be incremented. By restricting the
initial SEQ to the range of 0..2^15-1, SRTP packet-index initial SEQ to the range of 0..2^15-1, SRTP packet-index
determination will find the correct ROC value, unless all of the determination will find the correct ROC value, unless all of the
first 2^15 packets are lost (which seems, if not impossible, then first 2^15 packets are lost (which seems, if not impossible, then
rather unlikely). See Section 3.3.1 of the SRTP specification rather unlikely). See Section 3.3.1 of the SRTP specification
regarding packet-index determination [srtp]. regarding packet-index determination [srtp].
5.4.1 Late Binding of one or more SSRCs to a crypto context
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. uniqueness.
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" is security descriptions. Instead, an approach called "late binding" is
RECOMMENDED by this specification. When a packet arrives, the SSRC RECOMMENDED by this specification. When a packet arrives, the SSRC
that is contained in it can be bound to the crypto context at the that is contained in it can be bound to the crypto context at the
skipping to change at page 20, line 45 skipping to change at page 20, line 48
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 will result in Note that use of late binding without authentication will result in
local state being created as a result of receiving a packet from local state being created as a result of receiving a packet from
any unknown SSRC. UNAUTHENTICATED_SRTP, therefore is NOT 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.
5.4.2 Sharing cryptographic contexts among SSRCs
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. So there are no a=crypto parameters for signaling SSRC,
ROC or SEQ. Thus, multiple SSRCs will share a=crypto parameters when
late binding is used and when an SDP media line references a payload
type that generates multiple SSRCs. An application that uses
a=crypto in this way serially shares a master key among sessions and
MUST replace the master key when the aggregate number of packets
among all sessions approaches 2^31 packets. SSRCs that share a
master key MUST be unique from one another.
5.5 Removal of Crypto Contexts 5.5 Removal of Crypto Contexts
The mechanism defined above addresses the issue of creating crypto The mechanism defined above addresses the issue of creating crypto
contexts, however in practice, session participants may want to contexts, however in practice, session participants may want to
remove crypto contexts prior to session termination. Since a crypto remove crypto contexts prior to session termination. Since a crypto
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.
skipping to change at page 28, line 48 skipping to change at page 29, line 27
crypto attribute, and then we provide the ABNF grammar for the SRTP crypto attribute, and then we provide the ABNF grammar for the SRTP
specific use of the crypto attribute. specific use of the crypto attribute.
8.1 Generic "Crypto" Attribute Grammar 8.1 Generic "Crypto" Attribute Grammar
The ABNF grammar for the crypto attribute is defined below: The ABNF grammar for the crypto attribute is defined below:
"a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params "a=crypto:" tag 1*WSP crypto-suite 1*WSP key-params
*(1*WSP session-param) *(1*WSP session-param)
tag = 1*ALPHANUM tag = 1*9DIGIT
crypto-suite = 1*(ALPHA / DIGIT / "_") crypto-suite = 1*(ALPHA / DIGIT / "_")
key-params = key-param *(";" key-param) key-params = key-param *(";" key-param)
key-param = key-method ":" key-info key-param = key-method ":" key-info
key-method = "inline" / key-method-ext key-method = "inline" / key-method-ext
key-method-ext = 1*(ALPHA / DIGIT / "_") key-method-ext = 1*(ALPHA / DIGIT / "_")
key-info = %x21-3A / %x3C-7E ; visible (printing) characters key-info = %x21-3A / %x3C-7E ; visible (printing) characters
; except semi-colon ; except semi-colon
session-param = 1*(VCHAR) ; visible (printing) characters session-param = 1*(VCHAR) ; visible (printing) characters
skipping to change at page 33, line 28 skipping to change at page 34, line 9
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
dwing@cisco.com dwing@cisco.com
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. STD 64, 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, "SDP: Session Description Protocol", [SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998. RFC 2327, April 1998.
[RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999,
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, D. McGrew, M. Naslund, E. Carrara, K. Norrman, [srtp] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman,
"The Secure Real-time Transport Protocol", RFC 3711, March 2004. "The Secure Real-time Transport Protocol", RFC 3711, March 2004.
skipping to change at page 34, line 35 skipping to change at page 35, line 12
[kink] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of [kink] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation of
Keys (KINK)", Work in Progress. Keys (KINK)", Work in Progress.
[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.
[maxprate] Westerlund, M., "A Transport-independent Bandwidth
Modifier for the Session Description Protocol (SDP)," April 2004,
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bwparam-
06.txt
[RFC2733] J. Rosenberg, H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999,
http://www.ietf.org/rfc/rfc2733.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/mime] M. Elkins, "MIME Security with Pretty Good Privacy
(PGP)", RFC 2015, October 1996, http://www.ietf.org/rfc/rfc2015.txt. (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,
skipping to change at page 35, line 32 skipping to change at page 36, line 16
RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003. RTCP-based Feedback (RTP/SAVPF)", work in progress, October 2003.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security [sprecon] Andreasen, F., Baugher, M., and D. Wing, "Security
Preconditions for Session Description Protocol Media Streams", work Preconditions for Session Description Protocol Media Streams", work
in progress, February 2004. in progress, February 2004.
Intellectual Property Statement 14. Full Copyright Statement
The IETF takes no position regarding the validity or scope of any Copyright (C) The Internet Society (2004). This document is subject
intellectual property or other rights that might be claimed to to the rights, licenses and restrictions contained in BCP 78 and
pertain to the implementation or use of the technology described in except as set forth therein, the authors retain all their rights.
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any This document and the information contained herein are provided on
copyrights, patents or patent applications, or other proprietary an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
rights which may cover technology that may be required to practice REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
this standard. Please address the information to the IETF Executive INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
Director. IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement Intellectual Property
Copyright(C) The Internet Society 2004. All Rights Reserved.
This document and translations of it may be copied and furnished to The IETF takes no position regarding the validity or scope of any
others, and derivative works that comment on or otherwise explain it Intellectual Property Rights or other rights that might be claimed
or assist in its implementation may be prepared, copied, published to pertain to the implementation or use of the technology
and distributed, in whole or in part, without restriction of any described in this document or the extent to which any license
kind, provided that the above copyright notice and this paragraph under such rights might or might not be available; nor does it
are included on all such copies and derivative works. However, this represent that it has made any independent effort to identify any
document itself may not be modified in any way, such as by removing such rights. Information on the procedures with respect to
the copyright notice or references to the Internet Society or other rights in RFC documents can be found in BCP 78 and BCP 79.
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copies of IPR disclosures made to the IETF Secretariat and any
revoked by the Internet Society or its successors or assigns. assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
This document and the information contained herein is provided on an The IETF invites any interested party to bring to its attention
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING any copyrights, patents or patent applications, or other
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING proprietary rights that may cover technology that may be required
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION to implement this standard. Please address the information to the
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF IETF at ietf-ipr@ietf.org.
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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