One document matched: draft-zhou-mmusic-sdes-keymod-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-zhou-mmusic-sdes-keymod-01"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="draft-zhou-mmusic-sdes-keymod-01">Security Descriptions
Extension for Media Streams</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Sujing Zhou" initials="S.Z." role="editor"
surname="Zhou">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.68 Zijinghua Rd. Yuhuatai District</street>
<!-- Reorder these if your country does things differently -->
<city>Nanjing</city>
<region>Jiang Su</region>
<code>210012</code>
<country>R.R.China</country>
</postal>
<email>zhou.sujing@zte.com.cn</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Tian Tian" initials="T.T." surname="Tian">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.68 Zijinghua Rd. Yuhuatai District</street>
<!-- Reorder these if your country does things differently -->
<city>Nanjing</city>
<region>Jiang Su</region>
<code>210012</code>
<country>P.R.China</country>
</postal>
<phone>+86-025-5287-7867</phone>
<email>tian.tian1@zte.com.cn</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Zhenhua XIe" initials="Z.X" surname="Xie">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.68 Zijinghua Rd. Yuhuatai District</street>
<city>Nanjing</city>
<region>Jiang Su</region>
<code>210012</code>
<country>P.R.China</country>
</postal>
<phone>+86-25-52871287</phone>
<facsimile>+86-25-52871000</facsimile>
<email>xie.zhenhua@zte.com.cn</email>
</address>
</author>
<date day="26" month="March" year="2012"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>Multiparty Multimedia Session Control</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document provides an extension to the cryptographic attribute
(RFC 4568) defined for Session Description Protocol (RFC 4566) to
enhance end-to-end communication security, so that some scenarios, e.g.,
forking and re-targeting can especially benefit from the extension. The
usage of the provided extension in Secure Real-time Transport Protocol
(SRTP, RFC3711) is also defined in this document.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>To ensure the media security established by Session Initiation
Protocol (SIP), SDP Security Descriptions (SDES) is defined in <xref
target="RFC4568">RFC 4568</xref>, where a cryptographic attribute and
application in Secure Real-time Transport Protocol (SRTP,<xref
target="RFC3711">RFC 3711</xref>) unicast media streams are
provided.</t>
<t>SDP Security Descriptions (SDES) is essentially a key transportation
scheme in offer/answer model, in which keying material for the direction
from offerer to answerer is chosen independently by the offerer and
transported in clear text, the keying material for the reverse direction
is also chosen independently by the answerer and transported in clear.
Later the transported keying materials are provided to SRTP protocol to
secure outgoing or incoming media communication. The protection of the
transported keying materials obviously relies on the security of the
signaling protocol which is beyond the scope of this document.</t>
<t>When SDES is applied in some scenarios,e.g., forking and
re-targeting, the intermediate users and devices besides the ultimate
answerer also have knowledge of the keying material used for the
outgoing media from the offerer, which is a security threat to the
content of the end-to-end communication in the affected direction.</t>
<t>To resolve the problem, it is suggested exchanging a new pair of
offer/answer with a new key between the offerer and the ultimate
answerer,i.e., by using SIP UPDATE message<xref target="RFC3311"/>, but
it will require more round trip messages. In this document, a resolution
is introduced based on the defined SDES extension.</t>
<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">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="extension" title="Extension to SDES">
<t/>
<t>Following the ABNF format in Security Descriptions, a new session
parameter extension "keymod" is defined as follows:</t>
<t><figure>
<artwork><![CDATA[srtp-session-extension = keymod
keymod = "keymod:" <keymod-info>
keymod-info = <keymod-type> "|"<kdf-func>"|"<keymod-val>
keymod-type = "rand"/"rand-salt"/keymod-type-ext
keymod-type-ext = 1*(VCHAR)
kdf-func = 1*(ALPHA / DIGIT / "_")
keymod-val = *(base64);base64 encoded binary string
base64 = ALPHA/DIGIT/"+"/"/"/"="
]]></artwork>
</figure>where base64 encoding follows <xref
target="RFC3548">RFC3548</xref>, ALPHA, DIGIT, and VCHAR are defined in
<xref target="RFC4234">RFC4234</xref>.</t>
<t>The defined "keymod" is a negotiated parameter, which indicates it
does not apply to data sent from the answerer to the offerer, as defined
in <xref target="RFC4568">RFC 4568</xref>.</t>
<t>An answer MAY contain keymod value indicating the answerer is asking
for the offerer to refresh its keying material using the information
following it.</t>
<t>If keymod-type is "rand", then only master key is requested to
refresh according to specified function kdf-func;</t>
<t>If keymod-type is "rand-salt", then master key and master salt are
both requested to refresh, the master key will be refreshed according to
specified function kdf-func and the refresh method of master salt is
simply replacement in this document.</t>
<t>The key derivation fumction kdf-func can be as simple as an
assignment(defined as "is" ), or an XOR between the old master key and
the keymod-val value(defined as "xor"), or as complicated as any other
key derivation functions based on cryptographic primitives, e.g., <xref
target="RFC2104">RFC 2104</xref>.</t>
<t>In this document, only the two simple functions are defined:"is" and
"xor", that is</t>
<t><list hangIndent="20" style="hanging">
<t hangText="kdf-func =">"is"/"xor"/kdf-func-ext</t>
<t hangText="kdf-func-ext=">1*(ALPHA / DIGIT / "_")</t>
</list>And if no kdf-func is indicated in keymod-info, the default
kdf-func is "is".</t>
</section>
<section title="Usage of keymod with Offer/Answer ">
<t/>
<section title="Generating the Initial Offer – Unicast Streams">
<t>The generation of the initial offer for a unicast stream MUST
follow that of the crypto attribute <xref
target="RFC4568">RFC4568</xref>, and MAY</t>
<t>also include an additional "keymod" parameter with keymod-val being
NULL. It indicates to the ultimate answerer that the offerer wants to
employ the mechanism specified in</t>
<t>this document, a key agreement mechanism with a higher security
level than the original SDES.</t>
</section>
<section title="Generating the Initial Answer – Unicast Streams">
<t>The generation of the initial answer for a unicast stream MUST
follows that of the crypto attribute <xref
target="RFC4568">RFC4568</xref>, and if the offer message includes a
"keymod" parameter, it SHOULD also include an additional "keymod"
parameter. That is, when an offered crypto attribute is accepted, the
crypto attribute in the answer MUST contain the following:</t>
<t><list style="symbols">
<t>The tag and crypto-suite from the accepted crypto attribute in
the offer (the same crypto-suite MUST be used in the send and
receive direction).</t>
<t>The key(s) the answerer will be using for media sent to the
offerer.</t>
</list></t>
<t>Additionaly the answer MAY contain:</t>
<t><list style="symbols">
<t>The keymod parameter for media sent from the offerer to the
answerer.</t>
</list>The keymod parameter is constrained by the following
limits:</t>
<t><list style="symbols">
<t>If keymod type is "rand", the keymod-val value MUST be at the
minimum length required by the specified crypto-suite for the
master key.</t>
<t>If keymod type is "rand-salt", the keymod-val value length MUST
be no less than the addition of the minimum lengths of master key
and master salt required by the specified crypto-suite.</t>
</list>The keymod parameter and the master key retrieved from the
offer message MAY be used together to derive a new master key used for
the media from the offerer to the answerer.</t>
</section>
<section title="Procesing of the Initial Answer – Unicast Streams">
<t>When the offerer receives the answer, the offerer MUST do necessary
verifications following <xref target="RFC4568">RFC 4568</xref>.</t>
<t>If the answer includes a "keymod" value in "crypto" attribute, the
offerer MUST derive a new master key from the previous master key sent
in the offer message and the keymod-info value received in the answer
message.</t>
<t>Specifically, if the keymod type retrieved from the answer message
is "rand", a new master key will be derived from the previous master
key and the keymode-val value according to specified key derivation
function kdf-func.</t>
<t>If the keymod type retrieved from the answer message is
"rand-salt", a new master key will be derived from the previous master
key and the keymode-val value according to specified key derivation
function kdf-func, and the master salt will be replaced with the salt
value contained in the keymode-val.</t>
<t>The derived new master key and new master salt will be used to
protect the media from the offerer to the answerer.</t>
</section>
</section>
<!-- -->
<section title="Example">
<t>This example shows use of the keymod extension described in this
document. The "a=crypto" line is actually a one long line, which is
shown as two lines due to page formatting.</t>
<t>The following is an offer using crypto attribute indicating deploying
keymod, asking the answerer to return a keymod value :<figure>
<artwork><![CDATA[ v=0
o=alice 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
keymod:rand|xor|
]]></artwork>
</figure></t>
<t>The following is an answer with the keymod extension where type
"rand" is chosen and the refreshment of master key is "xor":</t>
<figure>
<artwork><![CDATA[ v=0
o=Bob 2890844725 2890844725 IN IP4 host.example.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30000 RTP/AVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32;
keymod:rand|xor|WVNfX19zZW1jdGwgKCkgew==]]></artwork>
</figure>
<t/>
<t>The following is an answer with the keymod extension where type
"rand-salt" is chosen and the refreshments of master key and master salt
are both "is":</t>
<t><figure>
<artwork><![CDATA[ v=0
o=Bob 2890844725 2890844725 IN IP4 host.example.org
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 30000 RTP/AVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32;
keymod:rand-salt|WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz]]></artwork>
</figure></t>
</section>
<section title="Applicability in Re-targeting Scenarios">
<t>In this section, applicability of the defined keymod parameter in
re-targeting scenarios is provided.</t>
<t>Re-targeting, or Communications Diversion (CDIV) service is a widely
used communication service which enables a served user to divert the
communications addressed to the served user's address to another
destination according to the specified service type. As define in <xref
target="RFC4458">RFC 4458</xref> and <xref target="TS">3GPP TS 24.604
</xref>, there are several conditions that may incur a CDIV service,
e.g., when the served user is at the statuses of "Not reachable" , "User
busy", "No reply", or the served user has registered with the CDIV Agent
Server (AS) to redirect the call unconditionally.The redirected
destination may be another call number or a voice mailbox of the same
user. CDIV may happen multiple times consecutively till the last
destination, see the example below.</t>
<section title="Single CDIV instance ">
<t>See Figure 1, A initiates a call to B by including a crypto
attribute with a key parameter K1 and an empty KEYMOD1 in the SIP
message. B has subscribed a CDIV service to divert calls to C. When
the diversion condition is met, the call is re-invited by the Proxy or
CDIV AS to C. Proxy sends re-invite SIP message which includes K1,
KEYMOD1 and an additional "cause" value to C (the usage and the
specification of the CAUSE parameter refers to <xref
target="RFC4458">RFC 4458</xref> , then C determines it a CVID call
and responds with a SIP message with a key parameter K2 and a keymod
parameter KEYMOD2. When A receives the SIP message including K2 and
KEYMOD2, A will derive a new key parameter K1' from K1 and KEYMOD2 the
same way as C. Thus the communication between A and C is protected by
K2 and K1', i.e., A uses K1' to protect the media sent from A to C,
and C uses K2 to protect the media sent from C to A.</t>
<t><figure align="center" anchor="example1">
<artwork><![CDATA[A Proxy B C
| | | |
|---INVITE(K1,KEYMOD1)-->| | |
| |---INVITE(K1,KEYMOD1)--->| |
| |------CDIV triggered-----| |
| |---INVITE(K1,CAUSE,KEYMOD1)------>|
| |<--------200 OK(K2,KEYMOD2)-------|
|<----200 OK(K2,KEYMOD2)-| | |
|---------------------------K1'encrypted media------------->|
|<-------------------K2 encrypted media---------------------|
]]></artwork>
</figure></t>
</section>
<section title="Multiple CDIV instances ">
<t>See Figure 2, A initiates a call to B by including a crypto
attribute with a key parameter K1 and an empty KEYMOD1 in the SIP
message. B has subscribed a CDIV service to divert calls to C. When
the diversion condition for B is met, the call is re-invited by the
CDIV AS to C. C has also subscribed a CDIV service to divert calls to
D. When the diversion condition for C is met, the call is re-invited
by the Proxy or CDIV AS to D. Proxy sends re-invite SIP message which
includes K1, KEYMOD1 and an additional "cause" value to D (the usage
and the specification of the CAUSE parameter refers to <xref
target="RFC4458">RFC 4458</xref>, then D determines it a CVID call and
responds with a SIP message with a key parameter K2 and a keymod
parameter KEYMOD2. When A receives the SIP message including K2 and
KEYMOD2, A will derive a new key parameter K1' from K1 and KEYMOD2 the
same way as D. Thus the communication between A and D is protected by
K2 and K1', i.e., A uses K1' to protect the media sent from A to D,
and D uses K2 to protect the media sent from D to A.</t>
<t><figure align="center" anchor="example2">
<artwork><![CDATA[A Proxy B C D
| | | | |
|-INVITE(K1,KEYMOD1)->| | | |
| |---INVITE(K1,KEYMOD1)-->| | |
| |-CDIV triggered---------| | |
| |------INVITE(K1,CAUSE,KEYMOD1)->| |
| |-----CDIV triggered-------------| |
| |--------INVITE(K1,CAUSE,KEYMOD1)------>|
| |<---------200 OK(K2, KEYMOD2)----------|
|<-200 OK(K2,KEYMOD2)-| | | |
|-------------------------K1'encrypted media----------------->|
|<-------------------K2 encrypted media-----------------------|
]]></artwork>
</figure></t>
</section>
<section anchor="comp" title="Computation of K1'">
<t>n the above examples, if key method "inline" is used in key
parameter. K1 consists of a master key msk1 and a master salt mss1, K2
consists of a master key msk2 and a master salt mss2.</t>
<t>If keymod type is "rand", the keymod-val contained in KEYMOD2 is
used to calculate the new master key:</t>
<t>msk1'=kdf-func(keymod-val, msk1)</t>
<t>If keymod type is "rand-salt", the keymod-val contained in KEYMOD2
can be divided into two parts, key and salt, a new master key will be
calculated as:</t>
<t>msk1'=kdf-func(keymod-val(key), msk1)</t>
<t>and a new master salt will be:</t>
<t>mss1'=keymod-val(salt).</t>
</section>
</section>
<section title="Applicability in Forking Scenarios">
<t>In this section, applicability of the defined keymod parameter in
forking scenarios is provided, see the example below.</t>
<t>See Figure 3, A initiates a call to a user U by including a crypto
attribute with a key parameter K1, an empty KEYMOD1 in the SIP message.
And U has multiple devices, e.g., B,C,D, then the call is forked to all
the devices till user U answers the call from D. D responds with a SIP
message with a key parameter K2 and a keymod parameter KEYMOD2. When A
receives the SIP message including K2 and KEYMOD2, A will derive a new
key parameter K1' from K1 and KEYMOD2 the same way as D. Thus the
communication between A and D is protected by K2 and K1', i.e., A uses
K1' to protect the media sent from A to D, and D uses K2 to protect the
media sent from D to A. The computation of K1' is exactly the same as in
<xref target="comp"/></t>
<t><figure align="center" anchor="example3">
<artwork><![CDATA[ A Proxy B C D
| | | | |
|-INVITE(K1,KEYMOD1)->| | | |
| |--INVITE(K1,KEYMOD1)-->| | |
| |-----INVITE(K1,KEYMOD1)------>| |
| |--------INVITE(K1,KEYMOD1)---------->|
| |<------200 OK(K2, KEYMOD2)-----------|
|<-200 OK(K2,KEYMOD2)-| | | |
|------------------------K1'encrypted media---------------->|
|<------------K2 encrypted media----------------------------|
]]></artwork>
</figure></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document includes an extension to the crypto attribute defined
in<xref target="RFC4568"> RFC 4568</xref>, so the security
considerations are mostly the same, except that the described solution
improves a security drawback when <xref target="RFC4568">RFC 4568</xref>
is applied in some specific scenarios, i.e., forking and
re-targeting.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include='reference.RFC.3548.xml'?>
<?rfc include='reference.RFC.3711.xml'?>
<?rfc include='reference.RFC.4568.xml'?>
<?rfc include='reference.RFC.2119.xml'
?>
<?rfc include='reference.RFC.4566.xml'
?>
<?rfc include='reference.RFC.4234.xml'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.4458.xml'?>
<?rfc include='reference.RFC.2104.xml'
?>
<?rfc include='reference.RFC.3311.xml'?>
<reference anchor="TS">
<front>
<title>3GPP TS 24.604 Communication Diversion (CDIV) using IP
Multimedia (IM) Core Network (CN) subsystem; Protocol
specification</title>
<author fullname="3GPP">
<organization/>
</author>
<date/>
</front>
</reference>
</references>
<!-- -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:21:54 |