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: 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: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security, Tivoli Systems, Inc.





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


Powered by eList eXpress LLC