< draft-ietf-sipbrandy-rtpsec-00.txt   draft-ietf-sipbrandy-rtpsec-01.txt >
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Best Current Practice E. Rescorla Intended status: Best Current Practice E. Rescorla
Expires: March 13, 2017 R. Barnes Expires: May 4, 2017 R. Barnes
Mozilla Mozilla
R. Housley R. Housley
Vigilsec Vigilsec
September 9, 2016 October 31, 2016
Best Practices for Securing RTP Media Signaled with SIP Best Practices for Securing RTP Media Signaled with SIP
draft-ietf-sipbrandy-rtpsec-00.txt draft-ietf-sipbrandy-rtpsec-01.txt
Abstract Abstract
Although the Session Initiation Protocol (SIP) includes a suite of Although the Session Initiation Protocol (SIP) includes a suite of
security services that has been expanded by numerous specifications security services that has been expanded by numerous specifications
over the years, there is no single place that explains how to use SIP over the years, there is no single place that explains how to use SIP
to establish confidential media sessions. Additionally, existing to establish confidential media sessions. Additionally, existing
mechanisms have some feature gaps that need to be identified and mechanisms have some feature gaps that need to be identified and
resolved in order for them to address the pervasive monitoring threat resolved in order for them to address the pervasive monitoring threat
model. This specification describes best practices for negotiating model. This specification describes best practices for negotiating
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 13, 2017. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3 3. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3
3.1. Comprehensive Protection . . . . . . . . . . . . . . . . 3 3.1. Comprehensive Protection . . . . . . . . . . . . . . . . 3
3.2. Opportunistic Security . . . . . . . . . . . . . . . . . 4 3.2. Opportunistic Security . . . . . . . . . . . . . . . . . 4
4. STIR Profile for Endpoint Authentication and Verification 4. STIR Profile for Endpoint Authentication and Verification
Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6 4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6
4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 6 4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 6
5. Media Security Protocols . . . . . . . . . . . . . . . . . . 7 4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 7
6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 7 4.4.1. Opportunistic STIR . . . . . . . . . . . . . . . . . 7
7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 8 5. Media Security Protocols . . . . . . . . . . . . . . . . . . 8
8. Best Current Practices . . . . . . . . . . . . . . . . . . . 8 6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 8
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Best Current Practices . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12. Informative References . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] includes a suite of The Session Initiation Protocol (SIP) [RFC3261] includes a suite of
security services, ranging from Digest authentication for security services, ranging from Digest authentication for
authenticating entities with a shared secret, to TLS for transport authenticating entities with a shared secret, to TLS for transport
security, to S/MIME (optional) for body security. SIP is frequently security, to S/MIME (optionally) for body security. SIP is
used to establish media sessions, in particular audio or audiovisual frequently used to establish media sessions, in particular audio or
sessions, which have their own security mechanisms available, such as audiovisual sessions, which have their own security mechanisms
Secure RTP [RFC3711]. However, the practices needed to bind security available, such as Secure RTP [RFC3711]. However, the practices
at the media layer to security at the SIP layer, to provide an needed to bind security at the media layer to security at the SIP
assurance that protection is in place all the way up the stack, rely layer, to provide an assurance that protection is in place all the
on a great many external security mechanisms and practices, and way up the stack, rely on a great many external security mechanisms
require a central point of documentation to explain their optimal use and practices, and require a central point of documentation to
as a best practice. explain their optimal use as a best practice.
Revelations about widespread pervasive monitoring of the Internet Revelations about widespread pervasive monitoring of the Internet
have led to a reevaluation of the threat model for Internet have led to a reevaluation of the threat model for Internet
communications [RFC7258]. In order to maximize the use of security communications [RFC7258]. In order to maximize the use of security
features, especially of media confidentiality, opportunistic measures features, especially of media confidentiality, opportunistic measures
must often serve as a stopgap when a full suite of services cannot be must often serve as a stopgap when a full suite of services cannot be
negotiated all the way up the stack. This document explains the negotiated all the way up the stack. This document explains the
limitations that may inhibit the use of comprehensive protection, and limitations that may inhibit the use of comprehensive protection, and
provides recommendations for which external security mechanisms provides recommendations for which external security mechanisms
implementers should use to negotiate secure media with SIP. It implementers should use to negotiate secure media with SIP. It
skipping to change at page 3, line 40 skipping to change at page 3, line 40
There are two approaches to providing confidentiality for media There are two approaches to providing confidentiality for media
sessions set up with SIP: comprehensive protection and opportunistic sessions set up with SIP: comprehensive protection and opportunistic
security (as defined in [RFC7435]). security (as defined in [RFC7435]).
3.1. Comprehensive Protection 3.1. Comprehensive Protection
Comprehensive protection for media sessions established by SIP Comprehensive protection for media sessions established by SIP
requires the interaction of three protocols: SIP, the Session requires the interaction of three protocols: SIP, the Session
Description Protocol (SDP), and the Real-time Protocol, in particular Description Protocol (SDP), and the Real-time Protocol, in particular
its secure profile SRTP. Broadly, it is the responsibility of SIP to its secure profile SRTP. Broadly, it is the responsibility of SIP to
provide integrity for the media keying attributes conveyed by SDP, provide integrity protection for the media keying attributes conveyed
and those attributes will in turn identify the keys used by endpoints by SDP, and those attributes will in turn identify the keys used by
in the RTP media session that SDP negotiates. In that way, once SIP endpoints in the RTP media session(s) that SDP negotiates. In that
and SDP have exchanged the necessary information to initiate a way, once SIP and SDP have exchanged the necessary information to
session, the media endpoints will have a strong assurance that the initiate a session, media endpoints will have a strong assurance that
keys they exchange have not been tampered with by third parties, and the keys they exchange have not been tampered with by third parties,
that end-to-end confidentiality is available. and that end-to-end confidentiality is available.
Our current target mechanism for establishing the identity of the Our current target mechanism for establishing the identity of the
endpoints of a SIP session is the use of STIR endpoints of a SIP session is the use of STIR
[I-D.ietf-stir-rfc4474bis]. The STIR signature has been designed to [I-D.ietf-stir-rfc4474bis]. The STIR Identity header has been
prevent a class of impersonation attacks that are commonly used in designed to prevent a class of impersonation attacks that are
robocalling, voicemail hacking, and related threats. STIR generates commonly used in robocalling, voicemail hacking, and related threats.
a signature over certain features of SIP requests, including header
field values that contain an identity for the originator of the STIR generates a signature over certain features of SIP requests,
request, such as the From header field or P-Asserted-Identity field, including header field values that contain an identity for the
and also over the media keys in SDP if they are present. As originator of the request, such as the From header field or P-
currently defined, STIR only provides a signature over the Asserted-Identity field, and also over the media keys in SDP if they
"a=fingerprint" attribute, which is a key fingerprint utilized by are present. As currently defined, STIR only provides a signature
DTLS-SRTP [RFC5763]; consequently, STIR only offers comprehensive over the "a=fingerprint" attribute, which is a key fingerprint
protection for SIP sessions, in concert with SDP and SRTP, when DTLS- utilized by DTLS-SRTP [RFC5763]; consequently, STIR only offers
SRTP is the media security service. The underlying security object comprehensive protection for SIP sessions, in concert with SDP and
of STIR is extensible, however, and it would be possible to provide SRTP, when DTLS-SRTP is the media security service. The underlying
signatures over other SDP attributes that contain alternate keying PASSporT [I-D.ietf-stir-passport] object used by STIR is extensible,
material. A profile for using STIR to provide media confidentiality however, and it would be possible to provide signatures over other
is given in Section 4. SDP attributes that contain alternate keying material. A profile for
using STIR to provide media confidentiality is given in Section 4.
3.2. Opportunistic Security 3.2. Opportunistic Security
Work is already underway on defining approaches to opportunistic Work is already underway on defining approaches to opportunistic
media security for SIP in [I-D.johnston-dispatch-osrtp], which builds media security for SIP in [I-D.johnston-dispatch-osrtp], which builds
on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. The on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. The
major protocol change proposed by that draft is to signal the use of major protocol change proposed by that draft is to signal the use of
opportunistic encryption by negotiating the AVP profile in SDP, opportunistic encryption by negotiating the AVP profile in SDP,
rather than the SAVP profile (as specified in [RFC3711]) that would rather than the SAVP profile (as specified in [RFC3711]) that would
ordinarily be used when negotiating SRTP. ordinarily be used when negotiating SRTP.
skipping to change at page 4, line 38 skipping to change at page 4, line 39
Opportunistic encryption approaches typically have no integrity Opportunistic encryption approaches typically have no integrity
protection for the keying material in SDP. Sending SIP over TLS hop- protection for the keying material in SDP. Sending SIP over TLS hop-
by-hop between user agents and any intermediaries will reduce the by-hop between user agents and any intermediaries will reduce the
prospect that active attackers can alter keys for session requests on prospect that active attackers can alter keys for session requests on
the wire. However, opportunistic confidentiality for media will the wire. However, opportunistic confidentiality for media will
prevent passive attacks of the form most common in the threat of prevent passive attacks of the form most common in the threat of
pervasive monitoring. pervasive monitoring.
4. STIR Profile for Endpoint Authentication and Verification Services 4. STIR Profile for Endpoint Authentication and Verification Services
A STIR [I-D.ietf-stir-rfc4474bis] verification service can act in STIR [I-D.ietf-stir-rfc4474bis] defines the Identity header field for
concert with an SRTP media endpoint to ensure that the key SIP, which provides a cryptographic attestation of the source of
fingerprints, as given in SDP, match the keys exchanged to establish communications. This profile assumes that a STIR verification
DTLS-SRTP. Typically, the verification service function would in service will act in concert with an SRTP media endpoint to ensure
this case be implemented in the SIP UAS, which would be composed with that the key fingerprints, as given in SDP, match the keys exchanged
the media endpoint. If the STIR authentication service or to establish DTLS-SRTP. To satisfy this condition, the verification
verification service functions are implemented at an intermediary service function would in this case be implemented in the SIP UAS,
rather than an endpoint, this introduces the possibility that the which would be composed with the media endpoint. If the STIR
intermediary could act as a man-in-the-middle, altering key authentication service or verification service functions are
fingerprints. As this attack is not in STIR's core threat model, implemented at an intermediary rather than an endpoint, this
which focuses on impersonation rather than man-in-the-middle attacks, introduces the possibility that the intermediary could act as a man
STIR offers no specific protections against it. However, it would be in the middle, altering key fingerprints. As this attack is not in
possible to build a deployment profile of STIR for media STIR's core threat model, which focuses on impersonation rather than
confidentiality which shifts these responsibilities to the endpoints man-in-the-middle attacks, STIR offers no specific protections
rather than the intermediaries. against such interference. The SIPBRANDY deployment profile of STIR
for media confidentiality thus shifts these responsibilities to the
endpoints rather than the intermediaries.
In order to be compliant with best practices for SIP media In order to be compliant with best practices for SIP media
confidentiality with comprehensive protection, user agent confidentiality with comprehensive protection, user agent
implementations MUST implement both the authentication service and implementations MUST implement both the authentication service and
verification service roles described in [I-D.ietf-stir-rfc4474bis]. verification service roles described in [I-D.ietf-stir-rfc4474bis].
STIR authentication services MUST signal their compliance with this
specification by adding the "msec" header element defined in this
specification to the PASSporT header. Implementations MUST provide
key fingerprints in SDP and the appropriate signatures over them per
[I-D.ietf-stir-passport].
When generating either an offer or an answer, compliant When generating either an offer or an answer, compliant
implementations MUST include an "a=fingerprint" attribute containing implementations MUST include an "a=fingerprint" attribute containing
the fingerprint of an appropriate key (see Section 4.1). the fingerprint of an appropriate key (see Section 4.1).
4.1. Credentials 4.1. Credentials
In order to implement the authentication service function, SIP In order to implement the authentication service function in the user
endpoints must acquire the credentials needed to sign for their own agent, SIP endpoints must acquire the credentials needed to sign for
identity. That identity is typically carried in the From header their own identity. That identity is typically carried in the From
field of a SIP request, and either contains a greenfield SIP URI header field of a SIP request, and either contains a greenfield SIP
(e.g. "sip:alice@example.com") or a telephone number, which can URI (e.g. "sip:alice@example.com") or a telephone number, which can
appear in a variety of ways (e.g. "sip:+17004561212@example.com). appear in a variety of ways (e.g.
[I-D.ietf-stir-rfc4474bis] Section 7 contains guidance for separating "sip:+17004561212@example.com;user=phone").
[I-D.ietf-stir-rfc4474bis] Section 8 contains guidance for separating
the two, and determining what sort of credential is needed to sign the two, and determining what sort of credential is needed to sign
for each. for each.
To date, few commercial certificate authorities issue certificates To date, few commercial certificate authorities issue certificates
for SIP URIs or telephone numbers. This is one reason why the STIR for SIP URIs or telephone numbers; though work is ongoing on systems
standard is architected to permit intermediaries to act as an for this purpose (such as [I-D.peterson-acme-telephone]) it is not
authentication service on behalf of an entire domain, just as in SIP mature enough to be recommended as a best practice. This is one
an proxy server can provide domain-level SIP service. While reason why the STIR standard is architected to permit intermediaries
certificate authorities that offered proof-of-possession certificates to act as an authentication service on behalf of an entire domain,
similar to those used in the email world could be offered for SIP, just as in SIP an proxy server can provide domain-level SIP service.
either for greenfield identifiers or for telephone numbers, this While certificate authorities that offered proof-of-possession
specification does not require their use. certificates similar to those used in the email world could be
offered for SIP, either for greenfield identifiers or for telephone
numbers, this specification does not require their use.
For users who do not possess such certificates, DTLS-SRTP [RFC5763] For users who do not possess such certificates, DTLS-SRTP [RFC5763]
permits the use of self-signed keys. This profile of STIR for media permits the use of self-signed keys. This profile of STIR for media
confidentiality therefore relaxes the authority requirements of confidentiality therefore relaxes the authority requirements of
[I-D.ietf-stir-rfc4474bis] to allow the use of self-signed keys for [I-D.ietf-stir-rfc4474bis] to allow the use of self-signed keys for
authentication services that are composed with user agents, by authentication services that are composed with user agents, by
generating a certificate (per the guidance of generating a certificate (per the guidance of
[I-D.ietf-stir-certificates]) with a subject corresponding to the [I-D.ietf-stir-certificates]) with a subject corresponding to the
user's identity. Such a credential could be used for trust on first user's identity. Such a credential could be used for trust on first
use (see [RFC7435]) by relying parties. Note that relying parties use (see [RFC7435]) by relying parties. Note that relying parties
skipping to change at page 6, line 32 skipping to change at page 6, line 39
RECOMMENDS using one-time self-signed certificates for anonymous RECOMMENDS using one-time self-signed certificates for anonymous
communications, with a subjectAltName of communications, with a subjectAltName of
"sip:anonymous@anonymous.invalid". After a session is terminated, "sip:anonymous@anonymous.invalid". After a session is terminated,
the certificate should be discarded, and a new one, with new keying the certificate should be discarded, and a new one, with new keying
material, should be generated before each future anonymous call. As material, should be generated before each future anonymous call. As
with self-signed certificates, relying parties SHOULD NOT use with self-signed certificates, relying parties SHOULD NOT use
certificate revocation mechanisms or real-time certificate certificate revocation mechanisms or real-time certificate
verification systems for anonymous certificates as they will not verification systems for anonymous certificates as they will not
increase confidence in the certificate. increase confidence in the certificate.
Note that when using one-time anonymous self-signed certificates, any
man in the middle could strip the Identity header and replace it with
one signed by its own one-time certificate, changing the "mkey"
parameters of PASSporT and any "a=fingerprint" attributes in SDP as
it chooses. This signature only provides protection against non-
Identity aware entities that might modify SDP without altering the
PASSporT conveyed in the Identity header.
4.3. Connected Identity Usage 4.3. Connected Identity Usage
STIR [I-D.ietf-stir-rfc4474bis] provides integrity protection for the STIR [I-D.ietf-stir-rfc4474bis] provides integrity protection for the
SDP bodies of SIP requests, but not SIP responses. When a session is SDP bodies of SIP requests, but not SIP responses. When a session is
established, therefore, any SDP body carried by a 200 class response established, therefore, any SDP body carried by a 200 class response
in the backwards direction will not be protected by an authentication in the backwards direction will not be protected by an authentication
service and cannot be verified. Thus, sending a secured SDP body in service and cannot be verified. Thus, sending a secured SDP body in
the backwards direction will require an extra RTT, typically a the backwards direction will require an extra RTT, typically a
request sent in the backwards direction. request sent in the backwards direction.
skipping to change at page 7, line 12 skipping to change at page 7, line 28
direction MUST be sent during dialog establishment, following the direction MUST be sent during dialog establishment, following the
receipt of a PRACK after a provisional 1xx response. receipt of a PRACK after a provisional 1xx response.
For use with this STIR Profile for media confidentiality, the UAS For use with this STIR Profile for media confidentiality, the UAS
that responds to the INVITE request MUST act as an authentication that responds to the INVITE request MUST act as an authentication
service for the UPDATE sent in the backwards direction. service for the UPDATE sent in the backwards direction.
The use of RFC4916 has some further interactions with ICE; see The use of RFC4916 has some further interactions with ICE; see
Section 7. Section 7.
4.4. Authorization Decisions
[I-D.ietf-stir-rfc4474bis] grants STIR verification services a great
deal of latitude when making authorization decisions based on the
presence of the Identity header field. It is largely a matter of
local policy whether an endpoint rejects a call based on absence of
an Identity header field, or even the presence of a header that fails
an integrity check against the request.
For the purposes of this STIR profile,
4.4.1. Opportunistic STIR
When the PASSporT object used by STIR contains the "mkey" attribute,
which protects the "a=fingerprint" attributes of SDP, STIR validation
will consequently fail when those attributes have been removed or
altered in transit. It would however be possible to convey with a
PASSporT attribute that the sender of an Identity-protected request
is using security on a best-effort basis, and that the originator of
the call would still like the call to connect even if it is not
possible to establish end-to-end confidentiality. In effect, this
would allow this profile of STIR for media confidentiality to behave
opportunistically.
5. Media Security Protocols 5. Media Security Protocols
As there are several ways to negotiate media security with SDP, any As there are several ways to negotiate media security with SDP, any
of which might be used with either opportunistic or comprehensive of which might be used with either opportunistic or comprehensive
protection, further guidance to implementers is needed. In protection, further guidance to implementers is needed. In
[I-D.johnston-dispatch-osrtp], opportunistic approaches considered [I-D.johnston-dispatch-osrtp], opportunistic approaches considered
include DTLS-SRTP, security descriptions [RFC4568], and ZRTP include DTLS-SRTP, security descriptions [RFC4568], and ZRTP
[RFC6189]. In order to prevent men-in-the-middle from decrypting [RFC6189].
media traffic, the "a=crypto" SDP parameter of security descriptions
requires signaling confidentiality which STIR and related
comprehensive protection approaches cannot provide, so delivering
keys by value in SDP in this fashion is NOT RECOMMENDED. Both DTLS-
SRTP and ZRTP instead provide hashes which are carried in SDP, and
thus require only integrity protection rather than confidentiality.
Of DTLS-SRTP and ZRTP, only DTLS-SRTP is a Standards Track Internet DTLS-SRTP is the only Standards Track Internet protocol for media
protocol. For that reason, this specification REQUIRES support for security. For that reason, this specification REQUIRES support for
DTLS-SRTP, and allows support for other media security protocols DTLS-SRTP.
OPTIONALLY.
[TBD] Future versions of this specification will explore the issue of The "mkey" claim of PASSporT provides integrity protection for
multiple fingerprints appearing in the message, and offers that "a=fingerprint" attributes in SDP, including cases where multiple
include both DTLS-SRTP and ZRTP security. "a=fingerprint" attributes appear in the same SDP.
6. Relayed Media and Conferencing 6. Relayed Media and Conferencing
Providing end-to-end media confidentiality for SIP is complicated by Providing end-to-end media confidentiality for SIP is complicated by
the presence of many forms of media relays. While many media relays the presence of many forms of media relays. While many media relays
merely proxy media to a destination, others present themselves as merely proxy media to a destination, others present themselves as
media endpoints and terminate security associations before re- media endpoints and terminate security associations before re-
originating media to its destination. originating media to its destination.
Centralized conference bridges are one type of entity that typically Centralized conference bridges are one type of entity that typically
terminates a media session in order to mux media from multiple terminates a media session in order to mux media from multiple
sources and then to re-originate the muxed media to conference sources and then to re-originate the muxed media to conference
participants. In many such implementations, only hop-by-hop media participants. In many such implementations, only hop-by-hop media
confidentiality is possible. Work is ongoing to specify a means to confidentiality is possible. Work is ongoing to specify a means to
encrypt both the hop-by-hop media between a user agent and a encrypt both the hop-by-hop media between a user agent and a
centralized server as well as the end-to-end media between user centralized server as well as the end-to-end media between user
agents. As this is the best practice for supporting agents, but is not sufficiently mature at this time to make a
[I-D.ietf-perc-double]. recommendation for a best practice here. Those protocols are
expected to identify their own best practice recommendations as they
mature.
Another class of entities that might relay SIP media are back-to-back Another class of entities that might relay SIP media are back-to-back
user agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879], user agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879],
it may be possible for those devices to act as media relays while it may be possible for those devices to act as media relays while
still permitting end-to-end confidentiality between user agents. still permitting end-to-end confidentiality between user agents.
Ultimately, if an endpoint can decrypt media it receives, then that Ultimately, if an endpoint can decrypt media it receives, then that
endpoint can forward the decrypted media without the knowledge or endpoint can forward the decrypted media without the knowledge or
consent of the media's originator. No media confidentiality consent of the media's originator. No media confidentiality
mechanism can protect against these sorts of relayed disclosures, or mechanism can protect against these sorts of relayed disclosures, or
skipping to change at page 8, line 50 skipping to change at page 9, line 38
recipients of media flows have consented to receive such flows. recipients of media flows have consented to receive such flows.
Implementations of this specification MUST implement the STUN usage Implementations of this specification MUST implement the STUN usage
for consent freshness defined in [RFC7675]. for consent freshness defined in [RFC7675].
8. Best Current Practices 8. Best Current Practices
The following are the best practices for SIP user agents to provide The following are the best practices for SIP user agents to provide
media confidentiality for SIP sessions. media confidentiality for SIP sessions.
Implementations MUST support the STIR endpoint profile given in Implementations MUST support the STIR endpoint profile given in
Section 4. Section 4, and signal that in PASSporT with the "msec" header
element.
Implementations MUST support DTLS-SRTP for key-management, as Implementations MUST support DTLS-SRTP for key-management, as
described in Section 5. described in Section 5.
Implementations MUST support the ICE, and the STUN consent freshness Implementations MUST support the ICE, and the STUN consent freshness
mechanism, as specified in Section 7. mechanism, as specified in Section 7.
Implementations MUST support the PERC "double" mechanism, as
specifies in Section 6.
9. Acknowledgments 9. Acknowledgments
We would like to thank Adam Roach, Andrew Hutton, and Ben Campbell We would like to thank Adam Roach, Andrew Hutton, and Ben Campbell
for contributions to this problem statement and framework. for contributions to this problem statement and framework.
10. IANA Considerations 10. IANA Considerations
This memo includes no requests to the IANA. This specification defines a new values for the PASSporT Type
registry called "msec," and the IANA is requested to add that to the
registry with a value pointing to [RFCThis].
11. Security Considerations 11. Security Considerations
This document describes the security features that provide media This document describes the security features that provide media
sessions established with SIP with confidentiality, integrity, and sessions established with SIP with confidentiality, integrity, and
authentication. authentication.
12. Informative References 12. Informative References
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
skipping to change at page 9, line 43 skipping to change at page 10, line 36
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-04 (work in progress), June 2016. rfc5245bis-04 (work in progress), June 2016.
[I-D.ietf-mmusic-trickle-ice-sip] [I-D.ietf-mmusic-trickle-ice-sip]
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) usage for Trickle ICE", Session Initiation Protocol (SIP) usage for Trickle ICE",
draft-ietf-mmusic-trickle-ice-sip-05 (work in progress), draft-ietf-mmusic-trickle-ice-sip-05 (work in progress),
August 2016. August 2016.
[I-D.ietf-perc-double]
Jennings, C., Jones, P., and A. Roach, "SRTP Double
Encryption Procedures", draft-ietf-perc-double-01 (work in
progress), July 2016.
[I-D.ietf-stir-certificates] [I-D.ietf-stir-certificates]
Peterson, J. and S. Turner, "Secure Telephone Identity Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir- Credentials: Certificates", draft-ietf-stir-
certificates-07 (work in progress), July 2016. certificates-10 (work in progress), October 2016.
[I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-10 (work in
progress), October 2016.
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-11 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-14
(work in progress), August 2016. (work in progress), October 2016.
[I-D.johnston-dispatch-osrtp] [I-D.johnston-dispatch-osrtp]
Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T. Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T.
Stach, "An Opportunistic Approach for Secure Real-time Stach, "An Opportunistic Approach for Secure Real-time
Transport Protocol (OSRTP)", draft-johnston-dispatch- Transport Protocol (OSRTP)", draft-johnston-dispatch-
osrtp-02 (work in progress), February 2016. osrtp-02 (work in progress), February 2016.
[I-D.kaplan-mmusic-best-effort-srtp] [I-D.kaplan-mmusic-best-effort-srtp]
Audet, F. and H. Kaplan, "Session Description Protocol Audet, F. and H. Kaplan, "Session Description Protocol
(SDP) Offer/Answer Negotiation For Best-Effort Secure (SDP) Offer/Answer Negotiation For Best-Effort Secure
Real-Time Transport Protocol", draft-kaplan-mmusic-best- Real-Time Transport Protocol", draft-kaplan-mmusic-best-
effort-srtp-01 (work in progress), October 2006. effort-srtp-01 (work in progress), October 2006.
[I-D.peterson-acme-telephone]
Peterson, J. and R. Barnes, "ACME Identifiers and
Challenges for Telephone Numbers", draft-peterson-acme-
telephone-00 (work in progress), October 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
 End of changes. 25 change blocks. 
104 lines changed or deleted 149 lines changed or added

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