One document matched: draft-wing-sipping-srtp-key-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc3903 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3903.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3830 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3830.xml">
<!ENTITY I-D.wing-rtpsec-keying-eval SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-rtpsec-keying-eval.xml">
<!ENTITY rfc4568 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4568.xml">
<!ENTITY I-D.ietf-sipping-config-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-config-framework.xml">
<!ENTITY I-D.ietf-sip-sips SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-sips.xml">
<!ENTITY I-D.ietf-sip-saml SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-saml.xml">
<!ENTITY I-D.zimmermann-avt-zrtp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zimmermann-avt-zrtp.xml">
<!ENTITY rfc4117 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4117.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-wing-sipping-srtp-key-02" ipr="full3978">
<front>
<title abbrev="SRTP Event Package">Disclosing Secure RTP (SRTP) Session
Keys with a SIP Event Package</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Francois Audet" initials="F." surname="Audet">
<organization>Nortel</organization>
<address>
<postal>
<street>4655 Great America Parkway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>USA</country>
</postal>
<email>audet@nortel.com</email>
</address>
</author>
<author fullname="Steffen Fries" initials="S." surname="Fries">
<organization>Siemens AG</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>steffen.fries@siemens.com</email>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H" surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<date day="15" month="November" year="2007" />
<abstract>
<t>Many Secure RTP (SRTP) key exchange mechanisms do not disclose the
SRTP session keys to intermediate SIP proxies. However, these key
exchange mechanisms cannot be used in environments where transcoding,
monitoring, or call recording are needed. This document specifies a
secure mechanism for a cooperating endpoint to disclose its SRTP master
keys to an authorized party.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document addresses 2 difficulties with End-to-end encryption of
RTP (<xref target="RFC3711">SRTP</xref>): transcoding and media
recording. When peering with other networks, different codecs are
sometimes necessary (transcoding a surround-sound codec for transmission
over a highly-compressed bandwidth-constrained network, for example). In
some environments (e.g., stock brokerages and banks) regulations and
business needs require recording calls with coworkers or with customers.
In many environments, quality problems such as echo can only be
diagnosed by listening to the call (analyzing SRTP headers is not
sufficient).</t>
<t>With an RTP stream, transcoding is accomplished by modifying SDP to
offer a different codec through a transcoding device <xref
target="RFC4117"></xref>, and call recording or monitoring can be
accomplished with an Ethernet sniffer listening for SIP and its
associated RTP, with a media relay, or with a Session Border Controller.
However, when media is encrypted end-to-end <xref
target="I-D.wing-rtpsec-keying-eval"></xref>, these existing techniques
fail because they are unable to decrypt the media packets.</t>
<t>When a media session is encrypted with SRTP, there are three
techniques to decrypt the media for monitoring or call recording:</t>
<t><list style="numbers">
<t>the endpoint establishes a separate media stream to the recording
device, with a separate SRTP key, and sends the (mixed) media to the
recording device. This techniques is often referenced as active
recording here. The disadvantages of this technique include doubling
bandwidth requirements in the network and additionally the
processing power on the client side, Moreover, the loss of media
recording facility doesn't cause loss of call (as is required in
some environments). A significant advantage of this technique,
however, is that it's secure: a malicious media recording device
cannot inject media to the connected party on behalf of the
endpoint. Depending on the application requirements it may be
necessary to establish a reliable connection to the recording device
to cope with possible packet loss on the unreliable link, typically
used for media transport.</t>
<t>the endpoint relays media through a device which forks a separate
media stream to the recording device. This technique is often
employed by Session Border Controllers, and could also be employed
by TURN servers.</t>
<t>Network monitoring devices are used to listen to the SRTP traffic
and correlate SRTP with SIP (with cooperation of call signaling
devices, if the call signaling is encrypted).</t>
</list></t>
<t>This document describes cases (2) and (3) where a cooperating
endpoint publishes its SRTP master keys to an authorized party using the
<xref target="RFC3903">SIP Event State Publication Extension</xref>. The
mechanism can be described as passive recording, as the client is not
directly involved into the media recording. It merely provides the key
information to a recording device. The mechanism described in this paper
allows secure disclosure of SRTP session keys to authorized parties so
that an endpoints media stream can be transcoded or decrypted, as needed
by that environment. Technique (1) stated above is not considered
further in this document, as it does not require the disclosure of the
key used for the communication between the two endpoints.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
<t>The following terminology is taken directly from <xref
target="RFC3903">SIP Event State Publication Extension</xref>:</t>
<t><list style="hanging">
<t hangText="Event Publication Agent (EPA):">The User Agent Client
(UAC) that issues PUBLISH requests to publish event state.</t>
<t hangText="Event State Compositor (ESC):">The User Agent Server
(UAS) that processes PUBLISH requests, and is responsible for
compositing event state into a complete, composite event state of a
resource.</t>
<t hangText="Publication:">The act of an EPA sending a PUBLISH
request to an ESC to publish event state.</t>
</list></t>
</section>
<section title="Operation">
<t>For transcoding, RTP packets must be sent from and received by a
device which performs the transcoding. When the media is encrypted, this
device must be capable of decrypting the media, performing the
transcoding function, and re-encrypting the media.</t>
<t><list>
<t>ISSUE-1: should we consider providing some or all of the SIP
headers, as well? Some recording functions will need to know the
identity of the remote party. This information could be gleaned from
the SIP proxies, though, and starts to fall outside the intended
scope of this document.</t>
<t>ISSUE-2: The authors have been considering use of <xref
target="RFC3830">MIKEY</xref>, but MIKEY may not be used off the
shelf. Certain changes to the state machine may have to be made
(RFC3830 describes the TGK transport rather than SRTP master key
transport).</t>
</list></t>
<section title="Learning Name and Certificate of ESC">
<t>The endpoint will be configured with the AOR of its ESC (e.g.,
"transcoder@example.com"). If S/MIME is used to send the SRTP master
key to the ESC, the endpoint is additionally configured with the
certificate of its ESC.</t>
<t>The name and public key of the ESC is configured into the
endpoint.It is vital that the public key of the ESC is not changed by
an unauthorized user. Changes to change that public key will cause
SRTP key disclosure to be encrypted with that key. It is RECOMMENDED
that endpoints restrict changing the public key of the disclosure
device using protections similar to changes to the endpoint's SIP
username and SIP password.</t>
</section>
<section title="Authorization of ESC">
<t>Depending on the application, authorization of the key disclosure
and distribution to the ESC may be necessary besides the pure
transport security of the key distribution itself. This may be the
case when the config framework <xref
target="I-D.ietf-sipping-config-framework"></xref> is not applied and
thus the information about the ESC is not known to the client.</t>
<t>This can be done by providing a SAML extension, according to <xref
target="I-D.ietf-sip-saml"></xref> in the header of the SUBSCRIBE
message. The SAML assertion shall at least contain the information
about the ESC, call related information to associate the call with the
assertion (editors note: we may also define wildcards here to allow
for recordings of all phone calls for a day, independent of the call)
and a reference to the certificate for the ESC. The latter information
is needed to transport the SRTP Session Key to the ESC in a protected
manner, as described in the section below.</t>
<t>The signature of the SAML assertion should be produced using the
private key of the domain certificate. This certificate MUST have a
SubjAltName which matches the domain of user agent's SIP proxy (that
is, if the SIP proxy is sip.example.com, the SubjAltName of the domain
certificate signing this SAML assertion MUST also be example.com).
Here, the main focus is placed on communication of clients with the
ESC, which belongs to the client's home domain.</t>
</section>
<section title="Sending SRTP Session Keys to ESC">
<t>SDP is used to describe the media session to the ESC. However, the
existing <xref target="RFC4568">Security Descriptions</xref> only
describes the master key and parameters of the SRTP packets being sent
-- it does not describe the master key (and parameters) of the SRTP
being received, or the SSRC being transmitted. For transcoding and
media recording, both the sending key and receiving key are needed and
in some cases the SSRC is needed.</t>
<t>Thus, we hereby extend the existing crypto attribute to indicate
the SSRC. We also create a new SDP attribute, "rcrypto", which is
identical to the existing "crypto" attribute, except that it describes
the receiving keys and their SSRCs. For example:</t>
<figure anchor="sdp_example" title="Example SDP">
<artwork><![CDATA[
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
SSRC=1899
a=rcrypto:1 AES_CM_128_HMAC_SHA1_80
inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32
SSRC=3289
a=rcrypto:1 AES_CM_128_HMAC_SHA1_80
inline:Hw3JFWNCFqSpTqNiYRj6HmSWKMHAmO4q1KIN1OVA|2^20|1:32
SSRC=4893
]]></artwork>
<postamble></postamble>
</figure>
<t>The full SDP, including the keying information, is then sent to the
ESC. The keying information MUST be encrypted and integrity protected.
Existing mechanisms such as <xref target="RFC3261">S/MIME</xref> and
<xref target="I-D.ietf-sip-sips">SIPS</xref> or SIP over TLS (on all
hops per administrative means) MAY be used to achieve this goal, or
other mechanisms may be defined.</t>
<t><list style="hanging">
<t hangText="[[">ISSUE-3: if a endpoint is receiving multiple
incoming streams from multiple endpoints, it will have negotiated
different keys with each of them, and all of that traffic is
coming to the same transport address on the endpoint. Thus, we
need a way to describe the different keys we're using to/from
different transport addresses. One solution is to indicate the
remote transport address. Indicating the remote SSRC is
insufficient for this task, as several SRTP keying mechanisms do
not include SSRC in their signaling (DTLS-SRTP, ZRTP, Security
Descriptions). <vspace blankLines="1" />For example, if there were
two remote peers with different keys, we could signal it like
this:<figure anchor="Issue_example_SDP" title="Strawman solution">
<preamble></preamble>
<artwork><![CDATA[ a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
192.0.2.1:5678 SSRC=1899 SSRC=3892
a=rcrypto:1 AES_CM_128_HMAC_SHA1_80
inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKKIN1Mw|2^20|1:32
192.0.2.1:5678 SSRC=3289 SSRC=2813
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:GdUJShpX1ZLEw6UzF3WSJjNzB4d1BINUAv+PSdFc|2^20|1:32
192.0.2.222:2893
a=rcrypto:1 AES_CM_128_HMAC_SHA1_80
inline:6UzF3IN1ZLEwAv+PSdFcWUGdUJShpXSJjNzB4d1B|2^20|1:32
192.0.2.222:2893]]></artwork>
<postamble></postamble>
</figure></t>
<t hangText="]]"></t>
</list></t>
</section>
<section title="Scenarios and Call Flows">
<t>The following scenarios and call flows depict the assumptions for
the provision of media key disclosure. <xref target="topology"></xref>
shows the general setup within the home domain of the client. Note
that the authors assume that the client only discloses media keys only
to an entity in the client's home network rather than to an arbitrary
entity in the visited network.</t>
<figure anchor="topology" title="Network Topology">
<artwork><![CDATA[
+----------+ +-------+ +---------+ +--------+ +----------+
| SIP User | | SIP | |SIP Proxy| | Media | | SIP |
|Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent|
+----------+ +-------+ +---------+ +--------+ +----------+
| | | | |
+----------+----------+-----------+-----------+
]]></artwork>
</figure>
<t>Based on this setup there are different options to realize the key
disclosure, depending on the environment. In the following two
approaches are distingusihed.</t>
<t><list style="hanging">
<t hangText="Publishing media keys to the ESC"><vspace
blankLines="1" /> This requires that the configuration management
provides the ESC configuration data (e.g., certificate, policy) in
a secure way to the client. As stated above, this configuration is
outside the scope of this document, but an example can be found in
<xref target="I-D.ietf-sipping-config-framework"></xref>. The key
disclosure in this approach uses the PUBLISH method to disclose
the key to the ESC according to a given policy. <vspace
blankLines="1" /> <figure>
<artwork><![CDATA[
+----------+ +-------+ +---------+ +--------+ +----------+
| SIP User | | SIP | |SIP Proxy| | Media | | SIP |
|Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent|
+----------+ +-------+ +---------+ +--------+ +----------+
| | | | |
|-REGISTER->| | | |
|<-200 OK---| | | |
| | | | |
|--INVITE-->|-------------INVITE------------->|
|<-200 Ok---|<------------200 Ok------------- |
| | | | |
|<====SRTP in both directions================>|
| | | | |
|-PUBLISH-->|-PUBLISH-->|-key----->| |
|<-200 Ok---|<--200 Ok--| | |
]]></artwork>
</figure> <vspace blankLines="1" /> Note that the protocol
between the ESC and the media recorder is out of scope of this
document.</t>
<t hangText="Using SAML assertions for ESC contact"><vspace
blankLines="1" /> In this approach authorization is provided via a
SAML assertion, see <xref target="I-D.ietf-sip-saml"></xref>,
indicating which ESC is allowed to perform call recording of a
single or a set of calls, depending on the content of the
assertion. Here a SAML assertion is provided as part of the
SUBSCRIBE message, send from the ESC to the client. The assertion
needs to provide at least the call relation, or a time intervall
for which media recoding is going to be performed. The SAML
assertion is signed with the private key associated with the
domain certificate, which is in possession of the authentication
service. The call flow would look like following: <vspace
blankLines="1" /> <figure>
<artwork><![CDATA[
+----------+ +-------+ +---------+ +--------+ +----------+
| SIP User | | SIP | |SIP Proxy| | Media | | SIP |
|Agent(EPA)| | Proxy | | (ESC) | |Recorder| |User Agent|
+----------+ +-------+ +---------+ +--------+ +----------+
| | | | |
|-REGISTER->| | | |
|<-200 OK---| | | |
| | | | |
|<-SUBSCRIBE (SAML as.)-| | |
| | | | |
|--INVITE-->|-------------INVITE------------->|
|<-200 Ok---|<------------200 Ok------------- |
| | | | |
|<====SRTP in both directions================>|
| | | | |
|--NOTIFY (SRTP data)-->| | |
| | | | |
]]></artwork>
</figure></t>
</list></t>
</section>
</section>
<section title="Grammar">
<t>[[Grammar will be provided in a subsequent version of this
document.]]</t>
</section>
<section title="Security Considerations">
<t></t>
<section title="Incorrect ESC">
<t>Insertion of the incorrect public key of the SRTP ESC will result
in disclosure of the SRTP session key to an unauthorized party. Thus,
the UA's configuration MUST be protected to prevent such
misconfiguration. To avoid changes to the configuration in the end
device, the configuration access MUST be suitably protected.</t>
</section>
<section anchor="disclosing_srtp_session_key"
title="Risks of Sharing SRTP Session Key">
<t>A party authorized to obtain the SRTP session key can listen to the
media stream and could inject data into the media stream as if it were
either party. The alternatives are worse: disclose the device's
private key to the transcoder or media recording device, or abandon
using secure SRTP key exchange in environments that require media
transcoding or media recording. As we wish to promote the use of
secure SRTP key exchange mechanisms, disclosure of the SRTP session
key appears the least of these evils.</t>
</section>
<section title="Disclosure Flag">
<t>Secure SRTP key exchange techniques which implement this
specification SHOULD provide a "disclosure flag", similar to that
first proposed in Appendix B of <xref
target="I-D.zimmermann-avt-zrtp"></xref>.</t>
</section>
<section title="Integrity and encryption of keying information">
<t>The mechanism describe in this specification relies on protecting
and encrypting the keying infomation. There are well known mechanism
to achieve that goal.</t>
<t>Using SIPS to convey the SRTP key exposes the SRTP master key to
all SIP proxies between the Event Publication Agent (ESC, the SIP User
Agent) and the Event State Compositor (ESC). S/MIME allows disclosing
the SRTP master key to only the ESC.</t>
</section>
</section>
<section title="IANA Considerations">
<t>New SSRC extension of the "crypto" attribute, and the new "rcrypto"
attribute will be registered here.</t>
</section>
<section title="Examples">
<figure anchor="sips_example" title="Example with "SIPS:" AOR">
<preamble>This is an example showing a SIPS AOR for the ESC. This
relies on the SIP network providing TLS encryption of the SRTP master
keys to the ESC.</preamble>
<artwork><![CDATA[
PUBLISH sips:recorder@example.com SIP/2.0
Via: SIP/2.0/TLS pua.example.com;branch=z9hG4bK652hsge
To: <sips:recorder@example.com>
From: <sips:dan@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
Expires: 3600
Event: srtp
Content-Type: application/sdp
Content-Length: ...
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=rcrypto:1 AES_CM_128_HMAC_SHA1_80
inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32
a=rtpmap:0 PCMU/8000
]]></artwork>
<postamble></postamble>
</figure>
<figure anchor="s_mime_example"
title="Example with S/MIME-encrypted SDP">
<preamble>This is an example showing an S/MIME-encrypted transmission
to the media recorder's AOR, recorder@example.com. The data enclosed
in "*" is encrypted with recorder@example.com's public key.</preamble>
<artwork><![CDATA[
PUBLISH sip:recorder@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
To: <sip:recorder@example.com>
From: <sip:dan@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
Expires: 3600
Event: srtp
Content-Type: application/pkcs7-mime;smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: binary
Content-ID: 1234@atlanta.example.com
Content-Disposition: attachment;filename=smime.p7m;
handling=required
Content-Length: ...
******************************************************************
* (encryptedContentInfo) *
* Content-Type: application/sdp *
* Content-Length: ... *
* *
* v=0 *
* o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com*
* s=- *
* c=IN IP4 192.0.2.101 *
* t=0 0 *
* m=audio 49172 RTP/SAVP 0 *
* a=crypto:1 AES_CM_128_HMAC_SHA1_80 *
* inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 *
* a=rcrypto:1 AES_CM_128_HMAC_SHA1_80 *
* inline:AmO4q1OVAHNiYRj6HmS3JFWNCFqSpTqHWKI8K1Mw|2^20|1:32 *
* a=rtpmap:0 PCMU/8000 *
* *
******************************************************************]]></artwork>
<postamble></postamble>
</figure>
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3711;
&rfc3903;
&rfc3261;
</references>
<references title="Informational References">
&rfc3830;
&I-D.wing-rtpsec-keying-eval;
&rfc4568;
&I-D.ietf-sipping-config-framework;
&I-D.ietf-sip-sips;
&I-D.ietf-sip-saml;
&I-D.zimmermann-avt-zrtp;
&rfc4117;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 21:43:41 |