[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Update: Contributed doc. browser bindings incl. Shibboleth
Some comments: >> >>>I would strongly recommend we leave JavaScript out of the >>>profile. Obviously, it is available as an optimization for >>>those who are willing to live a little dangerously. By bringing >>>it in formally we are opening the door to much controversy. >> >>By making a profile using dual-mode code, it will be a >>user's choice if you want automatic operation or not. >>Or do you mean that just by having JavaScript involved >>in something intended to be secure, would drag SAML's >>name in the dirt? This must be a very "tactical" move (which >>I'm bad at...) as implementators without doubt will add >>the JavaScript code anyway. Couldn't one handle it >>like RFC 2459 (X509-certs) that deprecates "legacy >>implementations" that use e-mail addresses in the Subject >>although this is 99.5% the actual deployment? :-) :-) >>I.e. tell how to do it but say its bad... We can figure out how to package this issue appropriately. Yes, I cannot stop implementors from doing a lot of crazy stuff but there is a difference between MUST haves in a specification and "you can also carry out this further step which Javascript-disabled browsers do not support". >> >>>QUESTIONS: >> >>>(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. >>> >>>(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. >> >>This is a hot potato for some people so I can only express some >>personal opionion. If the copy is made by the user, the user >>is performing a crime. At least if giving the assertion to >>another person. As this is like giving away your passwords >>I don't believe that it should be addressed. If the copy is the >>result of a hacked client, I wonder if you can trust anything >>on that machine. It could equally well have a key-board monitor >>and screen collector as well. Sort of impossible to cure. IMHO >>at least. >> >>>How can we guard against this? Notice, this is obviated >>>by the use of a "one-use artifact" >>>as found in the current web browser profile. >> >>There are no problems (we do this now BTW) to do one-time >>tickets but it requires state-holding as well. But not in the >>brutally simple PUSH scheme in my "Fat Browser Objects" slides. 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 machine. Even though limiting the lifetime of the assertion is helpful there still an issue of the form getting re-presented to the destination site. I dont see this as an issue of a hacker breaking the client as much as providing some safeguards against people re-posting the form. >>I guess, the one-time artifacts, do not solve the hidden ticket >>stealer snooping a hacked client? >> Certainly it does not; no such claim has ever been advanced to my knowledge, has it? - prateek
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC