< draft-ietf-sipbrandy-rtpsec-06.txt   draft-ietf-sipbrandy-rtpsec-07.txt >
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Best Current Practice R. Barnes Updates: 4916 (if approved) R. Barnes
Expires: April 18, 2019 Mozilla Intended status: Best Current Practice Cisco
R. Housley Expires: August 5, 2019 R. Housley
Vigil Security Vigil Security
October 15, 2018 February 01, 2019
Best Practices for Securing RTP Media Signaled with SIP Best Practices for Securing RTP Media Signaled with SIP
draft-ietf-sipbrandy-rtpsec-06 draft-ietf-sipbrandy-rtpsec-07
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 18, 2019. This Internet-Draft will expire on August 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
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 3, line 27 skipping to change at page 3, line 27
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 RFC 2119 [RFC2119] and RFC 8174 [RFC8174] when, and only when, BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
they appear in all capitals, as shown here. 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 16 skipping to change at page 5, line 16
implemented at an intermediary rather than an endpoint, this implemented at an intermediary rather than an endpoint, this
introduces the possibility that the intermediary could act as a man introduces the possibility that the intermediary could act as a man
in the middle, altering key fingerprints. As this attack is not in in the middle, altering key fingerprints. As this attack is not in
STIR's core threat model, which focuses on impersonation rather than STIR's core threat model, which focuses on impersonation rather than
man-in-the-middle attacks, STIR offers no specific protections man-in-the-middle attacks, STIR offers no specific protections
against such interference. against such interference.
The SIPBRANDY deployment profile of STIR for media confidentiality The SIPBRANDY deployment profile of STIR for media confidentiality
thus shifts these responsibilities to the endpoints rather than the thus shifts these responsibilities to the endpoints rather than the
intermediaries. While intermediaries MAY provide the verification intermediaries. While intermediaries MAY provide the verification
service function of STIR for SIPBRANDY transactions, intermediaries service function of STIR for SIPBRANDY transactions, the verification
supporting this specification MUST NOT block or otherwise redirects needs to be repeated at the endpoint obtain the end-to-end assurance.
calls if they do not trust the signing credential. The SIPBRANDY Intermediaries supporting this specification MUST NOT block or
profile is based on an end-to-end trust model, so it is up to the otherwise redirects calls if they do not trust the signing
endpoints to determine if they support signing credentials, not credential. The SIPBRANDY profile is based on an end-to-end trust
intermediaries. model, so it is up to the endpoints to determine if they support
signing credentials, not 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 [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].
skipping to change at page 5, line 45 skipping to change at page 5, line 46
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
number, which can appear in a variety of ways (e.g. number, which can appear in a variety of ways (e.g.
"sip:+17004561212@example.com;user=phone"). [RFC8224] Section 8 "sip:+17004561212@example.com;user=phone"). Section 8 of [RFC8224]
contains guidance for separating the two, and determining what sort contains guidance for separating the two, and determining what sort
of credential is needed to sign for each. of credential is needed to sign for each.
To date, few commercial certificate authorities issue certificates To date, few commercial certification authorities (CAs) issue
for SIP URIs or telephone numbers; though work is ongoing on systems certificates for SIP URIs or telephone numbers; though work is
for this purpose (such as [I-D.ietf-acme-telephone]) it is not mature ongoing on systems for this purpose (such as
enough to be recommended as a best practice. This is one reason why [I-D.ietf-acme-telephone]) it is not mature enough to be recommended
the STIR standard is architected to permit intermediaries to act as as a best practice. This is one reason why the STIR standard is
an authentication service on behalf of an entire domain, just as in architected to permit intermediaries to act as an authentication
SIP an proxy server can provide domain-level SIP service. While service on behalf of an entire domain, just as in SIP an proxy server
certificate authorities that offered proof-of-possession certificates can provide domain-level SIP service. While CAs that offer proof-of-
similar to those used in the email world could be offered for SIP, possession certificates similar to those used in the email world
either for greenfield identifiers or for telephone numbers, this could be offered for SIP, either for greenfield identifiers or for
specification does not require their use. 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 therefore permits the use of self-signed keys. This profile of STIR employs
relaxes the authority requirements of [RFC8224] to allow the use of more relaxed authority requirements of [RFC8224] to allow the use of
self-signed keys for authentication services that are composed with self-signed keys for authentication services that are composed with
user agents, by generating a certificate (per the guidance of user agents, by generating a certificate (per the guidance of
[RFC8226]) with a subject corresponding to the user's identity. Such [RFC8226]) with a subject corresponding to the user's identity. To
a credential could be used for trust on first use (see [RFC7435]) by obtain comprehensive protection with a self-signed certificate, some
relying parties. Note that relying parties SHOULD NOT use out-of-band verification is needed as well. Such a credential could
certificate revocation mechanisms or real-time certificate be used for trust on first use (see [RFC7435]) by relying parties.
verification systems for self-signed certificates as they will not Note that relying parties SHOULD NOT use certificate revocation
increase confidence in the certificate. mechanisms or real-time certificate verification systems for self-
signed certificates as they 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 Generally speaking, without access to out-of-band information about
which certificates were issued to whom, it will be very difficult for which certificates were issued to whom, it will be very difficult for
relying parties to ascertain whether or not the signer of a SIP relying parties to ascertain whether or not the signer of a SIP
request is genuinely an "endpoint." Even the term "endpoint" is a request is genuinely an "endpoint." Even the term "endpoint" is a
problematic one, as SIP user agents can be composed in a variety of problematic one, as SIP user agents can be composed in a variety of
architectures and may not be devices under direct user control. architectures and may not be devices under direct user control.
skipping to change at page 7, line 51 skipping to change at page 8, line 5
[RFC4916] are required: [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 The text in Section 4.4.1 of [RFC4916] regarding the receipt at a
of error codes 428, 436, 437 and 438 in response to a mid-dialog UAC of error codes 428, 436, 437 and 438 in response to a mid-
request RECOMMENDS treating the dialog as terminated. [RFC8224] dialog request RECOMMENDS treating the dialog as terminated.
allows the retransmission of requests with repairable error [RFC8224] allows the retransmission of requests with repairable
conditions (see section 6.1.1) in a way that can override that error conditions (see Section 6.1.1) in a way that can override
SHOULD in RFC4916. In particular, an authentication service MAY that SHOULD in [RFC4916]. In particular, an authentication
retry a mid-dialog as [RFC8224] allows rather than treating the service MAY retry a mid-dialog as [RFC8224] allows rather than
dialog as terminated, though note that only one such retry is treating the dialog as terminated, though note that only one such
permitted. retry is permitted.
The examples in RFC4916 are based on the original RFC4474, and The examples in [RFC4916] are based on the original [RFC4916], and
will not match signatures using [RFC8224]. will not match signatures using [RFC4474].
Future work may be done to revise RFC4916 for STIR; that work should Future work may be done to revise [RFC4916] for STIR; that work
take into account any impacts on the profile described in this should take into account any impacts on the profile described in this
document. The use of RFC4916 has some further interactions with ICE; document. The use of [RFC4916] has some further interactions with
see Section 7. ICE; see Section 7.
4.4. Authorization Decisions 4.4. Authorization Decisions
[RFC8224] grants STIR verification services a great deal of latitude [RFC8224] grants STIR verification services a great deal of latitude
when making authorization decisions based on the presence of the when making authorization decisions based on the presence of the
Identity header field. It is largely a matter of local policy Identity header field. It is largely a matter of local policy
whether an endpoint rejects a call based on absence of an Identity whether an endpoint rejects a call based on absence of an Identity
header field, or even the presence of a header that fails an header field, or even the presence of a header that fails an
integrity check against the request. integrity check against the request.
For this profile, however, a compliant verification service that For this profile, however, a compliant verification service that
receives a dialog-forming SIP request containing an Identity header receives a dialog-forming SIP request containing an Identity header
with a PASSporT type of "msec", after validating the request per the with a PASSporT type of "msec", after validating the request per the
steps described in [RFC8224] Section 6.2, MUST reject the request if steps described in Section 6.2 of [RFC8224], MUST reject the request
there is any failure in that validation process with the appropriate if there is any failure in that validation process with the
status code per Section 6.2.2. If the request is valid, then if a appropriate status code per Section 6.2.2. If the request is valid,
terminating user accepts the request, it MUST then follow the steps then if a terminating user accepts the request, it MUST then follow
in Section 4.3 to act as an authentication service and send a signed the steps in Section 4.3 to act as an authentication service and send
request with the "msec" PASSPorT type in its Identity header as well, a signed request with the "msec" PASSPorT type in its Identity header
in order to enable end-to-end bidirectional confidentiality. as well, in order to enable end-to-end bidirectional confidentiality.
For the purposes of this profile, the "msec" PASSporT type can be For the purposes of this profile, the "msec" PASSporT type can be
used by authentication services in one of two ways: as a mandatory used by authentication services in one of two ways: as a mandatory
request for media security, or as a merely opportunistic request for request for media security, or as a merely opportunistic request for
media security. As any verification service that receives an media security. As any verification service that receives an
Identity header in a SIP request with an unrecognized PASSporT type Identity header in a SIP request with an unrecognized PASSporT type
will simply ignore that Identity header, an authentication service will simply ignore that Identity header, an authentication service
will know whether or not the terminating side supports "msec" based will know whether or not the terminating side supports "msec" based
on whether or not its user agent receives a signed request in the on whether or not its user agent receives a signed request in the
backwards direction per Section 4.3. If no such requests are backwards direction per Section 4.3. If no such requests are
received, the UA may do one or two things: shut down the dialog, if 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 the policy of the UA requires that "msec" be supported by the
terminating side for this dialog; or, if policy permits, allow the terminating side for this dialog; or, if policy permits (e.g. an
dialog to continue without media security. explicit acceptance by the user), 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 13, line 46 skipping to change at page 13, line 46
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.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006,
<https://www.rfc-editor.org/info/rfc4474>.
[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,
<https://www.rfc-editor.org/info/rfc6189>. <https://www.rfc-editor.org/info/rfc6189>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>. <https://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,
skipping to change at page 14, line 26 skipping to change at page 14, line 31
December 2014, <https://www.rfc-editor.org/info/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 Cisco
Email: rlb@ipv.sx Email: rlb@ipv.sx
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 18 change blocks. 
61 lines changed or deleted 71 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/