Subject: SIP security

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 31 Jan 1998 14:45:01 -0500

One of the last remaining items for progressing "basic SIP" is
end-to-end security.

Some observations:

(1) We should re-use existing security implementations as much as
possible. SIP server and client writers shouldn't have to write
encryption code or deal with key management. Thus, I'd like to be able
to call up PGP and MIME implementation and just use the return values.
Makes it far more likely that anybody actually implements security.

(2) Proxies need to be able to read certain SIP header fields, including
the possibly sensitive From and To fields. To protect these "on the
wire", hop-by-hop encryption is necessary, but only TCP provides that in
the form of SSL/TLS. We can either rely on IPsec or define our own UDP
"security envelope" for this. One possibility is to define a SEALED
method; following the conventions of RFC 2015 (and the S/MIME spec):

SEALED <name of public key owner at next hop> SIP/2.0
Content-Type: multipart/encrypted; boundary=foo;
  protocol="application/pgp-encrypted"

--foo
Content-Type: application/pgp-encrypted

Version: 1

--foo
Content-Type: application/octet-stream

     -----BEGIN PGP MESSAGE-----
     Version: 2.6.2

     hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
     eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
     g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
     AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
     1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
     =zzaA
     -----END PGP MESSAGE-----

--foo--

The PGP message would be the complete SIP message, encrypted with the
public key of the proxy or next hop. Similar techniques would apply to
signed and encrypted + signed messages.

(3) Unlike PGP-over-MIME and S/MIME, we don't have to use "ASCII armor",
as we have an 8-bit clear channel. Doesn't change anything major, except
possibly an additional parameter on the Content-Type. Given argument
(1), we should, I believe, allow ASCII armor.

(4) Not all proxies can do encryption and we don't want to trust them
completely, so end-to-end encryption is still useful. One possible way
would be

     INVITE [email-masked] SIP/2.0
     From: Michael Elkins <[email-masked]>
     To: J.Doe <[email-masked]>
     Mime-Version: 1.0
     Call-ID: 458686
     Content-Type: multipart/encrypted; boundary=foo;
        protocol="application/pgp-encrypted"

     --foo
     Content-Type: application/pgp-encrypted

     Version: 1

     --foo
     Content-Type: application/octet-stream

     -----BEGIN PGP MESSAGE-----
     Version: 2.6.2

     hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
     eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
     g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
     AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
     1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
     =zzaA
     -----END PGP MESSAGE-----

     --foo--

With an address size of 35, the typical unencrypted part is 160 bytes
long. Two choices: either we concatenate the unencrypted and encrypted
parts to form the "real" SIP message (with encrypted headers overriding
unencrytped ones) or we ditch the unencrypted parts. The latter has the
advantage that it avoids easy additions by proxies such as

     INVITE [email-masked] SIP/2.0
     From: Michael Elkins <[email-masked]>
     To: J.Doe <[email-masked]>
     Subject: You are a complete idiot
     Mime-Version: 1.0
     Call-ID: 458686
     Content-Type: multipart/encrypted; boundary=foo;
        protocol="application/pgp-encrypted"

in the hope that the encrypted/signed version doesn't have a Subject
field to override this. (This could be particularly nasty with
call-control directives. We would have to somehow convey to the user
that only part of the message was authenticated and then ask which parts
to trust and act on. I'd much rather have a configuration that says
"don't answer unauthenticated calls".)

PGP has the advantage that it compresses text before encryption, so that
the overall penalty for encryption is probably still small or maybe even
a gain. Thus, I'd suggest that the receiver only look at the
encrypted/signed parts and ditch the rest.

(5) We could develop our own Encryption and Authentication headers to
put the PGP/S-MIME related data, but given available practice, I'm not
convinced that we want to be in the business of tracking every security
proposal. The MIME multipart stuff is a bit hairy, but not that painful.

(6) It might be possible to hide Via fields, but I'm having a hard time
convincing myself that they reveal anything more interesting than the
To/From fields, which all proxies need to see. Hiding Via fields gets
rather messy if done securely.

Comments are appreciated.

Henning
-- 
Henning Schulzrinne        email: [email-masked]
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 732 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs