Subject: Re: SIP: Proxy encryption and authentication

From: "Scott Petrack"<[email-masked]>
Date: Sun, 29 Mar 1998 10:21:39 +0200

There are definitely applications from the Telco world that will require
allowing proxies to encrypt and sign. This will happen at the edges of
networks at SIP proxy servers which represent the "phone subscribers" of
the networks.

Did I understand Wedge's concern -- that user names might be sent in the
clear, because user-to-user encryption may not be allowable or available? I
would assume that an operator would want to be able to authenticate and
decrypt packets from one of its subscribers at a proxy server (for example
before injecting it into the PSTN with correct calling line id or passing
it to a peer "SIP network"). The ability of a proxy to decrypt and
authenticate would solve his problem.

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

This is not true, authentication occurs on every call from every pay phone
every time. It is often end-to-end authentication. The point is that it is
the *phone number* that is being authenticated, not the *human caller.*
The phone number (aka SIP address of the phone) is authenticated via
hardware (aka wire to the CO) on every call. It is a legal requirement for
the phone network to receive an authenticated version of the phone number
(the two reasons for this requirement are emergency services  like 911 and
tracing of malicious calls.) Note that the phone devices themselves are not
authenticated (if you have 2 phones at home and you call the police they
can know from which phone number the call was made but not which phone made
the call).

These sorts of "device authentication" mechanisms might also require proxy
authentication and encryption.

The SIP equivalent of this pay phone might be having the client device sign
and encrypt the packet with the device's key, not the user's key. Is such a
thing possible in the current spec? I think it needs to be.

(Actually, when a user like "[email-masked]" picks up a "pay
SIPphone," say with SIP address "[email-masked]" drops in a
quarter and makes a phone call, is the SIPphone acting as a proxy server?
Does it put its own address into the Via: field? What is the correct way to
identify the SIP client device or application from which the human user
makes the call?)

Finally, interoperation with "smart firewalls" is important for more than
just the NAT stuff, it will also help allow proxies to do other "advanced
services" (such as add a multicast/unicast translator into a call, etc.).

On the face of it, it seems to me that user-to-user encryption of the
payload of the packet is just incompatible with having a clever network
device muck about with the payload of the packet. I am happy that SIP
supports user-to-user authentication and encryption, but clearly other
models also need to be supported. I think that it would be wrong to forbid
having a proxy act fully on behalf the thing it's proxy-ing for (device or
user).

I guess the two possibilities are: put into SIP mechanism for full
hop-by-hop encryption/authentication (where a hop is a Via: hop, not a
router hop, of course) This would not be very hard to do; or add text
saying that a proxy MAY sign/encrypt/decrypt packets according to the
wishes of the entity it is proxy-ing for.

It's ironic that this is needed for Telco applications, since Telephone
signalling has no security at all itself. It relies entirely on the
physical separation of the signaling network.

Scott