[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