SIP in higher education

[Shumon Huque <>]

On Fri, Mar 31, 2006 at 05:14:13PM -0500, Alan Crosswell wrote:
> What about the fact that most handsets have very weak security?  Do you 
> really
> want your handset to store your cleartext password (so it can do the 
> kerberos
> authn with it) or would you rather use your kerberos stuff for a 
> provisioning
> web application that gives out a phone-specific password?
> /a

I would certainly not trust my current VoIP handset with my
Kerberos password. It runs some sort of proprietary operating
system image and furthermore obtains this image unsigned and
via unauthenticated TFTP :-)

If I were running a SIP based soft client on my desktop or my
laptop though, that's a different story. It would be nice to
be able to use Kerberos to mutually authenticate soft clients 
to a SIP registration and proxy server.

With the current state of our VoIP "hard" phones, I currently 
prefer a model that authenticates the device rather than the 
user. We actually do this today using pre-shared secrets and 
Digest Authentication. This still has several security problems, 
but it's the best we've been able to do so far. If SIP supported 
Kerberos, we could conceivably use Kerberos to key the handsets 
with a random secret and get rid of Digest authentication.

I think we need to do some more thinking about the best way to
use Kerberos in SIP though. I believe SIP inherited most of it's
authentication mechanisms from HTTP (basic, digest or TLS), so
that kind of explains things: HTTP has similarly lousy support
for Kerberos. Incidentally, TLS does have support for Kerberos
authentication (RFC 2712) but no-one really uses it, and the
current spec has a number of outstanding technical problems.

I think we might want to use GSS-API rather than Kerberos
directly. The IETF generally says use GSS-API, unless you have
a specific reason to use Kerberos directly. So developing a
spec that used GSS-API is much more likely to succeed in the
standards arena.

Additionally I think we'd want to make sure that we can leverage
Kerberos to do channel protection. Simply authenticating the
SIP session with Kerberos isn't that useful, if attackers can 
easily hijack or tamper with the session afterwards. If Kerberos
is not providing this, then you'd still need something like TLS 
or DTLS with a server side PKI certificate.

And then there's a question of inter-domain authentication, ie.
end-to-end authentication of SIP user agents to one another. Cross 
realm authentication is of limited use because not every site uses 
Kerberos. The SIP authenticated identity draft might be one way of 
addressing this problem:

  http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-06.txt

--Shumon.