Log in

No account? Create an account


Not so soon...

« previous entry | next entry »
1st Dec 2005 | 18:26

So, while I was away seeing my dad and going to EuroBSDcon in Basel, my boss Bob presented my Jabber proposal to the senior management team. It was sent back to me for further work.

There were a few tactical errors, I think. The original reason for writing the proposal was that I had got to the stage of needing real DNS records in order to do some realistic testing. Bob said that I couldn't have them without SMT approval, hence the proposal write-up. (For good reasons there is a bit of a hurdle for the creation of domains immediately under cam.ac.uk.)

What I failed to emphasize to Bob or in my proposal, was that there had been no discussion of requirements or of development/release milestones beyond what I had sketched out for myself. So I was perfectly happy for the SMT to say "do things in this order please, and we won't formally announce until X, Y, and Z are done". Our Glorious Leader demanded a web interface with Raven authentication, and our Deputy Director thought that we'd need an MSN gateway to maximize take-up. There was also some discussion about how we could guage that the service was successful. This was all fine by me.

However there was much more of an argument than was warranted, especially over the Raven requirement. This is irritating because I'd prefer to make progress than fight political battles over unimportant details. Maybe we'll be successful with a revised proposal at the SMT next week.

The Raven requirement does have some slightly awkward implications which are worth noting.

The security model for Raven requires that Raven passwords are only typed into Raven, which means that they cannot be used by native Jabber clients. So my original plan to use the Hermes password file will still go ahead. But we've been told that any web-based Jabber client must use Raven authentication, which means that Jabber users must use different passwords in different contexts, which is a bit ugly. It's also different from the way Hermes passwords are used for email - though OGL says that if our webmail service was being done now it would also use Raven.

It implies some customization of the software, rather than just installation and configuration of the standard version. The Jabber HTTP binding uses clever AJAX techniques to get much less latency and bandwidth than a simple polling solution, and the protocol tunnels most of the Jabber protocol through to the web client. So I may have to make modifications to both the web client part as well as the web server part. Fitting an AJAX application into the Raven model may be tricky too.

Then there's the problem of turning Raven authentication at the web server into SASL authentication at the Jabber server. The easiest way to do this is for the Jabber server to trust the web server, and for them to use SASL EXTERNAL authentication. The EXTERNAL mechanism just states the username, and the server uses some implicit context to authenticate it. It is designed for lifting TLS client authentication up to the SASL layer, but it also works for turning trust defined by the system administrator into a standardized protocol. This kind of trust is not great for security, so I'd prefer something better; we'll see if Jon Warbrick, the author of Raven, has any bright ideas.

| Leave a comment | Share

Comments {6}


University-wide authentication

from: nonameyet
date: 1st Dec 2005 20:58 (UTC)

It is looking more and more as though we need a university-wide authentication strategy (and that my attempt to turn the not yet born wireless interest group into an authentication interest group were in the right direction).

jp107 has expressed a wish that wireless access be controlled by dot1x authentication against a University Computing Service run Radius server (looking at the password database used by Raven, although any widely used CS password database would be fine technically). If such a thing existed, would dot1x/Radius play any better with Jabber and AJAX ?

Reply | Thread

Tony Finch

Re: University-wide authentication

from: fanf
date: 2nd Dec 2005 12:36 (UTC)

If such a thing existed, would dot1x/Radius play any better with Jabber and AJAX ?

Yes, because the security model is much more relaxed than Raven. In particular, Raven passwords may only be typed in to Raven, and web servers that use Raven never see the password. For Radius etc. the web gateway and Jabber back-end would both see the password and be able to do normal things with it, such as SAL PLAIN authentication with pam_radius hanging off the back.

There were some discussions in the CS about setting up a Kerberos service to support single sign-on for any Kerberized service. This would include anything that uses SASL, such as Hermes and Jabber. However the difficulty of doing the Windows side of the cross-domain authentication caused the idea to die.

Reply | Parent | Thread


from: pjc50
date: 1st Dec 2005 21:49 (UTC)

Couple of radical suggestions:

1) abandon authentication altogether and deal with impersonation as a disciplinary offence, with the thing firewalled to @cam;

2) have a page on Raven which emits an OTP that can then be used to log into Jabber within the next minute by cut-and-paste. (While this is technically vulnerable to shoulder-surfing, the attacker has to copy it off the victim's screen faster than the victim can paste it from one window to another).

Reply | Thread

Tony Finch

from: fanf
date: 2nd Dec 2005 12:39 (UTC)

(1) Apart from the fact that a mid-1980s security model is inexcusably reckless nowadays, we can't firewall to @cam because we need to support roaming users.

(2) Far too clunky from the user interface point of view, and no simpler than just doing it right from the implementation point of view.

Reply | Parent | Thread

Steven J. Murdoch

from: sjmurdoch
date: 2nd Dec 2005 14:55 (UTC)

I agree that using different password for native and web clients might cause confusion. The ideal solution would be for there to be a single sign on system which could be both used on the web and native clients. There are lots, but none that I am aware of being supported by any widely deployed application let alone Jabber clients.

Here are two cludgy possibilities. The first (from stegro) is to let the user log in using any password. They are isolated from all users, but receive and automated IM from the system containing a link. The user click on this link, which will redirect them to Raven. If they sucessfully authenticate to Raven, the Jabber server will de-isolated them and they continue as normal. This could also generate them a random password, or simply set their Jabber password to be the one they entered before authenticating to Raven.

The second is my idea but I like it less than the above one. Single sign on exists but supporting it would require changes to applications. Users will have many platforms and their favourite applications on each. Modifying a few clients is time consuming, infeasible if closed source and tedious to support. Instead, how about a SOCKS proxy server on the users own machine. It opens a web browser, authenticates the user to a CS server using Raven which sets a cookie. The SOCKS proxy then sends this cookie to the Jabber server on a connection attempt. I belive MSN messenger can operate in this mode, using the Hotmail cookie.

Reply | Thread

Tony Finch

from: fanf
date: 2nd Dec 2005 16:02 (UTC)

People must be able to use Jabber clients on platforms which we don't support and on platforms which are constrained in some way. Adding hacks to the server which make the user interface significantly worse are not a good solution to the anticipated Hermes/Raven password confusion - which I don't expect will be all that bad in practice.

Reply | Parent | Thread