[OGSA-AUTHZ] Implementations

[David Chadwick]

Hi Tom

I would like to make two points to your comments

Firstly you are missing the point I made about the Shibboleth metadata. 
This is telling the SPs which IDPs it can trust. Without this necessary 
information user presence is not provable, since an untrusted IDP will 
lie to the SP that the user has just authenticated correctly, when there 
could be no user or the wrong user there. Consequently the meta data is 
providing the trust anchors in just the same way that Valerio is doing 
in his list of Grid SPs. Hence my analogy on the way of providing trust 
is correct.

Secondly the inclusion of a "certificate" needs more elaboration. The 
inclusion for example of a user's public key certificate proves nothing 
more than the presence of a DN does, since it is publicly available and 
an untrustworth grid SP could send any PKC it wished, just as it can 
send any DN it wished. Therefore one needs to specify the properties of 
the certificate that are being transferred, which is, that the user is 
delegating to the grid SP to act on its behalf. A proxy certificate 
would do this, as would an attribute certificate.

Finally, if you have followed a lot of the (old) discussions on the PKIX 
list about DN matching in certificates, you will see that a lot of PKI 
software vendors do plain string matching of DNs, rather than proper 
X.500/LDAP DN matching rules, so dont believe that passing certs instead 
of DNs will solve this problem. It wont. Only proper DN matching 
software will solve this, so it is irrelevant whether the DN is passed 
as a string or in a cert.

regards

David


Tom Scavo wrote:
> On Fri, Mar 21, 2008 at 6:15 PM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>>  I dont fully agree with your analysis since you have missed out the
>>  concept of trust. If an AA trusts an entity to act as a proxy on behalf
>>  of another entity (and this is actually the case we have here with the
>>  Grid SP acting as a proxy on behalf of the user) then the AA will be
>>  prepared to let the trusted proxy have the attributes of the entity it
>>  is acting on behalf of. There are many ways for the AA to know who it
>>  trusts. One way is for it to configure in the names of the trusted
>>  proxies (this is the easiest way but is not scalable), another is for it
>>  to configure in the name of a trusted entity that says who are trusted
>>  proxies (much more scalable since the trusted entity can authorise
>>  hundreds or thousands of trusted proxies) and for the trusted proxy to
>>  present this token to the AA.
> 
> What you say is true.  If the AA trusts the requester, then we're fine
> of course.  In the typical cross-domain scenario, however, I claim
> this is more trust than the AA can bear.  No AA worth its salt will
> respond to a cold query from an SP wielding a DN, even if the SP is
> "trusted" in other respects.
> 
>>  Another way would be for the user to give
>>  a token to the proxy saying that it authorises the proxy to act on its
>>  behalf, and the proxy can present this to the AA.
> 
> Yes, this approach will work, in general.  It is the approach I'm
> advocating, in fact.
> 
>>  However, this later
>>  model will require enhancements to the communications between the user
>>  and the Grid SP, which is probably a route you dont want to go down.
> 
> Having adopted a push model, our project is already far down this path
> (and making more progress than we ever did with a pull model, I might
> add).  (In fact, sometimes I wonder if it's worth belaboring the pull
> model further.)
> 
>>  Note that this issue is not unique to grids. Shibboleth has a similar
>>  problem of determine who are trusted IDPs, and it has solved it in the
>>  unscalable easy way by passing the complete list of trusted IDPs in the
>>  meta data. Not the best choice, but a quick and easy one. So the
>>  solution that Valerio has currently chosen is no different to the one
>>  that Shibboleth has chosen
> 
> No, that's not the whole story, I'm afraid.  In fact, metadata has
> nothing to do with user presence.  The Shib SP queries the AA using a
> transient, encrypted name identifier that the *user* obtained from the
> IdP during the SSO step.  By presenting this identifier to the AA, the
> SP proves user presence.
> 
> If you take away the SSO step and replace the Shib SP by a Grid SP,
> you have precisely the use case that our profile addresses.  But by
> taking away the SSO step, you lose the transient name identifier, so
> the Grid SP is unable to prove user presence.  No Shib AA will respond
> to such a query.
> 
> I doubt I've convinced you, but I've made my point the best I can, so
> I won't try to convince you further :-)  Let me close by proposing the
> following "patch" to our profile:
> 
> Instead of *requiring* a DN, the name identifier in the query should
> be generalized to accommodate the entire certificate (without
> excluding the possibility of a naked DN in those situations where it
> is warranted).  This can be done using <ds:KeyInfo>, something like
> this:
> 
> <saml:Subject>
>  <saml:BaseID xsi:type="KeyIdentifierType">
>    <ds:KeyInfo>...</ds:KeyInfo>
>  </saml:BaseID>
> </saml:Subject>
> 
> where KeyIdentifierType is defined as follows:
> 
> <complexType name="KeyIdentifierType">
>  <complexContent>
>   <extension base="saml:BaseIDAbstractType">
>     <sequence>
>       <element ref="ds:KeyInfo"/>
>     </sequence>
>   </extension>
>  </complexContent>
> </complexType>
> 
> This new name identifier type accommodates either a DN or a
> certificate.  In addition to proving user presence at the Grid SP,
> using a certificate in this way has the extra added benefit that it
> avoids potential DN string matching at the AA, which in and of itself
> is almost sufficient reason to pass a certificate instead of a DN.
> 
> Tom
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************