draft-ietf-sipbrandy-rtpsec-01.txt   draft-ietf-sipbrandy-rtpsec-02.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: May 4, 2017 R. Barnes Expires: September 14, 2017 R. Barnes
Mozilla Mozilla
R. Housley R. Housley
Vigilsec Vigilsec
October 31, 2016 March 13, 2017
Best Practices for Securing RTP Media Signaled with SIP Best Practices for Securing RTP Media Signaled with SIP
draft-ietf-sipbrandy-rtpsec-01.txt draft-ietf-sipbrandy-rtpsec-02.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 May 4, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . 7
4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 7 4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 8
4.4.1. Opportunistic STIR . . . . . . . . . . . . . . . . . 7
5. Media Security Protocols . . . . . . . . . . . . . . . . . . 8 5. Media Security Protocols . . . . . . . . . . . . . . . . . . 8
6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 8 6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9
7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9 7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9
8. Best Current Practices . . . . . . . . . . . . . . . . . . . 9 8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. Informative References . . . . . . . . . . . . . . . . . . . 10 12. Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 (optionally) for body security. SIP is security, to S/MIME (optionally) for body security. SIP is
frequently used to establish media sessions, in particular audio or frequently used to establish media sessions, in particular audio or
audiovisual sessions, which have their own security mechanisms audiovisual sessions, which have their own security mechanisms
available, such as Secure RTP [RFC3711]. However, the practices available, such as Secure RTP [RFC3711]. However, the practices
skipping to change at page 6, line 15 skipping to change at page 6, line 15
[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
SHOULD NOT use certificate revocation mechanisms or real-time SHOULD NOT use certificate revocation mechanisms or real-time
certificate verification systems for self-signed certificates as they certificate verification systems for self-signed certificates as they
will not increase confidence in the certificate. will not increase confidence in the certificate.
Users who wish to remain anonymous can instead generate self-signed Users who wish to remain anonymous can instead generate self-signed
certificates as described in Section 4.2. certificates as described in Section 4.2.
Generally speaking, without access to out-of-band information about
which certificates were issued to whom, it will be very difficult for
relying parties to ascertain whether or not the signer of a SIP
request is genuinely an "endpoint." Even the term "endpoint" is a
problematic one, as SIP user agents can be composed in a variety of
architectures and may not be devices under direct user control.
While it is possible that techniques based on certificate
transparency [RFC6962] or similar practices could help user agents to
recognize one another's certificates, those operational systems will
need to ramp up with the certificate authorities that issue
credentials to end user devices going forward.
4.2. Anonymous Communications 4.2. Anonymous Communications
In some cases, the identity of the initiator of a SIP session may be In some cases, the identity of the initiator of a SIP session may be
withheld due to user or provider policy. Per the recommendations of withheld due to user or provider policy. Per the recommendations of
[RFC3323], this may involve using an identity such as [RFC3323], this may involve using an identity such as
"anonymous@anonymous.invalid" in the identity fields of a SIP "anonymous@anonymous.invalid" in the identity fields of a SIP
request. [I-D.ietf-stir-rfc4474bis] does not currently permit request. [I-D.ietf-stir-rfc4474bis] does not currently permit
authentication services to sign for requests that supply this authentication services to sign for requests that supply this
identity. It does however permit signing for valid domains, such as identity. It does however permit signing for valid domains, such as
"anonymous@example.com," as a way of implementation an anonymization "anonymous@example.com," as a way of implementation an anonymization
skipping to change at page 7, line 25 skipping to change at page 7, line 39
following updates to [RFC4916] are required: following updates to [RFC4916] are required:
The UPDATE carrying signed SDP with a fingerprint in the backwards The UPDATE carrying signed SDP with a fingerprint in the backwards
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 text in RFC4916 Section 4.4.1 regarding the receipt at a UAC
of error codes 428, 436, 437 and 438 in response to a mid-dialog
request RECOMMENDS treating the dialog as terminated.
[I-D.ietf-stir-rfc4474bis] allows the retransmission of requests
with repairable error conditions (see section 6.1.1) in a way that
can override that SHOULD in RFC4916. In particular, an
authentication service MAY retry a mid-dialog as
[I-D.ietf-stir-rfc4474bis] allows rather than treating the dialog
as terminated, though note that only one such retry is permitted.
The examples in RFC4916 are based on the original RFC4474, and
will not match signatures using [I-D.ietf-stir-rfc4474bis].
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 4.4. Authorization Decisions
[I-D.ietf-stir-rfc4474bis] grants STIR verification services a great [I-D.ietf-stir-rfc4474bis] grants STIR verification services a great
deal of latitude when making authorization decisions based on the deal of latitude when making authorization decisions based on the
presence of the Identity header field. It is largely a matter of presence of the Identity header field. It is largely a matter of
local policy whether an endpoint rejects a call based on absence 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 Identity header field, or even the presence of a header that fails
an integrity check against the request. an integrity check against the request.
For the purposes of this STIR profile, For this profile, however, a compliant verification service that
receives a dialog-forming SIP request containing an Identity header
4.4.1. Opportunistic STIR with a PASSporT type of "msec", after validating the request per the
steps described in [I-D.ietf-stir-rfc4474bis] Section 6.2, MUST
reject the request if there is any failure in that validation process
with the appropriate status code per Section 6.2.2. If the request
is valid, then if a terminating user accepts the request, it MUST
then follow the steps in Section 4.3 to act as an authentication
service and send a signed request with the "msec" PASSPorT type in
its Identity header as well, in order to enable end-to-end
bidirectional confidentiality.
When the PASSporT object used by STIR contains the "mkey" attribute, For the purposes of this profile, the "msec" PASSporT type can be
which protects the "a=fingerprint" attributes of SDP, STIR validation used by authentication services in one of two ways: as a mandatory
will consequently fail when those attributes have been removed or request for media security, or as a merely opportunistic request for
altered in transit. It would however be possible to convey with a media security. As any verification service that receives an
PASSporT attribute that the sender of an Identity-protected request Identity header in a SIP request with an unrecognized PASSporT type
is using security on a best-effort basis, and that the originator of will simply ignore that Identity header, an authentication service
the call would still like the call to connect even if it is not will know whether or not the terminating side supports "msec" based
possible to establish end-to-end confidentiality. In effect, this on whether or not its user agent receives a signed request in the
would allow this profile of STIR for media confidentiality to behave backwards direction per Section 4.3. If no such requests are
opportunistically. received, the UA may do one or two things: shut down the dialog, if
the policy of the UA requires that "msec" be supported by the
terminating side for this dialog; or, if policy permits, allow the
dialog to continue without media security.
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]. [RFC6189].
skipping to change at page 9, line 41 skipping to change at page 10, line 32
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, and signal that in PASSporT with the "msec" header Section 4, and signal that in PASSporT with the "msec" header
element. element.
Implementations MUST follow the authorization decision behavior in
Section 4.4.
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.
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.
skipping to change at page 10, line 28 skipping to change at page 11, line 23
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]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
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-08 (work in progress), December 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-07 (work in progress),
August 2016. March 2017.
[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-10 (work in progress), October 2016. certificates-11 (work in progress), October 2016.
[I-D.ietf-stir-passport] [I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Personal Assertion Token Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-10 (work in (PASSporT)", draft-ietf-stir-passport-11 (work in
progress), October 2016. progress), February 2017.
[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-14 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(work in progress), October 2016. (work in progress), February 2017.
[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
skipping to change at page 12, line 36 skipping to change at page 13, line 32
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Media Path Key Agreement for Unicast Secure RTP", Media Path Key Agreement for Unicast Secure RTP",
RFC 6189, DOI 10.17487/RFC6189, April 2011, RFC 6189, DOI 10.17487/RFC6189, April 2011,
<http://www.rfc-editor.org/info/rfc6189>. <http://www.rfc-editor.org/info/rfc6189>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919, for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013, DOI 10.17487/RFC6919, April 2013,
<http://www.rfc-editor.org/info/rfc6919>. <http://www.rfc-editor.org/info/rfc6919>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>.
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
"An Architecture for Media Recording Using the Session "An Architecture for Media Recording Using the Session
Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
2014, <http://www.rfc-editor.org/info/rfc7245>. 2014, <http://www.rfc-editor.org/info/rfc7245>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>. 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
 End of changes. 20 change blocks. 
35 lines changed or deleted 77 lines changed or added

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