Henning Schulzrinne writes:
> Michael Thomas wrote:
> > Not true. You are still guessing that the UAS will
> > trust that certificate hierarchy. That may not be
> > a valid assumption. It's the exact same problem
> > as guessing which basic/digest realm might be needed
> > along the way. I can just as easily posit a global
> > symmetric key realm as a global PKI realm. Both
> > are fantasies.
>
> Given the practical success of having CA's embedded in millions of web
> clients, this seems at least feasible and works millions of times each
> day, even though it's less than ideal if you're a new CA and want to be
> recognized as such.
Just because I trust your certificate to name
you as Henning doesn't relieve me of knowing
what you're authorized for. 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
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.
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).
Mike
