More information about the Underscore mailing list

[_] Identity Lifecycle Manager, Client SSL certs, Single Sign-On

Greg Ferro myetherealmind at gmail.com
Tue Apr 12 10:30:55 BST 2011

Such things have certainly been developed and deployed. And failed.

A few years back (circa 2000) Microsoft made much ballyhoo about their 
"SmartCard" Crypto API which would deliver all that you describe ..... 
of course, it didn't work out all that well.

- Microsoft's crypto API was insecure and hacked several times (although 
it seems to be alright today).
- security companies have no concept of "reasonable profit" and gouged 
customers unmercifully for the cards.
- fundamental technology failings in certificate revocation ( which 
still exist today) have never been solved.

However, all is not lost. The concept of the Smartcard looks like it 
will come true in the Smartphone with various underlying developments 
taking place to turn your iPhone/Android into an identity token and 
based Near Field Induction technology for access.

Colour me cynical, but I won't be breathlessly declaiming that the 
future of the Internet has arrived.

Regards

Greg Ferro
e: myetherealmind at gmail.com
web: http://etherealmind.com | http://packetpushers.net




> ------------------------------------------------------------------------
>
> Tom Gidden <mailto:tom at gidden.net>
> 12 April 2011 10:19
>
>
>
>
> Greg's reply was quite enlightening (and disappointing), as I've 
> always thought that client-side certs could be / could have been the 
> silver bullet for a lot of security problems.
>
> Imagine a USB keyring device with a challenge-response passphrase (and 
> built-in biometrics?) that could provide single sign-on plus automatic 
> site registration for any site that complies... no more having to fill 
> in addresses, names, contact details, passwords, password hints, 
> usernames, emails, etc.: just insert your key into the nearest USB 
> port. No more faffing about with insecure and duplicated passwords on 
> myriad sites. Security of the identity becomes solely the user's 
> responsibility.
>
> Of course, there must be a million different technical and commercial 
> hurdles before it would be viable, not least of which are all the 
> problems Greg alludes to. I wonder if/how the whole thing could be 
> fixed to allow such a system.
>
> Tom
>
> ------------------------------------------------------------------------
>
> Matt Hamilton <mailto:matth at netsight.co.uk>
> 12 April 2011 10:05
>
>
> On 11/04/2011 23:04, Greg Ferro wrote:
>> I've designed & implemented this for two Fortune 100, and used it at the
>> BBC.
>>
>> Short version: Don't do it. It's a enormous bucket of hurt..
>
> OK, so you are the second person to say that ;)
>
>> Long version: SSL Client Side certs have been around for a very long
>> time but no one uses it - that's a great testimonial.
>
> Yes, they have been around for ages. UK Govt Gateway even used to use 
> them at one point, but I think have stopped. I've never used them on a 
> project before due to the hassles of distributing the certs in the 
> first place.
>
>> Major flaw is it requires a lot of independent moving parts to all work
>> properly & reliably to provide a satisfactory result.
>>
>> - handling certificate revocation is awesomely difficult. CRL is
>> resource intensive and OSCP still problematic.
>> - handling certificate updates is plain difficult.
>> - the CA requires special handling for integrity and security, and
>> should require multiple CA servers for proper install.
>> - the issuing CA servers must be highly available but it's hard to find
>> CA software that can reliably do this (see 'expensive')
>> - you are dependent on thousands of Windows clients reliably handling
>> the certificate and coherently presenting the correct certificate at all
>> times (experience to date - awful).
>> - widely different approaches for certificate management for Firefox /
>> Safari / Chrome on Linux / OSX.
>> - Microsoft uses different certificate formats (DER) to everyone else 
>> (CER)
>
> OK. Thanks for all that info. The client I think is proposing that 
> they manage all of that, so that wouldn't be my problem. But 
> inevitably, it will become my problem!
>
>> While IWA is painful to manage because it's subject to variation between
>> versions and requires configuration in IE (security zones) to present
>> credentials, it's a lot more reliable in practice. It's simple, well
>> understood and works well enough.
>
> Indeed. It is also used quite a bit more, so I think we generally know 
> where the bodies are buried. I'd also quite like to get them to use 
> it, as that is what we originally specified in the project, and it 
> would be good to get the IWA plugin we've written for Plone into 
> production use and used in more locations. It actually provides a lot 
> more flexibility than you can get with IIS itself. (ie. we can query 
> multiple distinct AD forests (Krb realms) for a single site, or allow 
> anon access as well as IWA on the same site).
>
>> I would consider implementing SSL Client Cert for specific high security
>> use cases, but for normal stuff, the extra cost and implementation work
>> is certainly not worth doing.
>
> Thanks for the comments. This is my thought too. To use client certs 
> alone without using username/password just seems to be a bit backwards 
> in my mind. I've always thought as client certs as an extra layer to 
> add to security, not to replace existing authentication mechanisms.
>
> -Matt
>
>
>
> ------------------------------------------------------------------------
>
> Greg Ferro <mailto:myetherealmind at gmail.com>
> 11 April 2011 23:04
>
>
> I've designed & implemented this for two Fortune 100, and used it at 
> the BBC.
>
> Short version: Don't do it. It's a enormous bucket of hurt..
>
> Long version: SSL Client Side certs have been around for a very long 
> time but no one uses it - that's a great testimonial.
>
> Major flaw is it requires a lot of independent moving parts to all 
> work properly & reliably to provide a satisfactory result.
>
> - handling certificate revocation is awesomely difficult. CRL is 
> resource intensive and OSCP still problematic.
> - handling certificate updates is plain difficult.
> - the CA requires special handling for integrity and security, and 
> should require multiple CA servers for proper install.
> - the issuing CA servers must be highly available but it's hard to 
> find CA software that can reliably do this (see 'expensive')
> - you are dependent on thousands of Windows clients reliably handling 
> the certificate and coherently presenting the correct certificate at 
> all times (experience to date - awful).
> - widely different approaches for certificate management for Firefox / 
> Safari / Chrome on Linux / OSX.
> - Microsoft uses different certificate formats (DER) to everyone else 
> (CER)
>
> While IWA is painful to manage because it's subject to variation 
> between versions and requires configuration in IE (security zones) to 
> present credentials, it's a lot more reliable in practice. It's 
> simple, well understood and works well enough.
>
> I would consider implementing SSL Client Cert for specific high 
> security use cases, but for normal stuff, the extra cost and 
> implementation work is certainly not worth doing.
>
> My 0.02p
>
>
>
> ------------------------------------------------------------------------
>
> Matt Hamilton <mailto:matth at netsight.co.uk>
> 11 April 2011 22:25
>
>
> Dear Brain,
>   We are working with a client who is looking to implement quite a 
> complex Single Sign-On system for their intranet (for 10's of 
> thousands of users). Our original proposal was to use Kerberos and 
> Windows' Integrated Authentication in IE. We have a working prototype 
> of Kerberos SSO plugin for Plone and can get a Linux server working 
> nicely within Active Directory...
>
> however...
>
> A new guy has come into the project on the client side and has 
> proposed an alternative solution: something I've never thought of 
> using before... client-side SSL certs. They mentioned they have an 
> 'Identity Lifecycle System'... something I've never even heard of 
> before and sounds enterprisy and expensive. Doing a bit of a search I 
> presume they mean Microsoft's Identity Lifecycle Manager.
>
> In a nutshell this is how it would work: first time a user goes to the 
> intranet (or any other web app needed authentication) and would be 
> re-directed to ILM and they are then authenticated by Kerberos or some 
> other means and that server then generates a client-side SSL cert for 
> the client who downloads it to their browser and is then re-directed 
> back to the intranet. The intranet can then just use mod_ssl or 
> whatever to check the identity of the user via the client-side SSL 
> cert that the browser automatically proffers to the server.
>
> It sounds fairly reasonsable, and sounds like it should be fairly 
> cross platform and work for any browser that supports client-side SSL 
> certs (all of them I think). It means the intranet doesn't have to 
> worry about Kerberos or anything like that.
>
> I presume ILM would also deal with the certificate revocation list 
> that the intranet server could check against for them certs are 
> revoked. I gather the certs would have a 'long' lifetime, something 
> like a year or more.
>
> It does seems a bit of a risk in that if you can get ahold of the 
> users client-side SSL certs then you can get in. I presume under a 
> windows desktop system then you would have had to authenticate to the 
> workstation in the first place. I don't know if IE stores those certs 
> securely (ala Apple's Keychain?) or not. I guess if the cert itself 
> had a password then it would defeat the whole object of the process as 
> you'd have to enter your cert password everytime you wanted to access 
> the intranet. So it seems to be doing pretty much what kerberos, CAS, 
> or any ticket based auth system would do, but just on a very long 
> expiry time for the tickets (the SSL certs).
>
> Has anyone on here had any experience with doing anything like this 
> before (with the self-service provisioning of client-side SSL certs). 
> How does it work out in practice?
>
> -Matt
>
>