OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Update: Contributed doc. browser bindings incl. Shibboleth


The entire javascript solution:
<BODY BGCOLOR="#FFFFFF" Onload="javascript:document.forms[0].submit ()">
<CENTER><H2>Your browser is JavaScript-disabled!</H2>
<H3>Click on the button below to manually continue the login</H3>

>>>(1) Do we need to mandate assertion confidentiality? Notice
>>>that the assertion itself is loaded into the user's browser
>>>and can therefore be "read" by the user. Should some form
>>>of encryption be mandatory here? 

>>I would not make this mandatory as it would both complicate
>>things, and there are probably not that many "secret" assertions.

>Hmmmm. I disagree. As we are building a security protocol this feels
>like a pretty big issue to me. My first cut would be that
>confidentiality should be required in this context. Otherwise,
>I can watch assertions fly by me and learn quite a lot
>about the AP and RP and what sort of information they plan
>to exchange.

I don't think that security is an issue in this case.  At least if we are
taking technical security in the sense that a user could fake
data in some way by looking on it.  To be able to do that you
must crack signatures keys etc.  That the protocol and verbs
are exposed is not a problem if we are not dealing with a
system based on "security by obscurity".
I therefore still prefer that encryption should depend on if the
information exchanged between the
AA and RP is secret for the user.  My *guess* is that
this is seldom the case. At least in the B2B-systems, like OBI, that
we work with, it never is.  I.e. employers (AAs) do not (in such
systems) exchange data about their employees with external business
partners (RPs) that the employees are not aware of.  Actually these
assertions are often not even carrying the employee's names.

>>>(3) But what about replay attacks? Even with (1) and (2)
>>>(signed assertion which has been encrypted) the assertion
>>>and form can be copied and used from a completely different browser
>>>by a completey different user.


>The point here is that the form (with the assertion 
>contained within it) is now present within the local
>state of the browser. People
>can use the "back" button and access it and re-post
>it to the destinaton site. Browsers
>are used in the public arena (kiosks, airports), 
>not just in private offices. People may complete
>a short transaction and then walk away from the 

I have two comments on this.
1. Any browser-based system that caches any kind of assertion-data will
allow a "back" button replay.  I.e. the only solution are one-time
assertions which we aleady have [as an option] in our system using
"fat browser objects".
2. If someone logins to the AA and leaves the browser
open they are in trouble anyway, independent on what
kind of system they are using.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC