One document matched: draft-jain-sipping-srtp-00.txt

INTERNET DRAFT                                    Kavita Jain
Category: Informational                           Mitel Networks
Title: draft-jain-sipping-srtp-00.txt                 John Albert                      
Date: August 2003 				  Mitel Networks
						  February, 2004

		         Using SRTP with SIP                                            


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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 in February, 2004.


Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


Conventions Used In This Document

   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 BCP 14, RFC 2119
   [KEYWORD].



Abstract

   The Secured Real Time Protocol (SRTP) is a lightweight protocol that 
   secures voice data between two end points. The Session Initiation Protocol 
   (SIP) is a simple and adaptive session-controlling protocol. Efforts have 
   been underway to get these two protocols working together. Several ideas 
   have been presented in different documents in past. This document describes 
   one more way to accomplish this task. The proposed approach is simple and 
   does not consume too much CPU cycles. However, some assumptions need to be 
   made in lack of the specific SIP and SDP fields.

1 Introduction

   In order to secure voice data using SRTP[1], peers exchange SRTP parameters 
   during call establishment. The most important parameter is 
   encryption/decryption key. The key must be secured and correct. If SIP[2] 
   is being used to establish the session, the key needs to be exchanged in SIP 
   messages. This document first addresses the issues involved and then explains 
   the assumptions that need to be made. This is being followed by the detail of 
   how the proposed way exploits the currently available SIP/SDP[3] fields to 
   accomplish the task. 

2 Issues

   Currently, SIP message does not have a field to transport a key to 
   encrypt/decrypt media. The SDP payload of a SIP message provides the ôkö field 
   to exchange the keys for the media. However, the content of the ôkö field can 
   be either clear text, or encrypted with Basic encryption. Another approach is 
   to store the key at a secured website and send the web site URL in the ôkö 
   field. The latter approach is a secured one, but it has the following 
   disadvantages:
	a) A lengthy process of obtaining a key
	b) Maintenance of keys at the website 
	c) Maintenance of the website itself 

   Therefore, the proposed idea to exchange keys suggests sending keys in the ôkö 
   field of the SDP payload in clear text. The key can be Basic encrypted. 

3 Assumptions

   In lack of the specific SIP and SDP fields, the following assumptions need to 
   be made:
  	a) The key is a 64-bit Diffie-Hellmann (DH) [4] key
	b) Encryption/decryption algorithm is DES [5]
	c) The Initiation Vector (IV) can be derived by performing a bit-wise 
           operation (say OR or XOR) between the public part of the key and a default 
           IV mask. Or it can have a default value 
	d) The prime number to generate a DH key has a default value
	e) The ôbaseö number to generate the DH key has a default value
    NOTE: These assumptions can later be defined as the default values of the fields, 
    once fields are being defined. 

4 The Proposed Approach

   The basic idea is that the public part of a DH key can be exchanged safely in 
   clear text using the ôkö field in SDP payload of a SIP message. Before sending an 
   INVITE message, the caller will generate its DH key. The caller would send its 
   public key in the SDP payload of the INVITE SIP message so that the callee would 
   know that the caller has SRTP capability. The callee will generate its own DH key 
   and will send its public key in its own SDP payload in the ô200 OKö SIP message. 
   Now, each peer will have an ôownö key that it itself has generated and a ôpeerö key 
   that it has received from the peer. With these two kinds of keys, the two ends will 
   calculate the ôSRTPö key to encrypt and decrypt the voice data. Each side will 
   calculate its encryption/decryption IV by performing a bit-wise operation between 
   the IV mask and ôownö/ôpeerö public key, respectively. 


   The DES algorithm will be configured with the ôSRTPö key and the encryption/decryption 
   IVs. DES algorithm can be run on voice data either in hardware or software.

 
   An SRTP connection will be in affect only if both parties send their keys. Otherwise, 
   it will be assumed that the peer does not support SRTP and voice data will not be 
   encrypted. 
	
5 References

    [1]	Baugher, M., Carrara, E., McGrew, D. A., Nausland, M., and Norrman, K. "The Secure 
        Real-time Transport Protocol" IETF, Work in Progress.

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

    [3] Handley, M. and Jacobson, V,. "SDP: Session Description Protocol", RFC 2327, April 1998.

    [4] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.

    [5] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977).     

6 Acknowledgements

    The authors would like to thank Lee Dilkie and Mark Baugher for sharing their expert thoughts 
    and knowledge. 

7 Authors' Addresses

    Kavita Jain
    Mitel Networks
    350 Legget Drive
    Kanata, ON
    Canada, K2K 2X3

     phone:	+1 613-592-2122
    E-mail:      kavita_jain@mitel.com

    John Albert
    Mitel Networks
    350 Legget Drive
    Kanata, ON
    Canada, K2K 2X3

     Phone:	+1 613-592-2122
    E-mail:     john_albert@mitel.com

8  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this docu-
   ment itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as
   required to translate it into languages other than English. The lim-
   ited permissions granted above are perpetual and will not be revoked
   by the Internet Society or its successors or assigns. This document
   and the information contained herein is provided on an "AS IS" basis
   and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
   CLAIMS 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.


9  Expiration Date

   This memo is filed as <draft-ietf-sip-srtp-00.txt> and expires in
   February, 2004.