Subject: SIP: Proxy encryption

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Mar 1998 12:55:48 -0500

Should proxies be allowed to encrypt requests and responses?

Suggested resolution: Yes.  This may be useful and necessary for
a corporate environment and outgoing calls:  the proxy/firewall needs to
see the SDP content and may need to rewrite it for NAT and net-10
reasons. Also allows embedded clients to get the benefit of encryption.

---

From: Mark Handley <[email-masked]>
Date: Fri, 27 Mar 1998 17:39:36 -0500

>reasons. Also allows embedded clients to get the benefit of encryption.

Whilst I agree this might be useful, we have to be careful about the
relationship between encryption and authentication.

The normal SIP model has the sender perform encryption and then the
digital signature for authentication is done over the encrypted
payload.  This is more powerful than the other way around because it
allows smart proxies to check the signature without needing the
decryption key.

If you allow a proxy to perform encryption, you still want end-to-end
authentication to be possible.  Here, the digital signature gets
performed over the cleartext, and then the proxy performs encryption,
rendering the signature invalid.  

If the reason for doing this is to allow a smart NAT to fix up the SDP
payload, the NAT will screw up the signature too.  There seem to be
two ways around this, and both are ugly.

 - talk to the NAT and get your address from the NAT, and then not
   need the payload to be fixed up.

 - use your key to sign certify the NAT's key, and the have the NAT
   actually sign the modified message.

Neither of these need specifying in SIP - they're both outside of the
scope of SIP itself (though not of systems involving SIP - perhaps a
separate ID: "sip and smart firewalls"?).

If the reason for permitting proxy-encryption is because some boxes
are too dumb to do it themselves, I'm not convinced this is a good
enough argument to justify breaking our rule of "proxies only mess
with hop-by-hop fields".

I think end-to-end authentication is _so_ important that I would
rather not see proxy-encryption being permitted in the base draft.

Cheers,
	Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Mar 1998 17:57:06 -0500

In the dumb-client case, the proxy will probably both sign (as a
third-party) and encrypt, so this maintains the
signature-around-encryption model. It's then up to the intermediate
proxies to decide whether to trust something signed by "Columbia
University" or insist on my personal signature. Personally, I'd rather
trust something that an institution is willing to sign - they have
deeper pockets if I need to send lawyers...

However, I'm not convinced that the model "first encrypt, then sign" is
always the appropriate one. If I want to hide my identity to all but the
end system, signing my request in the open is not exactly the best way
to do this. As with any degree of anonymity (e.g., hiding the From
field), I run the risk that some intermediary won't like this and will
refuse to forward my call. However, that's a trade-off best left to the
user.

Caller identity is very sensitive information, requiring a court order
to get, so requiring that I put a signature visible to every unknown
proxy along the way on every call is not going to fly.

The truly dangerous stuff (like redirecting existing calls or getting
somebody to send media to an unsuspecting third party) seems to mostly
affect end systems.

Note: if you'd want to require (or expect) authentication on every call,
you have to outlaw pay phones :-)

---

From: Mark Handley <[email-masked]>
Date: Fri, 27 Mar 1998 18:18:47 -0500

>proxy along the way on every call is not going to fly.

Actually this is a good point, and something we need to fix in the
current draft.  

It appears there's the possibility in the current spec for us to allow
an external identify (From field in the clear) and an internal
identity (From field encrypted) and on decryption our current rules
say the internal From field replaces the external one.  In addition,
the spec would also allow an external Authorization field and an
internal one.

Thus you can have an external identity that clears you through
authenticating proxies and protects the header fields against
tampering, but doesn't reveal your true identity to anyone, and an
internal identity that is only revealed to the recipient.  The only
change we need is to note explicitly that this may occur (ie a
receiver may need to check a second signature after decryption).

Now, a separate issue is the one of whether we let a NAT change the
addresses in the SDP payload - it's this idea I don't like.

Cheers,
	Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Mar 1998 18:32:25 -0500

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 27 Mar 1998 18:42:15 -0500

(my previous message was written with invisible ink.)

> the spec would also allow an external Authorization field and an

To clear proxies, there's the Proxy-Authorization header. We just need
to make clear that it should probably not be encrypted...

> addresses in the SDP payload - it's this idea I don't like.

Our writing it in the spec won't deter NAT vendors :-)

One possibility, suggested reluctantly, is to adopt the RTSP approach of
declaring the media transport ports in the header rather than (or in
addition to) SDP, using the Transport header. That way, they can be left
outside the encryption and can be inspected by intervening firewalls. 

The current scheme basically forces encryption on the message body if
you do any encryption. Compared to most header fields, the SDP stuff is
not all that sensitive.

---

From: Mark Handley <[email-masked]>
Date: Fri, 27 Mar 1998 19:06:57 -0500

>outside the encryption and can be inspected by intervening firewalls. 

Another possibility is to put addresses we want translated in the
clear in a payload independent format:

Eg client adds:

  Address-Map: 10.1.2.3

NAT changes it to:

  Address-Mapped: 10.1.2.3 128.12.34.56

It's then up to the remote end system to do the translation of the
payload using these mappings.  This requires the app knows about the
NAT, but so does SOCKS.

If you want to hide the internal address, we can go one stage further:

Eg client adds:

  Address-Map: 10.0.0.1 10.1.2.3
               ^^^^^^^^ ^^^^^^^^
	       token    real internal address

NAT changes it to:

  Address-Mapped: 10.0.0.1 128.12.34.56

The token 10.0.0.1 is a fake address chosen by the client.  In the
SDP, the client then refers to 10.0.0.1 rather than the real address
which is only known between it and the NAT.

This is of course pretty ugly, but possibly less so than having to put
the transport fields in the clear for all possible transports.

Cheers,
	Mark