draft-ietf-mmusic-securityprecondition-02.txt   draft-ietf-mmusic-securityprecondition-03.txt 
Internet Engineering Task Force Flemming Andreasen Internet Engineering Task Force Flemming Andreasen
MMUSIC Working Group Dan Wing MMUSIC Working Group Dan Wing
Internet-Draft Internet-Draft
Expires: December 2006 Cisco Systems Expires: April 2006 Cisco Systems
June, 2006 Updates: RFC3312 (if accepted) October 19, 2006
Security Preconditions for Security Preconditions for
Session Description Protocol (SDP) Media Streams Session Description Protocol (SDP) Media Streams
<draft-ietf-mmusic-securityprecondition-02.txt> <draft-ietf-mmusic-securityprecondition-03.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 2, line ? skipping to change at page 2, line ?
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or cite them other than as "work in progress". reference 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
This Internet-Draft will expire on December 25, 2006. This Internet-Draft will expire on April 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved. Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract Abstract
This document defines a new security precondition for the Session This document defines a new security precondition for the Session
Description Protocol (SDP) precondition framework described in RFCs Description Protocol (SDP) precondition framework described in RFCs
3312 and 4032. A security precondition can be used to delay session 3312 and 4032. A security precondition can be used to delay session
establishment or modification until media stream security for a establishment or modification until media stream security for a
secure media stream has been negotiated successfully. secure media stream has been negotiated successfully.
1 Notational Conventions............................................2 1 Notational Conventions............................................2
2 Introduction......................................................2 2 Introduction......................................................2
3 Security Precondition Definition..................................3 3 Security Precondition Definition..................................3
4 Examples..........................................................6 4 Examples..........................................................6
4.1 SDP Security Descriptions Example.............................6 4.1 SDP Security Descriptions Example.............................6
4.2 Key Management Extension for SDP Example......................8 4.2 Key Management Extension for SDP Example......................8
5 Security Considerations..........................................11 5 Security Considerations..........................................11
6 IANA Considerations..............................................12 6 IANA Considerations..............................................13
7 Acknowledgements.................................................12 7 Acknowledgements.................................................13
8 Authors' Addresses...............................................13 8 Authors' Addresses...............................................13
9 Normative References.............................................13 9 Normative References.............................................13
10 Informative References.........................................13 10 Informative References.........................................13
11 Intellectual Property Statement................................15 11 Intellectual Property Statement................................15
1 Notational Conventions 1 Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 2, line ? skipping to change at page 2, line ?
alerting) a call. alerting) a call.
Media streams can either be provided in cleartext and with no Media streams can either be provided in cleartext and with no
integrity protection, or some kind of media security can be applied, integrity protection, or some kind of media security can be applied,
e.g., confidentiality and/or message integrity. For example, the e.g., confidentiality and/or message integrity. For example, the
Audio/Video profile of the Real-Time Transfer protocol (RTP) Audio/Video profile of the Real-Time Transfer protocol (RTP)
[RFC3551] is normally used without any security services whereas the [RFC3551] is normally used without any security services whereas the
Secure Real-time Transport Protocol (SRTP) [SRTP] is always used Secure Real-time Transport Protocol (SRTP) [SRTP] is always used
with security services. When media stream security is being with security services. When media stream security is being
negotiated, e.g., using the mechanism defined in SDP Security negotiated, e.g., using the mechanism defined in SDP Security
Descriptions [SDESC], both the offerer and the answerer need to know Descriptions [SDESC], both the offerer and the answerer [OFFANS]
the cryptographic parameters being used for the media stream; the need to know the cryptographic parameters being used for the media
offerer may provide multiple choices for the cryptographic stream; the offerer may provide multiple choices for the
parameters, or the cryptographic parameters selected by the answerer cryptographic parameters, or the cryptographic parameters selected
may differ from those of the offerer (e.g. the key used in one by the answerer may differ from those of the offerer (e.g. the key
direction versus the other). In such cases, to avoid media used in one direction versus the other). In such cases, to avoid
clipping, the offerer needs to receive the answer prior to receiving media clipping, the offerer needs to receive the answer prior to
any media packets from the answerer. This can be achieved by using receiving any media packets from the answerer. This can be achieved
a security precondition, which ensures the successful negotiation of by using a security precondition, which ensures the successful
media stream security parameters for a secure media stream prior to negotiation of media stream security parameters for a secure media
session establishment or modification. stream prior to session establishment or modification.
3 Security Precondition Definition 3 Security Precondition Definition
The semantics for a security precondition are that the relevant The semantics for a security precondition are that the relevant
cryptographic parameters (cipher, key, etc.) for a secure media cryptographic parameters (cipher, key, etc.) for a secure media
stream are known to have been negotiated in the direction(s) stream are known to have been negotiated in the direction(s)
required. If the security precondition is used with a non-secure required. If the security precondition is used with a non-secure
media stream, the security precondition is by definition satisfied. media stream, the security precondition is by definition satisfied.
A secure media stream is here defined as a media stream that uses A secure media stream is here defined as a media stream that uses
some kind of security service, e.g. message integrity, some kind of security service, e.g. message integrity,
confidentiality or both, regardless of the cryptographic strength of confidentiality or both, regardless of the cryptographic strength of
the mechanisms being used. the mechanisms being used.
As an extreme example of this, Secure RTP (SRTP) using the NULL As an extreme example of this, Secure RTP (SRTP) using the NULL
encryption algorithm and no message integrity would be considered encryption algorithm and no message integrity would be considered
a secure media stream whereas use of plain RTP would not. Note a secure media stream whereas use of plain RTP would not. Note
though, that use of SRTP without authentication is discouraged. though, that section 9.5 of [SRTP] discourages the use of SRTP
without message integrity.
Security preconditions do not guarantee that an established media Security preconditions do not guarantee that an established media
stream will be secure. They merely guarantee that the recipient of stream will be secure. They merely guarantee that the recipient of
the media stream packets will be able to perform any relevant the media stream packets will be able to perform any relevant
decryption and integrity checking on those media stream packets. decryption and integrity checking on those media stream packets.
Please refer to Section 5 for further security considerations. Please refer to Section 5 for further security considerations.
The security precondition type is defined by the string "sec" and The security precondition type is defined by the string "sec" and
hence we modify the grammar found in RFC 3312 as follows: hence we modify the grammar found in RFC 3312 as follows:
skipping to change at page 6, line 14 skipping to change at page 6, line 16
offer/answer exchange and avoids forwarding the information to the offer/answer exchange and avoids forwarding the information to the
security layer for further processing. security layer for further processing.
Offers with security preconditions in re-INVITEs or UPDATEs follow Offers with security preconditions in re-INVITEs or UPDATEs follow
the rules given in Section 6 of RFC 3312, i.e.: the rules given in Section 6 of RFC 3312, i.e.:
"Both user agents SHOULD continue using the old session parameters "Both user agents SHOULD continue using the old session parameters
until all the mandatory preconditions are met. At that moment, until all the mandatory preconditions are met. At that moment,
the user agents can begin using the new session parameters." the user agents can begin using the new session parameters."
At that moment, we furthermore require that ser agents MUST start
using the new session parameters for media packets being sent. The
user agents SHOULD be prepared to process media packets received
with either the old or the new session parameters for a short period
of time to accommodate media packets in transit. Note that this may
involve iterative security processing of the received media packets
during that period of time. Section 8 in [OFFANS] lists several
techniques to help alleviate the problem of determining when a
received media packet was generated according to the old or new
offer/answer exchange.
4 Examples 4 Examples
4.1 SDP Security Descriptions Example 4.1 SDP Security Descriptions Example
The call flow of Figure 1 shows a basic session establishment using The call flow of Figure 1 shows a basic session establishment using
the Session Initiation Protocol [SIP] and SDP security descriptions the Session Initiation Protocol [SIP] and SDP security descriptions
[SDESC] with security descriptions for the secure media stream (SRTP [SDESC] with security descriptions for the secure media stream (SRTP
in this case). in this case).
A B A B
skipping to change at page 7, line 19 skipping to change at page 7, line 30
and the resulting offer SDP is: and the resulting offer SDP is:
m=audio 20000 RTP/SAVP 0 m=audio 20000 RTP/SAVP 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=curr:sec e2e none a=curr:sec e2e none
a=des:sec mandatory e2e sendrecv a=des:sec mandatory e2e sendrecv
a=crypto:foo... a=crypto:foo...
SDP2: When B receives the offer and generates an answer, B knows the SDP2: When B receives the offer and generates an answer, B knows the
(send and recv) security parameters of both A and B. However, A (send and recv) security parameters of both A and B. From a
does not know B's security parameters, so the current status of B's security perspective, B is now able to receive media from A, so B's
"send" security precondition (which equal A's "recv" security "recv" security precondition is "yes". However, A does not know any
precondition) is "no". Similarly, A does not know any of B's SDP of B's SDP information, so B's "send" security precondition is "no".
information, so B's "send" security precondition is also "no". B's B's local status table therefore looks as follows:
local status table therefore looks as follows:
Direction | Current | Desired Strength | Confirm Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+---------- -----------+----------+------------------+----------
send | no | mandatory | no send | no | mandatory | no
recv | no | mandatory | no recv | yes | mandatory | no
B requests A to confirm when A knows the security parameters used in B requests A to confirm when A knows the security parameters used in
the send and receive direction and hence the resulting answer SDP the send and receive direction (it would suffice for B to ask for
becomes: confirmation of A's send direction only) and hence the resulting
answer SDP becomes:
m=audio 30000 RTP/SAVP 0 m=audio 30000 RTP/SAVP 0
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
a=curr:sec e2e none a=curr:sec e2e recv
a=des:sec mandatory e2e sendrecv a=des:sec mandatory e2e sendrecv
a=conf:sec e2e sendrecv a=conf:sec e2e sendrecv
a=crypto:bar... a=crypto:bar...
SDP3: When A receives the answer, A updates its local status table SDP3: When A receives the answer, A updates its local status table
based on the rules in RFC 3312. A knows the security parameters of based on the rules in RFC 3312. A knows the security parameters of
both the send and receive direction and hence A's local status table both the send and receive direction and hence A's local status table
is updated as follows: is updated as follows:
Direction | Current | Desired Strength | Confirm Direction | Current | Desired Strength | Confirm
skipping to change at page 8, line 15 skipping to change at page 8, line 28
satisfied: satisfied:
m=audio 20000 RTP/SAVP 0 m=audio 20000 RTP/SAVP 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=curr:sec e2e sendrecv a=curr:sec e2e sendrecv
a=des:sec mandatory e2e sendrecv a=des:sec mandatory e2e sendrecv
a=crypto:foo... a=crypto:foo...
Note that we here use PRACK [RFC3262] instead of UPDATE [RFC3311] Note that we here use PRACK [RFC3262] instead of UPDATE [RFC3311]
since the precondition is satisfied immediately, and the original since the precondition is satisfied immediately, and the original
offer/answer exchange is complete) offer/answer exchange is complete.
SDP4: Upon receiving the updated offer, B updates its local status SDP4: Upon receiving the updated offer, B updates its local status
table based on the rules in RFC 3312 which yields the following: table based on the rules in RFC 3312 which yields the following:
Direction | Current | Desired Strength | Confirm Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+---------- -----------+----------+------------------+----------
send | yes | mandatory | no send | yes | mandatory | no
recv | yes | mandatory | no recv | yes | mandatory | no
B responds with an answer (4) which contains the current status of B responds with an answer (4) which contains the current status of
skipping to change at page 9, line 45 skipping to change at page 10, line 9
m=audio 20000 RTP/SAVP 0 m=audio 20000 RTP/SAVP 0
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=curr:sec e2e none a=curr:sec e2e none
a=des:sec mandatory e2e sendrecv a=des:sec mandatory e2e sendrecv
a=key-mgmt:mikey AQAFgM0X... a=key-mgmt:mikey AQAFgM0X...
SDP2: When B receives the offer and generates an answer, B knows the SDP2: When B receives the offer and generates an answer, B knows the
(send and recv) security parameters of both A and B. B generates (send and recv) security parameters of both A and B. B generates
keying material for sending media to A, however, A does not know B's keying material for sending media to A, however, A does not know B's
keying material, so the current status of B's "send" security keying material, so the current status of B's "send" security
precondition (which equal A's "recv" security precondition) is "no". precondition is "no". B does know A's SDP information, so B's
Similarly, A does not know any of B's SDP information, so B's "recv" "recv" security precondition is "yes". B's local status table
security precondition is also "no". B's local status table
therefore looks as follows: therefore looks as follows:
Direction | Current | Desired Strength | Confirm Direction | Current | Desired Strength | Confirm
-----------+----------+------------------+---------- -----------+----------+------------------+----------
send | no | mandatory | no send | no | mandatory | no
recv | no | mandatory | no recv | yes | mandatory | no
B requests A to confirm when A knows the security parameters used in B requests A to confirm when A knows the security parameters used in
the send and receive direction and hence the resulting answer SDP the send and receive direction and hence the resulting answer SDP
becomes: becomes:
m=audio 30000 RTP/SAVP 0 m=audio 30000 RTP/SAVP 0
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
a=curr:sec e2e none a=curr:sec e2e recv
a=des:sec mandatory e2e sendrecv a=des:sec mandatory e2e sendrecv
a=conf:sec e2e sendrecv a=conf:sec e2e sendrecv
a=key-mgmt:mikey AQAFgM0X... a=key-mgmt:mikey AQAFgM0X...
Note that the actual MIKEY data in the answer differs from that in Note that the actual MIKEY data in the answer differs from that in
the offer, however we have only shown the initial and common part of the offer, however we have only shown the initial and common part of
the MIKEY value in the above. the MIKEY value in the above.
SDP3: When A receives the answer, A updates its local status table SDP3: When A receives the answer, A updates its local status table
based on the rules in RFC 3312. A now knows all the security based on the rules in RFC 3312. A now knows all the security
skipping to change at page 12, line 17 skipping to change at page 12, line 31
that an established media stream will be secure. They merely that an established media stream will be secure. They merely
guarantee that the recipient of the media stream packets will be guarantee that the recipient of the media stream packets will be
able to perform any relevant decryption and integrity checking on able to perform any relevant decryption and integrity checking on
those media stream packets. If an offer includes a secure and a those media stream packets. If an offer includes a secure and a
non-secure media stream as alternatives, this may lead to additional non-secure media stream as alternatives, this may lead to additional
security issues. It is important to understand how security security issues. It is important to understand how security
preconditions interact with those. preconditions interact with those.
SDP and the offer/answer model currently do not define how such SDP and the offer/answer model currently do not define how such
alternatives could be negotiated, however there is work in alternatives could be negotiated, however there is work in
progress to address that (see e.g. [SDPCN]). Below, we provide progress to address that (see e.g. [SDPCN]). Negotiating secure
general security considerations for security preconditions with and non-secure media streams as alternatives however introduces
such mechanisms. several security issues and hence SHOULD NOT be done until a
complete specification for doing so has been documented in detail
If the offer were to include secure and non-secure media streams as and reviewed properly. Below, we provide general security
alternative offers, and media for either alternative may be received considerations for security preconditions that may aid in the
prior to the answer, then the offerer may not know if the answerer design and review of such mechanisms.
accepted the secure alternative. An active attacker thus may be
able to inject malicious media stream packets until the answer is
received. Use of security preconditions would not address this
vulnerability since security preconditions do not guarantee that a
media stream established is secure, even if the strength-tag is
"mandatory".
In the above scenario with secure and non-secure media streams as Note that a basic premise of negotiating secure and non-secure media
alternatives, the offerer may also be concerned about a passive streams as alternatives is that the offerer's security policy allows
attacker performing eavesdropping on the media stream. Security for non-secure media. If the offer were to include secure and non-
preconditions can help here by ensuring that clipping will not occur secure media streams as alternative offers, and media for either
if the answerer supports the secure media stream and furthermore alternative may be received prior to the answer, then the offerer
accepts it. Still, they would not guarantee that the media stream may not know if the answerer accepted the secure alternative. An
established is secure and hence by themselves would not protect active attacker thus may be able to inject malicious media stream
against eavesdropping. packets until the answer (indicating the chosen secure alternative)
is received. Use of security preconditions (even with a mandatory
strength-tag) would not address this vulnerability since security
preconditions would apply only to the secure media stream
alternatives.
6 IANA Considerations 6 IANA Considerations
IANA is hereby requested to register a RFC 3312 precondition type IANA is hereby requested to register a RFC 3312 precondition type
called "sec" with the name "Security precondition". The reference called "sec" with the name "Security precondition". The reference
for this precondition type is the current document. for this precondition type is the current document.
7 Acknowledgements 7 Acknowledgements
The security precondition was defined in earlier draft versions of The security precondition was defined in earlier draft versions of
RFC 3312. RFC 3312 contains an extensive list of people who worked RFC 3312. RFC 3312 contains an extensive list of people who worked
on those earlier draft versions which are acknowledged here as well. on those earlier draft versions which are acknowledged here as well.
The authors would additionally like to thank Mark Baugher, Gonzalo The authors would additionally like to thank David Black, Mark
Camarillo, Paul Kyzivat and Thomas Stach for their comments on this Baugher, Gonzalo Camarillo, Paul Kyzivat and Thomas Stach for their
document. comments on this document.
8 Authors' Addresses 8 Authors' Addresses
Flemming Andreasen Flemming Andreasen
Cisco Systems, Inc. Cisco Systems, Inc.
499 Thornall Street, 8th Floor 499 Thornall Street, 8th Floor
Edison, New Jersey 08837 USA Edison, New Jersey 08837 USA
EMail: fandreas@cisco.com EMail: fandreas@cisco.com
Dan Wing Dan Wing
skipping to change at page 13, line 40 skipping to change at page 14, line 4
2005. 2005.
[RFC2327] M. Handley and V. Jacobson, "SDP: Session Description [RFC2327] M. Handley and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[SIP] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [SIP] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session
Initiation Protocol", RFC 3261, June 2002. Initiation Protocol", RFC 3261, June 2002.
10 Informative References 10 Informative References
[SDESC] F. Andreasen, M. Baugher, and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Streams",
RFC 4568, July 2006.
[SDESC] F. Andreasen, M. Baugher, and D. Wing, "SDP Security [OFFANS] J. Rosenberg, and H. Schulzrinne, "An Offer/Answer Model
Descriptions for Media Streams", work in progress with the Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3551] H. Schulzrinne, and S. Casner "RTP Profile for Audio and [RFC3551] H. Schulzrinne, and S. Casner "RTP Profile for Audio and
Video Conferences with Minimal Control", RFC 3550, July 2003. Video Conferences with Minimal Control", RFC 3550, July 2003.
[SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K.
Norrman, "The Secure Real-time Transport Protocol", RFC 3711, March Norrman, "The Secure Real-time Transport Protocol", RFC 3711, March
2004. 2004.
[ICE] J. Rosenberg, "Interactive Connectivity Establishment [ICE] J. Rosenberg, "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT) Traversal (ICE): A Methodology for Network Address Translator (NAT) Traversal
 End of changes. 20 change blocks. 
60 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/