Henning Schulzrinne writes:
> 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.)
Oh, OK. I see where you're going. I didn't read the
original message this way.
> - 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.
With Kerberos based key distribution, Digest could
be almost aribitrarily large given cross realm
operation. With PKCROSS, you move the PKI
problem to the KDC which makes for an even more
scalable solution than pure PKI solutions.
Effectively, KDC's become PKI aggregators which
shield the vagueries of cross realm policy from
mere mortals.
> 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.)
Not true. A cross realm Kerberos based solution
would be more than adequate to give you a high
level of confidence that a piece of information
came from the realm it claims to have come from.
And it doesn't require expensive public key
operations at the endpoints or proxies. The
only place that symmetric key solutions come up
short is in their inability to deal with the
situation where you can, without prior
knowledge of the recipient, sign something that
the recipient can verify directly. This is
useful sometimes -- particularly in multicast
cases -- but the unicast case only requires a
an end to end INVITE to make that advantage
disappear.
> Are there statistics on the typical cert size?
Probably, but I don't have any handy. I've
heard that typical certs are ~500 bytes and
that you need to ship part of the hierarchy
which may include a cert or two more. Even if
it's half, it's still problematic for multiple
realms.
> > 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.
Is that actually true? If you posit a
pre-shared symmetric key between the two
entities, both digest and PGP provide a
means of doing symmetric key signatures.
It's true that there isn't a SIP endorsed
means of shipping Kerberos credentials, but
that doesn't mean that symmetric key PGP or
Basic/Digest couldn't be used as-is. I've
promised to write an ID by this fall on how
to do this, so we shall see.
Mike
