[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: HTTP binding & impersonation counter-measures
Marlena et. al.: > It is my belief that it is "not a good idea" to use >the fields of an attribute assertion to provide counter-measures >information. Reason: Attribute assertions could (theoretically) >be long lived (e.g. college degree info).The suggestion to tie the >information in the assertion to the http binding >necessarily obliterates the notion of a repository of long-lived >assertions (because of the need to have a very short validity period). I strongly agree with this -- the attack we're guarding against is the re-use of an assertion in a particular context and hence is a bindings issue. If we try to prevent re-use of an assertion *in general* then we will have to solve a very hard problem, namely the problem of making sure that two different destinations can't simultaneously rely on the same assertion -- which can only be solved by requiring a trip back to the asserting party by the relying party to confirm that the assertion is still valid. This way madness lies. All validity concerns regarding ASSERTIONS should be handled by lifetime and audience restrictions. Period. > On the other hand, I think it is an OK idea to tie the fields of >an authentication assertion to the binding. Yes. However this raises an interesting problem.... for which see below. >The authN assertion isn't supposed to be long-lived in any case. I *don't* agree with this, but I also don't think it affects the validity of anything else we're discussing here. > That said, however, it seems to me that we'd like to >have a single mechanism for providing impersonation >countermeasures in the http binding -- and it should be >the same for both attribute and authentication assertions. >(And it shouldn't be a requirement to have an authN assertion >before getting an attr assertion!) Yes and yes. > Putting countermeasure info in packaging works for >both types of assertions. Here's where it gets hard. You can only REALLY put countermeasures in the packaging if the client is both state-aware and crypto-capable. The ideal solution would be for the CLIENT to generate a nonce and use its OWN key to apply an integrity seal to the assertion and the message with which it travels. This would solve all problems but would require changing the client code to be SAML-aware. Without doing this, you'll always be open to the kind of attack you cite at the beginning of your note (server impersonating user). >Using the fields in the assertion itself >(as currently proposed) seriously messes with the possible >longer-lived uses of an attribute assertion. I agree and I don't think we should use the fields of the assertion to try to prevent re-use. --bob Bob Blakley (email: firstname.lastname@example.org phone: +1 512 436 1564) Chief Scientist, Security, Tivoli Systems, Inc.
Powered by eList eXpress LLC