Shyam Pallapothu
Internet-Draft Sunil Mahajan
Expires: Aug 19, 2007 ARICENT
Feb 19, 2007

Selective Encryption Support in SRTP
draft-smahajan-srtp-selective-encryption-01.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

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

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on Aug 19, 2007.

Abstract

Selective Encryption is good mechanism to improve performance of
devices that support media encode/decode and transport and still
meets basic requirement of confidentiality. SRTP is one of the
popular mechanism used to support confidential media transport over
IP channels. This draft suggests some enhancements to SRTP protocol
management to enable SRTP to support "Selective Encryption".

Sunil Mahajan Expires Aug 19, 2007 [Page 1]

Internet-Draft SRTP Selective Encryption Aug 2007

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Selective Encryption in SRTP . . . . . . . . . . . . . . . . 5
2.1 Method-1 -> MKI overloading . . . . . . . . . . . . . . . . 5
2.1.Security Context . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2.Key Exchange Protocol . . . . . . . . . . . . . . . . . . 6
2.2 Method-2 -> Additional Paremeter in SRTP . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . 8
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . 10

Sunil Mahajan Expires Aug 19, 2007 [Page 2]

Internet-Draft SRTP Selective Encryption Aug 2007

1. Introduction

It is clearly understood that to support media transport over IP
networks transport protocols would need to support confidentiality
and integrity of data, as these transports are typically shared
access media for multiple users and are open to different kind of
security attacks, unlike traditional PSTN networks where access and
network transport is inherently and physically secured from malicious
use. To support such requirements media transport shall provide
mechanisms to encrypt and protect integrity of the user data. To
achieve such requirements SRTP protocol is proposed to be used which
is another profile of RTP protocol. SRTP provides all the required
features for media communication over insecure and shared IP
networks.

However since most of these media communications originate from
handheld devices like mobile phones or even fixed phones, processing
power requirements at these devices to encrypt the complete media
stream also increases which poses its own challenges. To avoid high
processing requirements at these devices "Selective Encryption"
techniques can be used.

Also for network devices which originate or terminate large number of
media streams, processing power required to encrypt each media stream
will contribute a large amount of CPU and memory requirements for
these devices and increases their cost.

Selective Encryption:
It is a method where part of the media stream is encrypted and other
part is left unencrypted. There are 2 criterions which can be used to
decide which parts of the media stream shall be encrypted and what
parts can be left unencrypted.

Scheme-1:
This scheme depends on the mix of media available during a media
based communication. In such communications there are generally more
than one media contents mixed and their security requirements are
also different. One media component requires high security, whereas
other component might require less or no encryption at all. Such
media streams can exploit selective encryption schemes to get
benefits both on network devices and on user devices.

Example of such media communications include 1) A video broadcast of
a football match where contents of live match are encrypted and all
the intermediate advertisement contents need not be encrypted. 2) A
user while interacting with an IVR application would need his

Sunil Mahajan Expires Aug 19, 2007 [Page 3]

Internet-Draft SRTP Selective Encryption Aug 2007

communication with operator and any data that he supplies to system
to be encrypted whereas all the recorded announcements need not be
encrypted.

Scheme-2:
Unencrypted parts are such components of the media stream which can
not be used by any kind of attacker to create original stream. Either
the processing power required to created original stream is very very
high or time needed is very large. Such schemes might have different
level of security available to overall scheme dependig upon how
unencrypted components are chosen. An application developer can
choose level of security needed and hence the components to be used
for unencrypted parts.

Examples of such scheme include that the parts to be encrypted
depends on the type of media and compression schemes used for media
transport. It is required that sufficient information is encrypted so
that any evesdroper should not be able to reconstruct the complete
stream. E.g. for video transport, I frames are encrypted and others
are sent in un-encrypted format. However it should be well understood
by the application developer that the type of scheme used will
determine level of security for the media stream.

Some of the examples where level of security requirements is less
are - 1) VoIP communication within enterprise environment, 2) Free
VoIP Calls offered by internet service providers etc.
Please note that by using such schemes, security or confidentiality
does not go away completely but it is less as compared to full
encryption support. However people expert on security can determine
more appropriate method of choosing unencrypted components to make
selective encryption relatively more secure.

There are various research papers published on the benefits of
Selective Encryption but still there are differing opinions on
the usefulness of selective encryption. However the biggest benefit
for IP based communication from handheld devices point of view is low
processing power requirements and this is a good enough benefit for
selective encryption to be considered. For network nodes which
process large number of encrypted media streams, selective encryption
can play an important role there too.

Use of selective encryption shall be optional to the user and device
and for critical projecs or communication needs where confidentiality
is of prime importance, it shall not be used, however for other form
of normal communication needs, it can be used.

Current definition of SRTP protocol does not support selective

Sunil Mahajan Expires Aug 19, 2007 [Page 4]

Internet-Draft SRTP Selective Encryption Aug 2007

encryption. This draft proposes a method using which selective
encryption can be supported. There are 2 ways to add support for
selective encryption in SRTP 1) without changing the syntax of the
protocol 2) Adding explicit support for selective encryption in SRTP
protocol. This draft proposes both the methods and leaves it to
working group to decide which is a better method.

2. Selective Encryption in SRTP

Basic requirement in selective encryption is to encrypt some media
packets and not encrypt some other. This requires that every packet
shall carry an indicator which indicates whether packet is encrypted
or not. This does not interfere with other security requirements,
like message integrity or authentication of source etc.
The first proposed method is based on MKI parameter overloading and
second method is based on adding additional parameter to SRTP.

2.1 Method-1 -> MKI overloading
SRTP uses a parameter called MKI (Master Key Index) which is an
optional parameter in every SRTP packet and indicates the index of
the master key in use.

Current definition of SRTP protocol defines security context at both
the ends of the communication which is established using other(other
than SRTP)mechanisms and also creates Master Key. Master key is used
to create session keys for encryption and integrity. SRTP allows
multiple Master Keys to be used to provide enhanced security features
where Master Key can be changed during media communication over SRTP
by indicating different MKI value in the SRTP stream.

Current definition of SRTP does not include encryption (cipher)
algorithm to be part of Master Key Index, so basically while
establishing security context at both ends of the communication,
cipher algorithm is negotiated and multiple master keys are
established and all the keys uses same cipher suite.

SRTP also allows NULL encryption to be supported as valid cipher
algorithm.

If we change SRTP definition by linking encryption algorithm to the
Master Key and each Master Key can hold its own cipher algorithms,
SRTP can support selective encryption without changing protocol
syntax.

In order to support selective encryption between two endpoints,

Sunil Mahajan Expires Aug 19, 2007 [Page 5]

Internet-Draft SRTP Selective Encryption Aug 2007

security context establishment shall establish at least two master
keys (which means two MKI values as well) and one of the master key
carries a cipher algorithm and other one uses NULL Cipher. During RTP packet processing by SRTP stack, if encryption for that packet is
needed, MKI value will be set to the one that has cipher algorithm
attached and if encryption is not needed, MKI value will be set to
one that has NULL Cipher.

2.1.1 Security Context

Security context at each endpoint will change as per this new
definition.

Key material params
(for each master key):
SRTP and SRTCP encr transf. AES_CM/NULL AES_CM
master key length 128 128
n_e (encr session key length) 128 128
n_a (auth session key length) 160 160
master salt key
length of the master salt 112 112
n_s (session salt key length) 112 112
key derivation rate 0 0

key lifetime
SRTP-packets-max-lifetime 2^48 2^48
SRTCP-packets-max-lifetime 2^31 2^31
from-to-lifetime <From, To>
MKI indicator 0 0
length of the MKI 0 0
value of the MKI

Above table is modified table from RFC3711 section 8.2.

2.1.2 Key exchange protocol

This new definition of SRTP protocol will also require changes to key
exchange protocols like RFC4568 (Security Descriptions for Media
Streams). For example crypto parameter as per RFC4568 shall be part
of key definition.

Following example is only suggestive and does not define the required
syntax. (example is taken from RFC4568 section 7.1.5.)

Sunil Mahajan Expires Aug 19, 2007 [Page 6]

Internet-Draft SRTP Selective Encryption Aug 2007

v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
crypto:1 AES_CM_128_HMAC_SHA1_80
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
FEC_ORDER=FEC_SRTP

For two endpoints agreeing to use selective encryption, one of the
key parameter shall carry NULL Cipher and NULL key.

2.2 Method-2 -> Additional Paremeter in SRTP

In this proposal there is an explicit parameter in each SRTP packet
which indicates whether the payload is encrypted or not. This
parameter is optional and the presence is indicated during key
exchange by using the same mechanism as used for the presence of
MKI paremeter in the payload. So if a particular communication does
not require selective encryption, this parameter will not be present
in SRTP packet. If selective encryption is used this parameter can
be used to indicate whether packet is encrypted or not.

Sunil Mahajan Expires Aug 19, 2007 [Page 7]

Internet-Draft SRTP Selective Encryption Aug 2007

Extension to SRTP is shown below:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | |
| .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RTP extension (OPTIONAL) | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |E| FOR FUTURE EXTENSIONS | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+- Encrypted Portion* Authenticated Portion ---+

E bit in the extension parameter will determine whether encryption
is on or not. E=1 -> Encrypted, E=0 -> Not Encrypted

3. Security Considerations

Selective Encryption with SRTP is an optional feature of SRTP and
shall be used only if participating end points agree to use it.

Algorithm to do selective encryption will determine effectiveness of
this mechanism and overall security of the media.

It should be well understood by all application developers who wish
to use selective encryption that full encryption is always more
secure than selective encryption - so only if developers see
benefits of selective encryption compelling, they should opt for
selective encryption. Scheme-1 defined in the draft requires the

Sunil Mahajan Expires Aug 19, 2007 [Page 8]

Internet-Draft SRTP Selective Encryption Aug 2007

application developer to clearly categorize the contents into 2
types, one which definitely requires encryption and other which can
be seen as unencrypted contents by the users. For scheme-2
application developer would need to understand the coding or
compression type clearly and evaluate the selective encryption
mechanism only if either the security requirements are not very
critical or developer is sure about the method used for determining
the unencrypted contents will not compromise the security of overall
contents.

4. Acknowledgements

Thanks to Armstrong M and Senthil Gurusamy for fruitful discussions
and inputs. Authors would like to acknowledge the contribution of
all the members of working group for their useful comments and
critical review of previous version of the draft.

5. References

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, 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.

[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol Security Descriptions for Media
Streams",

Sunil Mahajan Expires Aug 19, 2007 [Page 9]

Internet-Draft SRTP Selective Encryption Aug 2007

Authors' Addresses

Sunil Mahajan
Aricent
Plot#31, Sector 18, Electronic City
Gurgaon, Haryana
INDIA

Phone: +91-124-2346666
Email: sunil.mahajan@arcient.com

Shyam SBK Gupta Pallapothu
Aricent
9th Floor, Gamma Block, Sigma Soft Tech park,
Varthur, Bangalore, Karnataka,
INDIA

Email: shyam.pallapothu@aricent.com

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Sunil Mahajan Expires Aug 19, 2007 [Page 10]

Internet-Draft SRTP Selective Encryption Aug 2007

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The IETF Trust (2007). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Sunil Mahajan Expires Aug 19, 2007 [Page 11]