Security Descriptions Extension for Media Streams
draft-zhou-mmusic-sdes-keymod-00

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 in scenarios, e.g., forking and re-targeting. 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 August 01, 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Terminology
• 2. Extension to SDES
• 3. Usage of keymod with Offer/Answer
• 3.1. Generating the Initial Offer – Unicast Streams
• 3.2. Generating the Initial Answer – Unicast Streams
• 3.3. Procesing of the Initial Answer – Unicast Streams
• 4. Example
• 5. Applicability in Re-targeting Scenarios
• 5.1. Single CDIV instance
• 5.2. Multiple CDIV instances
• 6. Applicability in Forking Scenarios
• 7. IANA Considerations
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

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:

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               = 1*(base64);base64 encoded binary string
base64                   = ALPHA/DIGIT/"+"/"/"/"="

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

3.1. Generating the Initial Offer – Unicast Streams

The generation of the initial offer for a unicast stream is unchanged compared with that of the crypto attribute RFC4568 [RFC4568].

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 MAY 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:

• 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).
• The key(s) the answerer will be using for media sent to the offerer.

Additionaly the answer MAY contain:

• The keymod parameter for media sent from the offerer to the answerer.

The keymod parameter is constrained by the following limits:

• 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.
• 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.

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 MUSTl 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.

   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

The following is an usual offer using crypto attribute:

The following is an answer with the keymod extension where type "rand" is chosen and the refreshment of master key is "xor":

   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 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 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. When A receives the SIP message including K2 and keymod, A will derive a new key parameter K1' from K1 and keymod 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)------>|                |        |
|                    |---NVITE(K1)--->|        | 
|                    |-CDIV triggered-|        |
|                    |---INVITE(K1,CAUSE)----->|   
|                    |<---200 OK(K2,KEYMOD)----|
|<-200 OK(K2,KEYMOD)-|                |        |
|---------------K1'encrypted media------------>|
|<-------------------K2 encrypted media--------|     

5.2. Multiple CDIV instances

See Figure 2, A initiates a call to B by including a crypto attribute with a key parameter K1 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 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 keymod. When A receives the SIP message including K2 and keymod, A will derive a new key parameter K1' from K1 and keymod 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.

A                  Proxy              B       C      D 
|                    |                |       |      | 
|----INVITE(K1)----->|                |       |      |
|                    |---INVITE(K1)-->|       |      |
|                    |-CDIV triggered-|       |      |
|                    |------INVITE(K1,CAUSE)->|      |
|                    |-----CDIV triggered-----|      |
|                    |--------INVITE(K1,CAUSE)------>|
|                    |<---------200 OK(K2, KEYMOD)---|     
|<-200 OK(K2,KEYMOD)-|                |       |      | 
|------------------K1'encrypted media--------------->|
|<-------------------K2 encrypted media--------------|

If keymod type is "rand", the keymod-val contained in KEYMOD 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 KEYMOD 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 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 keymod. When A receives the SIP message including K2 and keymod, A will derive a new key parameter K1' from K1 and keymod 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.

 A                  Proxy             B      C      D 
 |                    |               |      |      | 
 |----INVITE(K1)----->|               |      |      |
 |                    |--INVITE(K1)-->|      |      |
 |                    |-----INVITE(K1)------>|      |
 |                    |--------INVITE(K1)---------->|
 |                    |<------200 OK(K2, KEYMOD)----|     
 |<-200 OK(K2,KEYMOD)-|               |      |      |
 |---------------K1'encrypted media---------------->|
 |<-------------------K2 encrypted media------------|

If keymod type is "rand", the keymod-val contained in KEYMOD 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 KEYMOD 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).

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

9.2. Informative References

Authors' Addresses