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.