SIP in higher education

[Prashant Kumar <>]

Sip identity draft is a very good option. However, using the Identity draft will not allow the use of Kerboros and will not help the existing  Kerboros deployments.

 

To use the Sip Identity, an UA as to identify itself to the Authentication service. One of the ways specified is using Digest authentication. This still forces us to have some kind of shared-secret between UA and the Authentication service!

 

- Prashant.

 

Shumon Huque <> wrote:

> 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.ordrafts/draft-ietf-sip-identity-06.txt
> g/internet-
> --Shumon.

---

New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.