draft-ietf-sipbrandy-rtpsec-05.txt   draft-ietf-sipbrandy-rtpsec-06.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Best Current Practice R. Barnes Intended status: Best Current Practice R. Barnes
Expires: April 15, 2019 Mozilla Expires: April 18, 2019 Mozilla
R. Housley R. Housley
Vigil Security Vigil Security
October 12, 2018 October 15, 2018
Best Practices for Securing RTP Media Signaled with SIP Best Practices for Securing RTP Media Signaled with SIP
draft-ietf-sipbrandy-rtpsec-05 draft-ietf-sipbrandy-rtpsec-06
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 42 skipping to change at page 1, line 42
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 15, 2019. This Internet-Draft will expire on April 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 25 skipping to change at page 3, line 25
implementers should use to negotiate secure media with SIP. It implementers should use to negotiate secure media with SIP. It
moreover gives a gap analysis of the limitations of existing moreover gives a gap analysis of the limitations of existing
solutions, and specifies solutions to address them. solutions, and specifies solutions to address them.
Various specifications that user agents must implement to support Various specifications that user agents must implement to support
media confidentiality are given in the sections below; a summary of media confidentiality are given in the sections below; a summary of
the best current practices appears in Section 8. the best current practices appears in Section 8.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as "OPTIONAL" in this document are to be interpreted as described in BCP
described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919]. 14 RFC 2119 [RFC2119] and RFC 8174 [RFC8174] when, and only when,
they appear in all capitals, as shown here.
3. Security at the SIP and SDP layer 3. Security at the SIP and SDP layer
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
skipping to change at page 5, line 33 skipping to change at page 5, line 33
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 [RFC8224]. STIR verification service roles described in [RFC8224]. STIR
authentication services MUST signal their compliance with this authentication services MUST signal their compliance with this
specification by adding the "msec" header element defined in this specification by adding the "msec" header element defined in this
specification to the PASSporT header. Implementations MUST provide specification to the PASSporT header. Implementations MUST provide
key fingerprints in SDP and the appropriate signatures over them per key fingerprints in SDP and the appropriate signatures over them per
[RFC8225]. [RFC8225].
When generating either an offer or an answer, compliant When generating either an offer or an answer [RFC3264], 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 in the user In order to implement the authentication service function in the user
agent, SIP endpoints will need to acquire the credentials needed to agent, SIP endpoints will need to acquire the credentials needed to
sign for their own identity. That identity is typically carried in sign for their own identity. That identity is typically carried in
the From header field of a SIP request, and either contains a the From header field of a SIP request, and either contains a
greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone
skipping to change at page 10, line 15 skipping to change at page 10, line 15
sent elsewhere (see [RFC7245]). sent elsewhere (see [RFC7245]).
7. ICE and Connected Identity 7. ICE and Connected Identity
Providing confidentiality for media with comprehensive protection Providing confidentiality for media with comprehensive protection
requires careful timing of when media streams should be sent and when requires careful timing of when media streams should be sent and when
a user interface should signify that confidentiality is in place. a user interface should signify that confidentiality is in place.
In order to best enable end-to-end connectivity between user agents, In order to best enable end-to-end connectivity between user agents,
and to avoid media relays as much as possible, implementations of and to avoid media relays as much as possible, implementations of
this specification must support ICE [I-D.ietf-ice-rfc5245bis]. To this specification must support ICE [RFC8445]. To speed up call
speed up call establishment, it is RECOMMENDED that implementations establishment, it is RECOMMENDED that implementations support trickle
support trickle ICE [I-D.ietf-mmusic-trickle-ice-sip]. ICE [I-D.ietf-mmusic-trickle-ice-sip].
Note that in the comprehensive protection case, the use of Connected Note that in the comprehensive protection case, the use of Connected
Identity [RFC4916] with ICE entails that the answer containing the Identity [RFC4916] with ICE entails that the answer containing the
key fingerprints, and thus the STIR signature, will come in an UPDATE key fingerprints, and thus the STIR signature, will come in an UPDATE
sent in the backwards direction a provisional response and sent in the backwards direction a provisional response and
acknowledgment (PRACK), rather than in any earlier SDP body. Only at acknowledgment (PRACK), rather than in any earlier SDP body. Only at
such a time as that UPDATE is received will the media keys be such a time as that UPDATE is received will the media keys be
considered exchanged in this case. considered exchanged in this case.
Similarly, in order to prevent, or at least mitigate, the denial-of- Similarly, in order to prevent, or at least mitigate, the denial-of-
service attack envisioned in [RFC5245] Section 18.5.1, this service attack described in Section 19.5.1 of [RFC8445], this
specification incorporates best practices for ensuring that specification incorporates best practices for ensuring that
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.
skipping to change at page 12, line 23 skipping to change at page 12, line 23
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<https://www.rfc-editor.org/info/rfc4568>. <https://www.rfc-editor.org/info/rfc4568>.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
2007, <https://www.rfc-editor.org/info/rfc4916>. 2007, <https://www.rfc-editor.org/info/rfc4916>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/info/rfc5763>. 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Media Path Key Agreement for Unicast Secure RTP",
RFC 6189, DOI 10.17487/RFC6189, April 2011,
<https://www.rfc-editor.org/info/rfc6189>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013,
<https://www.rfc-editor.org/info/rfc6919>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>.
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
"An Architecture for Media Recording Using the Session
Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
2014, <https://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, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
Thomson, "Session Traversal Utilities for NAT (STUN) Usage Thomson, "Session Traversal Utilities for NAT (STUN) Usage
for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
October 2015, <https://www.rfc-editor.org/info/rfc7675>. October 2015, <https://www.rfc-editor.org/info/rfc7675>.
[RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V.,
and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back
User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016,
<https://www.rfc-editor.org/info/rfc7879>. <https://www.rfc-editor.org/info/rfc7879>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224, Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018, DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>. <https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>. <https://www.rfc-editor.org/info/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226, Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018, DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>. <https://www.rfc-editor.org/info/rfc8226>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-acme-telephone] [I-D.ietf-acme-telephone]
Peterson, J. and R. Barnes, "ACME Identifiers and Peterson, J. and R. Barnes, "ACME Identifiers and
Challenges for Telephone Numbers", draft-ietf-acme- Challenges for Telephone Numbers", draft-ietf-acme-
telephone-01 (work in progress), October 2017. telephone-01 (work in progress), October 2017.
[I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-20 (work in progress), March 2018.
[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 Incremental Session Initiation Protocol (SIP) Usage for Incremental
Provisioning of Candidates for the Interactive Provisioning of Candidates for the Interactive
Connectivity Establishment (Trickle ICE)", draft-ietf- Connectivity Establishment (Trickle ICE)", draft-ietf-
mmusic-trickle-ice-sip-18 (work in progress), June 2018. mmusic-trickle-ice-sip-18 (work in progress), June 2018.
[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.
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Media Path Key Agreement for Unicast Secure RTP",
RFC 6189, DOI 10.17487/RFC6189, April 2011,
<https://www.rfc-editor.org/info/rfc6189>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>.
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
"An Architecture for Media Recording Using the Session
Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
2014, <https://www.rfc-editor.org/info/rfc7245>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <https://www.rfc-editor.org/info/rfc7435>.
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
Email: jon.peterson@team.neustar Email: jon.peterson@team.neustar
Richard Barnes Richard Barnes
Mozilla Mozilla
 End of changes. 15 change blocks. 
53 lines changed or deleted 42 lines changed or added

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