Community Matters

This is a topic that I have been tossing around for a while. The fact that I gave a presentation about this at this week’s SambaXP conference in Göttingen has forced me to put some structure around my thoughts.

Single sign on is a commonly listed goal in the IT industry. You authenticate once and then have access to all kinds of applications or services via the net. This sounds good, but of course it comes at a price. The damage that can be done if your credentials are compromised increase dramatically if they can be used in many places.

A simple example. Let’s say you use your login credentials to also be able to access your email account. That’s wonderful – one less username and password to remember. But unfortunately a number of email clients (or email retrieval apps like getmail or offlineimap) have no convenient way to securely store your credentials – or are easily fooled into handing these credentials to a proxy server. Which suddenly exposes your “general pass key” to your account to an attacker.

Of course you can use SSL encryption on your email protocol (e.g., imaps) to make man in the middle attacks harder – but that only works if you have signed certificates and a correctly built and trusted CA in place with the CA certificates installed on all clients. Which gets a little harder with the proliferation of mobile clients. For example, when using your favorite email client on your Android phone (or Nokia N71, or…), who hasn’t clicked ‘accept’ when asked to verify the authenticity of an SSL certificate provided for the server that wasn’t signed with a key that’s installed in the client’s CA keychain. You may have looked at the certificate to make sure that it looked sane – but did you verify it?

That’s a huge risk when allowing authentication with typical username / password based single sign on credentials on internet-facing servers. Yet that’s a very common practice.

So what can you do? One school of thought is “just don’t do it”. Have separate credentials for all services, force distribution of CA certificates, enforce SSL or SSH as a minimum requirement to connect to any services and basically device and conquer the risk. But frankly, that makes mobile clients far less attractive, interaction with network facing applications and services more difficult and generally reduces productivity. And in the end, if users are forced to use too many distinct username / password combinations they tend to use simple algorithmic passwords (or simply write them down somewhere in clear text).

Another alternative is to look at ticket based systems like kerberos and the way they handle credentials. Kerberos (and it’s implementation in Microsoft’s Active Directory) encrypt all traffic and use a rather smart system to prevent man in the middle attacks. Assuming strong passwords (to prevent the well documented offline password guessing attacks) you can create a decent sign on system that can be used with mobile clients – assuming the client software stack includes the necessary code to authenticate against A/D – which unfortunately is not universally the case today.

Ideally for each account with a service provider you as the user would be able to pick how to authenticate – using a ticket authority of your choice – potentially with different identities between different services, potentially with the same. This way you could control which services share the same ID, ensure that all authentication is secure and at the same time make it easier to manage these identities securely in a mobile device.

Samba is a widely used open source implementation of the necessary pieces of A/D. It allows clients to authenticate against Active Directory servers or other kerberos based authentication servers and then only distribute tickets (that don’t include the actual credentials) to authenticate against services. One downside of using Samba’s model of implementing the different components of MSRPC as monolithic applications instead of APIs is that it makes it harder to use in this context (providing authentication services in the mobile world); also, Samba has gaps in its support for the full breadth of A/D (missing some of the SSPI providers).

Still, it’s a good start. An alternative could be Likewise Open as it matures. Kirshna and his team certainly are focused on a complete implementation of the necessary APIs – but the mobile client isn’t their focus area, either.

The discussion after my presentation showed some interest in the community to tackle the problem, but of course this will require the service providers and the device vendors to cooperate as well. But first more people need to understand the underlying problem that needs to be solved…

As part of my brief set of posts on getting Linux systems (and sometimes Macs) connected to wireless networks beyond WiFi, here’s a quick post on what’s different when connecting to Vodafone.de with their prepaid CallYa SIM in a Huawei USB stick (this is actually a stick that I bought in London for the O2 network – just switch out the SIM… one of the nice things about GSM based networks).

The first few problems that I ran into shouldn’t affect most people, but just in case… be warned, if you have setup your system to use Vodafone.uk in the past, you are likely to have incorrect settings laying around in conf files…

Once those are removed, plug in your modem and simply create a new connection under Network Manager / Mobile Broadband. Set the APN to event.vodafone.de (this is important – contract SIMs use web.vodafone.de but that doesn’t work with CallYa SIMs). You can type in your PIN in that dialogue as well, that way the system doesn’t ask you for it after every reboot. All the other information is optional or not needed – except for the phone number; the usual *99# does the trick.

Go to the Network Manager icon and click on the new connection you created (it should show up under Mobile Broadband, assuming your modem got recognized correctly). Once the connection is established (the NM icon changes to a broadcast tower) open a web browser and navigate to any arbitrary web page. Vodafone will redirect you to a page where you can pick whether you want to purchase 30 minutes, an hour or a day’s worth of “unlimited” internet. Once you went through that process, everything should work. If I tried to open an ssh connection (or something else) before doing the magic web page thing the system occasionally got confused…

After sitting on the sidelines for a long time I finally figured “what the heck” and started to use Twitter.

You can find me as dhohndel.

Disclaimer on top (so no one can claim they didn’t see it): I’m obviously not necessarily an objective observer here. I work for Intel and have been involved with the Linux Foundation and its predecessor organizations for many many years. But this is my blog – unrelated to either organization (so if you quote me, please keep that in mind).

Some people might think the blog post at the New York Times that Intel hands Moblin over to the Linux Foundation is an April Fools joke. But even though the headline is a little unfortunate, the content of the article is correct: In order to make it easier for more people to get involved in Moblin, Intel has asked the Linux Foundation to take over the stewardship of the project.

This does not indicate any reduction in Intel’s effort on Moblin (quite the contrary, actually). Nor does it mean that dramatic changes are coming to the short term development plans. On the technical side it’s the same engineers doing the same impressive work.

But neither is this just a symbolic act – this really means that the Linux Foundation – a “nonprofit consortium dedicated to fostering the growth of Linux” (quoted from their About page) is hosting the project and will run it in a way similar to many other open source projects. The role of contributors will be determined by their merit to the project; which means that non-Intel engineers will hopefully soon step up into leadership roles. This is important for the pace of adoption of Moblin in the industry and (based on my conviction that true open source development is a huge advantage) this will cause the pace of innovation to increase even more. And it is something that would have been much harder to implement if the project is seen as only “Intel’s Linux OS”.

So to me this is great news. And from what I am hearing the same is true for many in the Linux community who have watched the first signs of life of Moblin with growing excitement. With the release of Alpha 2 a short while ago the traffic on our developer list has noticeably picked up – as has coverage in the press. And frankly, Alpha 2 barely scratches the surface of what Moblin will deliver.

Next week at the Linux Foundation Collaboration Summit I will host a Moblin track and I am very much looking forward to discussing what all this means with the attendees.