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: HTTP binding & impersonation counter-measures


[If you aren't interested in the HTTP binding, don't bother reading
this.]

In recent discussions, folks on the bindings committee have
been batting around how to provide counter-measures to
a number of different impersonation attacks (for the HTTP
binding).  This note discusses some (but not all)
interesting aspects of the proposals.


A few weeks ago, I suggested that the bindings proposal didn't cover
the case of a malicious destination forwarding an artifact to
another destination, thus assuming the identity of the
browser user.  And I laid out the Shibboleth counter-measure
to this attack -- which is to including a destination identifier in
our tamper-proof artifact (which we call a "handle package").
     At this point, there is some disagreement --  not about the
use of a destination identifier as a counter-measure, but where to
put it.

    In particular, it has been suggested (by Prateek and others) that
the <AudienceRestrictionConditionType> could be used for
this purpose.
    This struck me as a different use of the field than had
been intended. My impression of the field is that represented the
audiences for the assertion itself. To my mind, who the assertion
might be used for is a different matter than
who the user is trying to visit at the moment.
     Given this it seemed to me "obvious" that the impersonation
countermeasure information need to go either around the
reference/handle  in the artifact, or around the pushed assertion
(depending of course on the particular flow). I refer to this
as using "packaging" to help with impersonation counter-measures.
    So the adamance (as graceful as it was) of the other bindings
folks to use the fields of the assertion to provide impersonation
counter-measures confused me.

    Enlightenment struck after I read very useful emails by Tim,
Prateek, and Hal about a variety of bindings topic. The emails about
the http binding consistently discuss authentication assertions
and assume that there will always be one pushed or
pulled to the RP. Aha!  In  Shibboleth, we don't currently
have authN assertions.  Our artifact contains a "handle"
which is used to pull an attribute assertion. (Authentication
method is left entirely up to the origin institution of the user.)

    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).

    On the other hand, I think it is an OK idea to tie the fields of
an authentication assertion to the binding.   The authN assertion
isn't supposed to be long-lived in any case.

    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!)

    Putting countermeasure info in packaging works for
both types of assertions.  Using the fields in the assertion itself
(as currently proposed) seriously messes with the possible
longer-lived uses of an attribute assertion.

    Perhaps there is another alternative?


Regards,
Marlena
IBM/Tivoli



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


Powered by eList eXpress LLC