Michael Thomas wrote:
>
> Just because I trust your certificate to name
> you as Henning doesn't relieve me of knowing
> what you're authorized for.
There are two different things here:
- trusting the information (which is what we started out from in this
gateway discussion, e.g., trusting the caller-id value). Here, it's good
enough to know that it's an AT&T gateway, say (see earlier discussion).
Whether I accept a call from that gateway is a separate matter and
something that no third party can authorize anyway. (That is, the
traditional "Cisco badge" model doesn't apply here.)
- granting authorization (should my phone ring).
For authorization, the Basic/Digest mechanisms works, since I can hand
out user names and secrets to the very small subset of people in the
world that I want to be able to call me (at least outside certain hours
or using certain means of communication). This also works for outside
gateway access since the gateway has to have at least an indirect
business relationship with me in any event, requiring prior
establishment of trust.
> That means that I
> keep it in some sort of database or it needs
> to be transfered in the authentication token
> (cert, ticket). Keeping a symmetric key in that
> database as well doesn't seem to much of a
> stretch.
>
> So, I still don't see what you've bought
> yourself with PKI, other than lots of CPU
> cycles to do private key operations. If you
See above. Again, at the danger of repeating myself, I'm talking about
things we can do today and where they might be useful. (Beyond the
do-I-trust-this-caller-id problem, public-key signed requests are also
useful for the is-this-call-really-from-the-local-gas-company problem.
Secret-based authentication, as in Basic and Digest, does nothing for me
there.)
> encode the authorization into the cert you
> fall back into the same problem of realm
> multiplicity, if you don't you've consigned
> yourself to database lookups.
>
> > This does not mean that you couldn't use a ticket-based system (Kerberos
> > and kin), but we're here talking about the existing SIP authentication
> > mechanisms Basic, Digest and PGP (or, in the case of S/MIME, trivially
> > added), not something that doesn't exist yet in our context.
>
> There are two possiblities:
>
> 1) Carry the authentication in SIP itself which runs
> into the MTU problems, naively.
Are there statistics on the typical cert size?
> 2) Carry the authentication in a separate protocol
> (such as the results of the KINK to-be-WG) and
> reuse digest authentication as the means of
> generating the keyed hash.
>
> I generally don't like reliance on third party
> protocols/questionable layering, but it is a
> possiblity and is somewhat inherent in both
> IPsec and TLS schemes (less so with TLS, but
> still).
Again, none of this addresses current capabilities and models.
>
> Mike
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs
