Michael Thomas wrote:
>
>
> 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.
Also, if the gateway provides the caller id (e.g., as From), the UAS
might be very interested in gauging whether it can trust this
information.
>
> > 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.
> >
>
> 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.
Also note that the realm is the challenge *from* the UAS, so this would
not be particularly useful in the general case.
The model seems a bit different depending on whether we're talking about
basic/digest or PGP (or S/MIME) authentication.
For basic/digest authentication, the gateway would have to know a user
id and password registered with the remote UAS, appropriate for the
realm "challenge". It's not likely that either a gateway or proxy will
know what user names and passwords are valid at the callee UAS. (It is
much more likely that a GUI-equipped SIP UAC will have this information,
e.g., embedded in an address book or other cache, similar to how web
browsers handle authentication.)
For PGP or S/MIME, this is much more likely, as long as I can get
something that is certified. Again, very similar to server
authentication in a web case. In that model, the UAS would simply get
"this call originated from a gateway that has the private key of
Telephant Telephone Company." This would likely be good enough for me to
judge whether this company will deal with crank calls appropriately and
whether the caller id is more than a random bit string. (What you really
want is probably something stronger, such as a way to find out whether
this entity is certified in some way to have these properties, as the
average callee is unlikely to recognize Granby Telephone, say.)
Since the number of calls from a particular gateway to a particular UAS
are likely going to be very low in most instances (I'd guess no more
than ten a day), long-lived associations or caching aren't any more
necessary than for S/MIME or PGP-secured email.
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs
