Internet Engineering Task Force P. Dawes
Internet-Draft Vodafone Group
Intended status: Standards Track February 17, 2010
Expires: August 21, 2010
Header Field Parameter for Media Plane Security
draft-dawes-dispatch-mediasec-parameter-00.txt
Abstract
Negotiating the security mechanisms used between a Session Initiation
Protocol (SIP) user agent and its next-hop SIP entity is already
described in an RFC. This document extends negotiation of a security
mechanism to the media plane by defining a new Session Initiation
Protocol (SIP) header field parameter to label security mechanisms
that apply to the media plane.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2010.
Copyright Notice
Dawes Expires August 21, 2010 [Page 1]
Internet-Draft Media Security Parameter February 2010
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Relationship to RFC3329 . . . . . . . . . . . . . . . . . 4
2.2. Overview of Operation . . . . . . . . . . . . . . . . . . 4
2.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Protocol Operation . . . . . . . . . . . . . . . . . . . . 5
2.4.1. The "mediasec" Header Field Parameter . . . . . . . . 5
2.4.2. Client Initiated . . . . . . . . . . . . . . . . . . . 6
2.4.3. Server Initiated . . . . . . . . . . . . . . . . . . . 6
2.5. Security Mechanism Initiation . . . . . . . . . . . . . . 6
2.6. Duration of Security Assocations . . . . . . . . . . . . . 6
2.7. Summary of Header Field Use . . . . . . . . . . . . . . . 6
3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Client Initiated . . . . . . . . . . . . . . . . . . . . . 6
4.2. Server Initiated . . . . . . . . . . . . . . . . . . . . . 8
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. Registration Information . . . . . . . . . . . . . . . . . 9
7.2. Registration Template . . . . . . . . . . . . . . . . . . 9
7.3. Header Field Names . . . . . . . . . . . . . . . . . . . . 9
7.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 10
7.5. Option Tags . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Additional stuff . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Dawes Expires August 21, 2010 [Page 2]
Internet-Draft Media Security Parameter February 2010
1. Introduction
RFC 3329 [1] describes negotiation of a security mechanism for SIP
signalling between a UAC and its first hop proxy. This document
extends the concept of security negotiation by added exchange of
security capability for the media plane. Similar to the signalling
plane, the evolution of security mechanisms for media often
introduces new algorithms, or uncovers problems in existing ones,
making negotiation of mechanisms a necessity.
The purpose of this specification is to define negotiation
functionality for the Session Initiation Protocol (SIP) [1]. This
negotiation is intended to work only between a UA and its first-hop
SIP entity.
1.1. Motivations
RFC3329 describes why security is needed to protect SIP signalling
from man-in-the-middle attacks, and to accomodate the expected wide
variation in security mechanism support by SIP entities. The media
plane requires similar protection and capability, for example to
prevent eavesdropping in environments such as public wireless access
networks that have no inherent security.
1.2. Design Goals
Security on the media plane differs from security for signalling,
because it is applied per media stream and also because multiple
media streams can be started and stopped within a single SIP session.
For a single media stream, any one of the media plane security
mechanisms supported by client and server may be applied, or no media
plane security may be applied at all. Therefore, this specification
defines secure capability exchange and use of security mechanisms for
media, but with no obligation to use the indicated security
mechanisms.
1. The entities involved in the security agreement process need to
find out exactly which security mechanisms to apply, preferably
without excessive additional roundtrips.
2. The selection of security mechanisms itself needs to be secure.
Traditionally, all security protocols use a secure form of
negotiation. For instance, after establishing mutual keys
through Diffie-Hellman, IKE sends hashes of the previously sent
data including the offered crypto mechanisms [8]. This allows
the peers to detect if the initial, unprotected offers were
tampered with.
Dawes Expires August 21, 2010 [Page 3]
Internet-Draft Media Security Parameter February 2010
3. The security agreement process should not introduce any
additional state to be maintained by the involved entities.
2. Solution
This document defines the "mediasec" header field parameter that
labels any of the Security-Client:, Security-Server:, or Security-
Verify: header fields as applicable to the media plane and not the
signalling plane. Any one of the mechanisms labelled with the
"mediasec" header field parameter can be applied on-the-fly as a
media stream is started, unlike mechanisms for signalling one of
which is chosen and then applied throughout a session.
2.1. Relationship to RFC3329
As stated earlier, RFC 3329 [1] defines security mechanism agreement
for signalling, including the "sec-agree" option tag that can appear
in Supported:, Require:, and Proxy-Require: header fields. The
"mediasec" header field parameter defined in this document places no
requirements to support any function in RFC 3329 [1]. In other
words, media plane security can be supported without implementing any
of RFC 3329 [1], it is only the header field names that are re-used.
A user agent or proxy that does not implement RFC 3329 [1] or this
document and receives the Security-Client;, Security-Server; and
Security-Verfiy; header fields containing only media plane security
mechanisms, labelled with the "mediasec" header field parameter, will
ignore them as unknown, and will not include these header fields in
its response, thereby informing the entity that sent them that this
document is not supported. This document adds 200 (OK) to the SIP
responses that can contain the Security-Client, Security-Server, and
Security-Verfiy header fields; RFC 3329 [1] allows Security-Server
only in SIP responses 421 (Extension Required) and 494 (Security
Agreement Required).
2.2. Overview of Operation
The message flow is identical to the flow in RFC 3329 [1], with the
exceptions that it is not mandatory for the user agent to apply media
plane security immediately after it receives the list of supported
media plane mechanisms from the server, or any timer after that, nor
will the lack of a mutually supported media plane security mechanism
prevent SIP session setup. In the message flow below, only Step 3
differs from RFC 3329 [1].
Dawes Expires August 21, 2010 [Page 4]
Internet-Draft Media Security Parameter February 2010
1. Client ---------------client list-------------> Server
2. Client <--------------server list-------------- Server
3. Client --(optional to turn on media security)-- Server
4. Client ---------------server list-------------> Server
5. Client <--------------ok or error-------------- Server
Figure 1: Security capability Exchange message flow
Step 1: Clients wishing to use this specification can send a list of
their supported security mechanisms along the first request to the
server.
Step 2: Servers wishing to use this specification can challenge the
client to perform the security agreement procedure. The security
mechanisms and parameters supported by the server are sent along in
this challenge.
Step 3: The client may then proceed to select any media security
mechanism they have in common and to turn on the selected security.
Step 4: The client contacts the server again, now using the selected
security mechanism. The server's list of supported security
mechanisms is returned as a response to the challenge.
Step 5: The server verifies its own list of security mechanisms in
order to ensure that the original list had not been modified.
2.3. Syntax
tbd.
2.4. Protocol Operation
2.4.1. The "mediasec" Header Field Parameter
The "mediasec" header field parameter may be used in the Security-
Client;, Security-Server; or Security-Verfiy; header fields defined
in RFC 3329 [1] to indicate that a header field applies to the media
plane. Any one of the media plane security mechanisms supported by
both client and server, if any, may be applied when a media stream is
started. Or, a media stream may be set up without security.
The value of the "mediasec" header field parameter will be specific
to the security mechanism applied and the secure media transport
protocol. This document defines the following value:
Dawes Expires August 21, 2010 [Page 5]
Internet-Draft Media Security Parameter February 2010
o sdes-srtp: SDES security mechanism for SRTP applied end to access
edge
2.4.2. Client Initiated
tbd.
2.4.3. Server Initiated
tbd.
2.5. Security Mechanism Initiation
tbd.
2.6. Duration of Security Assocations
tbd.
2.7. Summary of Header Field Use
tbd.
3. Backwards Compatibility
Security mechanisms that apply to the media plane only MUST NOT have
the same name as any signalling plane mechanism. If a signalling
plane security mechanism name is re-used for the media plane and
distinguished only by the "mediasec" parameter, then implementations
that do not understand the "mediasec" parameter may incorrectly use
that security mechanism for the signalling plane.
4. Examples
tbd.
4.1. Client Initiated
As per RFC 3329 [1], a UA negotiates the security mechanism for
signalling to be used with its outbound proxy without knowing
beforehand which mechanisms the proxy supports as shown below.
Dawes Expires August 21, 2010 [Page 6]
Internet-Draft Media Security Parameter February 2010
UAC Proxy UAS
| | |
|----(1) OPTIONS---->| |
| | |
|<-----(2) 494 ------| |
| | |
|<====== TLS =======>| |
| | |
|----(3) INVITE----->| |
| |----(4) INVITE--->|
| | |
| |<---(5) 200 OK----|
|<---(6) 200 OK------| |
| | |
|------(7) ACK------>| |
| |-----(8) ACK----->|
| | |
| | |
| | |
| | |
Figure 2: Negotiation Initiated by the Client
Indication of media security mechanisms is added and identified by
the "mediasec" header field parameter. Media security mechanisms are
returned by the client to the server in the Security-Verify: header
field in the same way as for signalling security mechanisms.
Dawes Expires August 21, 2010 [Page 7]
Internet-Draft Media Security Parameter February 2010
(1) OPTIONS sip:proxy.example.com SIP/2.0
Security-Client: tls
Security-Client: sdes-srtp;mediasec
Require: sec-agree
Proxy-Require: sec-agree
(2) SIP/2.0 494 Security Agreeement Required
Security-Server: ipsec-ike;q=0.1
Security-Server: tls;q=0.2
Security-Server: sdes-srtp;mediasec
(3) INVITE sip:proxy.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2
Security-Verify: sdes-srtp;mediasec
Security-Client: tls
Security-Client: sdes-srtp;mediasec
Route: sip:callee@domain.com
Require: sec-agree
Proxy-Require: sec-agree
(4) INVITE sip:proxy.example.com SIP/2.0
Route: sip:callee@domain.com
(5) SIP/2.0 200 OK
(6) SIP/2.0 200 OK
Security-Server: tls;q=0.2
Security-Server: sdes-srtp;mediasec
Figure 3: Use of mediasec parameter
4.2. Server Initiated
tbd.
5. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC 5234 [RFC5234].
The "reg-type" URI parameter is a "header field parameter", as
defined by [RFC3968].
Header Field Name in which the parameter can appear.
Dawes Expires August 21, 2010 [Page 8]
Internet-Draft Media Security Parameter February 2010
Security-Client
Security-Server
Security-Verify
Header Fields Parameter Name Values Reference
--------------- ---------------- -------- ---------
Security-Client mediasec No [this document]
Security-Server
Security-Verify
Name of the Header Field Parameter being registered.
"mediasec"
6. Acknowledgements
Remember, it's important to acknowledge people who have contributed
to the work.
This template was extended from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.
7. IANA Considerations
The "mediasec" parameter and any new security mechanisms for the
media plane must be IANA registered.
7.1. Registration Information
tbd.
7.2. Registration Template
tbd.
7.3. Header Field Names
tbd.
Dawes Expires August 21, 2010 [Page 9]
Internet-Draft Media Security Parameter February 2010
7.4. Response Codes
tbd.
7.5. Option Tags
None?
8. Security Considerations
Remember to consider security from the start.. and all drafts are
required to have a security considerations section before they will
pass the IESG.
9. References
9.1. Normative References
[1] authSurName, authInitials., "RFC3329", year.
[2] authSurName, authInitials., "RFC2661", year.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997,
<http://xml.resource.org/public/rfc/html/rfc2119.html>.
[4] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
9.2. Informative References
[5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Appendix A. Additional stuff
You can add appendices just as regular sections, the only difference
is that they go within the "back" element, and not within the
"middle" element. And they follow the "reference" elements.
Dawes Expires August 21, 2010 [Page 10]
Internet-Draft Media Security Parameter February 2010
Author's Address
Peter Dawes
Vodafone Group Services Ltd.
Newbury
UK
Email: peter.dawes@vodafone.com
Dawes Expires August 21, 2010 [Page 11]