Subject: [SIP] Key agreement using SIP/SDP?

From: Anders Clausen <[email-masked]>
Date: Mon, 10 Apr 2000 15:08:35 +0200

Hello,

We are two students writing on a graduate thesis about VoIP security
with SIP/SDP/RTP, with focus on encrypting the media stream. We are
new to this, and would be grateful for help on this subject.

There are some problems transferring or agreeing on a session
encryption key using the k= field in SDP, if one are to send it in a
SIP INVITE through a NAT. Since the NAT needs to change some fields in
the SDP description, the SDP must not be encrypted.

The end user should be oblivious of the FW/NAT and thus should neither
query it for the adresses to enter into the SDP, nor depend on the FW
to encrypt anything.

A couple of possible solutions (?).

The simplest (and least secure) way to transfer a symmetric key would
be that the caller enters his public key (or Diffie-Hellman "A") into
the k= field of the SDP.

"k=base64:<caller key>"

together with a couple of attributes that could look something like

"a=key-encr-alg:RSA"
or
"a=key-encr-alg:D-H"

for describing the algorithm the key in the k= field corresponds to,
and

"a=media-encr-alg:3DES-CBC"

for describing preferred media encryption algorithm.

In case of RSA, the "callers key" is the public key, corresponding to
a private key only known by him. In case of Diffie-Hellman the
"callers key" is the "A"-part of the partly built media key.

The callee then generates a "callee key". In case of RSA, this is the
symmetric media key, encrypted using the callers public key. In case
of Diffie-Hellman, the "callee key" is the "B"-part of the partly
built symmetric media key. The callee sends this back in the k= field
in the SDP of the 180 response. Should the callee fail to meet the
specific security wishes of the caller, it could simply omit the k=
field in the response, and the caller could choose to proceed and not
encrypt the media or just hang up.

  CALLER		          SIP-PROXY(s)                   CALLEE
    |                           |                           |
    | INVITE w/SDP(caller's key)|                           |
    |-------------------------->| INVITE w/SDP(caller's key)|
    |                           |-------------------------->|
    |                           |                           |
    |                           |   100                     |
    |   100                     |<--------------------------|
    |<--------------------------|                      Key generation
    |                           |   180 w/SDP(callee's key) |
    |   180 w/SDP(callee's key) |<--------------------------|
    |<--------------------------|                           |

Another way could be to insert something similar to a TLS handshake
(or some other more secure way of agreeing on or transferring keys)
into the Reservation stage in the QoS/security negotiation described
in draft-manyfolks-sip-resource-00.txt.

This would probably also need a couple of attributes to tell the
callee which handshake protocol should be used.

Comments?

(After reading RFC 1889 (RTP), 1890 (AVP), 2327 (SDP), 2543 (SIP), and a
number of drafts, we have not found any solutions to the problems
described above.)

---
Anders Clausen <[email-masked]>
Thomas Karlsson <[email-masked]>

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Lars Berggren <[email-masked]>
Date: Mon, 17 Apr 2000 11:23:39 +0200 (CEST)

Anders and Thomas,

I am cc-ing this to the mmusic list since SDP is involved here.

First, I would say that you probably shouldn't say that it is the 180
response that contains the key agreement information, as I think that any 
response containing SDP is likely to be suitable. (183 and 200)

Second, I like the mechanism described here regarding agreement on keys
for RTP level encryption. However, as there has been no responses in this
thread from the WG, I would like to bring attention from the WG to this
topic again, hoping for more interest this time.

Does anyone else have comments on this? I really would like to see some
more discussion in this topic. What about the SIP security team, any
thoughts in this direction?

How about writing an ID on this to specify it clearer?

The advantages I can see with the proposal are:
1) Works through NATs.
2) It could be made generic. I believe any need for negotiation between
caller and callee when agreeing on a session key or shared secret (like 
diffie-hellman) could be signaled this way.
3) No need to rely on an infra-structure for fetching of public keys.

Disadvantages:
1) Another extension to SIP/SDP ?
2) The same key is used in the streams caller->callee and 
callee->caller. There may be applications that need to have different
keys in each stream.

Regards
Lars

>     |-------------------------->| INVITE w/SDP(caller's key)|

Lars Berggren       <mailto:[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 Apr 2000 23:45:21 -0400

My general feeling is queasiness. Security protocols are hard to get
right. In general, wherever possible, I would prefer to use a real,
established, tested, and understood security protocol rather than try to
add one into SIP itself. In this case, we have numerous key exchange
protocols at our disposal, including IKE and kerberos. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com