Internet DRAFT - draft-zhou-mmusic-sdes-keymod
draft-zhou-mmusic-sdes-keymod
Multiparty Multimedia Session Control S. Zhou, Ed.
Internet-Draft T. Tian
Intended status: Standards Track Z. Xie
Expires: September 27, 2012 ZTE Corporation
March 26, 2012
Security Descriptions Extension for Media Streams
draft-zhou-mmusic-sdes-keymod-01
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 27, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Zhou, et al. Expires September 27, 2012 [Page 1]
Internet-Draft draft-zhou-mmusic-sdes-keymod-01 March 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Extension to SDES . . . . . . . . . . . . . . . . . . . . . . 3
3. Usage of keymod with Offer/Answer . . . . . . . . . . . . . . 4
3.1. Generating the Initial Offer - Unicast Streams . . . . . . 5
3.2. Generating the Initial Answer - Unicast Streams . . . . . 5
3.3. Procesing of the Initial Answer - Unicast Streams . . . . 6
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Applicability in Re-targeting Scenarios . . . . . . . . . . . 7
5.1. Single CDIV instance . . . . . . . . . . . . . . . . . . . 7
5.2. Multiple CDIV instances . . . . . . . . . . . . . . . . . 8
5.3. Computation of K1' . . . . . . . . . . . . . . . . . . . . 9
6. Applicability in Forking Scenarios . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zhou, et al. Expires September 27, 2012 [Page 2]
Internet-Draft draft-zhou-mmusic-sdes-keymod-01 March 2012
1. Introduction
To ensure the media security established by Session Initiation
Protocol (SIP), SDP Security Descriptions (SDES) is defined in RFC
4568 [RFC4568], where a cryptographic attribute and application in
Secure Real-time Transport Protocol (SRTP,RFC 3711 [RFC3711]) unicast
media streams are provided.
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.
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.
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[RFC3311], but it will
require more round trip messages. In this document, a resolution is
introduced based on the defined SDES extension.
1.1. Terminology
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 RFC 2119 [RFC2119].
2. Extension to SDES
Following the ABNF format in Security Descriptions, a new session
parameter extension "keymod" is defined as follows:
Zhou, et al. Expires September 27, 2012 [Page 3]
Internet-Draft draft-zhou-mmusic-sdes-keymod-01 March 2012
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/"+"/"/"/"="
where base64 encoding follows RFC3548 [RFC3548], ALPHA, DIGIT, and
VCHAR are defined in RFC4234 [RFC4234].
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 RFC 4568 [RFC4568].
An answer MAY contain keymod value indicating the answerer is asking
for the offerer to refresh its keying material using the information
following it.
If keymod-type is "rand", then only master key is requested to
refresh according to specified function kdf-func;
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.
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., RFC 2104 [RFC2104].
In this document, only the two simple functions are defined:"is" and
"xor", that is
kdf-func = "is"/"xor"/kdf-func-ext
kdf-func-ext= 1*(ALPHA / DIGIT / "_")
And if no kdf-func is indicated in keymod-info, the default kdf-func
is "is".
3. Usage of keymod with Offer/Answer
Zhou, et al. Expires September 27, 2012 [Page 4]
Internet-Draft draft-zhou-mmusic-sdes-keymod-01 March 2012
3.1. Generating the Initial Offer - Unicast Streams
The generation of the initial offer for a unicast stream MUST follow
that of the crypto attribute RFC4568 [RFC4568], and MAY
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
this document, a key agreement mechanism with a higher security level
than the original SDES.
3.2. Generating the Initial Answer - Unicast Streams
The generation of the initial answer for a unicast stream MUST
follows that of the crypto attribute RFC4568 [RFC4568], 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:
o 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).
o The key(s) the answerer will be using for media sent to the
offerer.
Additionaly the answer MAY contain:
o The keymod parameter for media sent from the offerer to the
answerer.
The keymod parameter is constrained by the following limits:
o 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.
o 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.
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.
Zhou, et al. Expires September 27, 2012 [Page 5]
Internet-Draft draft-zhou-mmusic-sdes-keymod-01 March 2012
3.3. Procesing of the Initial Answer - Unicast Streams
When the offerer receives the answer, the offerer MUST do necessary
verifications following RFC 4568 [RFC4568].
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.
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.
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.
The derived new master key and new master salt will be used to
protect the media from the offerer to the answerer.
4. Example
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.
The following is an offer using crypto attribute indicating deploying
keymod, asking the answerer to return a keymod value :
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|
The following is an answer with the keymod extension where type
"rand" is chosen and the refreshment of master key is "xor":
Zhou, et al. Expires September 27, 2012 [Page 6]
Internet-Draft draft-zhou-mmusic-sdes-keymod-01 March 2012
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==
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":
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
5. Applicability in Re-targeting Scenarios
In this section, applicability of the defined keymod parameter in re-
targeting scenarios is provided.
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
RFC 4458 [RFC4458] and 3GPP TS 24.604 [TS], 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.
5.1. Single CDIV instance
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
Zhou, et al. Expires September 27, 2012 [Page 7]
Internet-Draft draft-zhou-mmusic-sdes-keymod-01 March 2012
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 RFC 4458 [RFC4458] ,
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.
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---------------------|
Figure 1
5.2. Multiple CDIV instances
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 RFC 4458
[RFC4458], 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.
Zhou, et al. Expires September 27, 2012 [Page 8]
Internet-Draft draft-zhou-mmusic-sdes-keymod-01 March 2012
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-----------------------|
Figure 2
5.3. Computation of K1'
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.
If keymod type is "rand", the keymod-val contained in KEYMOD2 is used
to calculate the new master key:
msk1'=kdf-func(keymod-val, msk1)
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:
msk1'=kdf-func(keymod-val(key), msk1)
and a new master salt will be:
mss1'=keymod-val(salt).
6. Applicability in Forking Scenarios
In this section, applicability of the defined keymod parameter in
forking scenarios is provided, see the example below.
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
Zhou, et al. Expires September 27, 2012 [Page 9]
Internet-Draft draft-zhou-mmusic-sdes-keymod-01 March 2012
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 Section 5.3
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----------------------------|
Figure 3
7. IANA Considerations
This document includes no request to IANA.
8. Security Considerations
This document includes an extension to the crypto attribute defined
inRFC 4568 [RFC4568], so the security considerations are mostly the
same, except that the described solution improves a security drawback
when RFC 4568 [RFC4568] is applied in some specific scenarios, i.e.,
forking and re-targeting.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
Zhou, et al. Expires September 27, 2012 [Page 10]
Internet-Draft draft-zhou-mmusic-sdes-keymod-01 March 2012
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006.
9.2. Informative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Initiation Protocol (SIP) URIs for Applications such as
Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006.
[TS] "3GPP TS 24.604 Communication Diversion (CDIV) using IP
Multimedia (IM) Core Network (CN) subsystem; Protocol
specification".
Authors' Addresses
Sujing Zhou (editor)
ZTE Corporation
No.68 Zijinghua Rd. Yuhuatai District
Nanjing, Jiang Su 210012
R.R.China
Email: zhou.sujing@zte.com.cn
Zhou, et al. Expires September 27, 2012 [Page 11]
Internet-Draft draft-zhou-mmusic-sdes-keymod-01 March 2012
Tian Tian
ZTE Corporation
No.68 Zijinghua Rd. Yuhuatai District
Nanjing, Jiang Su 210012
P.R.China
Phone: +86-025-5287-7867
Email: tian.tian1@zte.com.cn
Zhenhua XIe
ZTE Corporation
No.68 Zijinghua Rd. Yuhuatai District
Nanjing, Jiang Su 210012
P.R.China
Phone: +86-25-52871287
Fax: +86-25-52871000
Email: xie.zhenhua@zte.com.cn
Zhou, et al. Expires September 27, 2012 [Page 12]
