Jonathan Rosenberg writes:
> Let me rephrase the problem. A user makes a call from a PSTN phone
> through a PSTN->SIP gateway. This call arrives at a proxy server, then
> gets routed to a UAS. Either or both of the proxy/UAS might challenge
> this request. In this case, who is being authenticated, the gateway
> itself, or the user calling in through the gateway? If its the user
> themselves, how would that work?
It depends. Clearly the gateway must proxy the
authentication no matter what.
> One might argue that authentication of a gateway by a proxy is useless;
> really in this case you want a hop by hop security mechanism like IPSec
> or TLS, and forgo completely the high overhead SIP authentication for
> each message. Then again, in the absence of support for IPSec or TLS,
> SIP proxy authentication migth provide a way to authenticate the gateway
> from a proxy.
Probably, though you may again want to have a "default"
service which is authenticated as the gateway (directly
or implicitly through the lower level SA) and a user
authenticated service.
> It also seems unlikely the UAS would really be interested in
> authenticating the originating gateway.
Why not? It may very well be that I don't trust
or have control over my first hop proxy. Assuming
that the gateway had a default secondary dialtone
IVR maze which would change the From: address and
respond to any challenges with a PIN, this is
pretty much exactly what you'd want.
> Some options:
>
> 1. The realm indicates this. For example, a realm of "gateway" would
> indicate that the gateway is being authenticated, "user" means the user.
> We wouldn't need to standardize the actual words here, but rather
> standardize that the realm would indicate which was the case through
> administrative configuration.
>
> 2. Use a different response code for each case. Probably not a great
> idea.
>
> 3. Others?
I think it's a slippery slope trying to draw
a difference between "gateway" and "user". A
better way to think of this, IMO, is that a
particular device may at any time take on one
or more identities, and that at any point each
proxy/UAS is entitled to demand authentication
for an identity in its realm. This is consistant
with real life: I have a drivers license for
driving, a credit card for buying dinner and
a cisco badge for getting into our buildings.
At each place, a different identity is stored in
those pieces of plastic and each demand the
proper one for its realm.
> I'll also note that this problem is not limited to gateways - its the
> fundamental issue of whether you authenticate a device or a user, and
> could equally well apply to a softphone application, single line
> gateway, and trunking gateway.
Yes, I'll say again that like my wallet, it
is necessary to be brutally parsimonious about
the size of credentials. For SIP, I really,
really think we need to introduce the concept
of cached credentials on the UA/proxies so that
you can transfer a relatively large and/or
expensive credential (kerberos ticket,
X.509...) once, and use a keyed hash for
subsequent messages. If it were just one
credential that might be demanded upon the
path, it might be OK (and with public key
operations, even that is doubtful), but the
possibility of an unlimited (where for both
kerberos and X.509 "unlimited" is > 2) set
of credentials means that you couldn't do
UDP INVITE's without fragmentation which
really sux.
An iterative model of challenge/response/cache
where the UAC sends a keyed hash based on a
shared symmetric key after the initial
challenge would scale *much* better.
Mike
