Re: Question about "TLS CCA Session" versus "Web Session"

On 5/12/14 7:50 AM, Anders Rundgren wrote:
> On 2014-05-12 13:33, Kingsley Idehen wrote:
>> On 5/12/14 6:00 AM, Anders Rundgren wrote:
>>> On 2014-05-12 10:57, henry.story@bblfish.net wrote:
>>>>
>>>> On 12 May 2014, at 09:32, Anders Rundgren 
>>>> <anders.rundgren.net@gmail.com> wrote:
>>>>
>>>>> On 2014-05-07 11:48, henry.story@bblfish.net wrote:
>>>>>> On 7 May 2014, at 08:42, Anders Rundgren 
>>>>>> <anders.rundgren.net@gmail.com> wrote:
>>>>>>
>>>>>>> I don't claim knowing everything so please bear with me when I 
>>>>>>> ask a simple question :-)
>>>>>>>
>>>>>>> Using JBoss and Tomcat (java-based) servers an HTTPS Client 
>>>>>>> Certificate Authenticated
>>>>>>> session created from a browser *never terminates* regardless of 
>>>>>>> session time-out settings
>>>>>>> because the TLS session has no link into the Java Servlet web 
>>>>>>> session framework.
>>>>>>>
>>>>>>> Due to this neither manual logout or automatic logout work in 
>>>>>>> such setups.
>>>>>>>
>>>>>>> Q1: how do other web-servers enforce logout from the server-side?
>>>>>>> Q2: if other web-servers actually can do this,  does this 
>>>>>>> require TCP terminate?
>>>>>>> Q3: if other web-servers actually can do this,  logout works 
>>>>>>> formost/all browsers without specific measures?
>>>>>>>
>>>>>> As far as I can tell a server cannot force logout of the client, 
>>>>>> since the browsers tend to resend the same certificate
>>>>>> to the server. You can only do this with Firefox which has a 
>>>>>> Javascript logout call currently. In my view login/logout
>>>>>> has to be handled by the client in the chrome.
>>>>>
>>>>> This is a unique problem for HTTPS Client Certificate 
>>>>> Authentication; no other authentication
>>>>> method needs modifications of the chrome in order to perform 
>>>>> logout or requires the client
>>>>> to support session timeout policies.
>>>>
>>>> That is wrong as a little reflection should show:
>>>>
>>>> - Basic Authentication uses the Chrome
>>>
>>> True.  However, basic auth is even less popular than HTTPS Client 
>>> Cert Auth.
>>> Form-based login rules on the web.
>>>
>>>
>>>> - All other current methods rely on cookie based authentication, 
>>>> and it is problematic to exactly the extent that
>>>>    there until recently it was difficult for a user to control his 
>>>> cookie based personas. This is exactly what Aza Raskin
>>>>    was trying to bring into the Chrome with his "Identity in the 
>>>> Browser" blog post
>>>> http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
>>>
>>> Fine with me.  If the mechanism is universal it would be a useful 
>>> option.
>>>
>>>
>>>>> I can though imagine a chrome-based identity context but it should 
>>>>> be optional and universal.
>>>>> It should probably also address logout to *all* enabled sites that 
>>>>> you have encountered
>>>>> during your session on the web.
>>>>
>>>> yes, there are many such features that become possible once one 
>>>> starts thinking about tying
>>>> identity to the Chrome, and putting the user fully in control of 
>>>> it. Google Chrome's Profiles
>>>> are a good step in the direction, but they don't yet help show 
>>>> which certificates are used,
>>>
>>> OK
>>>
>>>
>>>> which  is important just because with WebID one could log into all 
>>>> sites with the same certificate.
>>>
>>> In theory a singe certificate using WebID could log in to all sites 
>>> but due to differences in
>>> policies etc. this won't happen.  I don't see that as a problem if 
>>> you have a working certificate
>>> selection filter.
>>>
>>>
>>> Question: where does this leave us?
>>>
>>> Anders
>>
>> Waiting for Chrome, Firefox, and Opera to catch up with IE (Windows) 
>> and  Safari (on Mac OS X, iOS). Now if you want to look at matters 
>> through "actual user" lenses, then the total users of IE and Safari 
>> completely trump the users of Firefox and Chrome, who for all intents 
>> are purposes fall into the "programmer / developer" user profile.
>>
>> To conclude, most end-users don't even have a problem. They can work 
>> with <http://id.myopenlink.net/ods/webid_demo.html> and switch 
>> certificates without restarting their browsers. As for the issues 
>> with Certificate selection presentation, that's less of a problem 
>> when the Certificate Generator UI aids the user accordingly re., CN 
>> attribute values.
>>
>> As is often the case, the programmer is making an incorrect 
>> assumption about end-users based on the programmers own preferred 
>> combination of host operating system, development tools, and test 
>> applications (e.g.,, browser in this case). Windows, Mac OS X, and 
>> iOS end-users don't have a problem because they use the default 
>> browsers provided by the OS.
>>
>> If I have <http://id.myopenlink.net/ods/webid_demo.html> tweaked 
>> (which I will), such that it tests for Firefox/Mozilla, even users of 
>> that particular browser will be able to authenticate without 
>> restarting the browser -- since the HTML page served up from the 
>> server will include the necessary JS code achieving this goal.
>
> This discusson doesn't go forward.
>
> Google, Microsoft, PayPal and a lot of other big players recently
> put their money on U2F which is completely new solution. 

So? Does anything stop the implementation of a WebID-Authentication 
profile for U2F?

> There must be
> reasons for not bulding on the already deployed platform, right?

Yes, but not what you are thinking, I can assure you of that.
>
> Not until the WebID folks understand the motives behing the U2F we
> can expect any progress in this space.

A spec shouldn't be based on the motives of vendors. It should be 
focused on providing an open approach to solving a real problem etc..

Vendors respond to "opportunity costs" above all else.


Kingsley
>
> Anders


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen