[OGSA-AUTHZ] holder-of-key or sender-vouches SAML token?

[David Chadwick]

Hi Tom

comments below.

One overall comment is this. If the PIP is receiving signed SAML 
assertions to validate, then it should be able to work in either push or 
pull mode without it making any difference. The PIP should either be 
given the assertion or pull it itself. Either way the validation process 
should be the same. So if your model does not cater for this, then I 
would say that the model needs updating. (Note that that OGSA Authz 
model does cater for this) If your model does cater for this, but the 
SAML assertions do not (because they are different in the push and pull 
cases) then I would say the assertions need changing to be the same in 
both cases.

The other point is that the validation process should work regardless of 
whether the user pulled the assertion himself, or whether a grid 
container pulled it for him. The assertion should be the same, in both 
cases assigning particular attributes to a particular user. Who did the 
pulling is another issue and should not be of concern to the validation 
process, but only to the AA that is issuing the assertion.


Tom Scavo wrote:
> Hi Weizhong,
> 
> On Fri, May 9, 2008 at 9:31 AM, wz qiang <weizhongqiang at gmail.com> wrote:
>> On 5/8/08, Tom Scavo <trscavo at gmail.com> wrote:
>>> There's a problem with the Attribute Exchange Profile it seems.  If
>>> you bind a VOMS-SAML token to a SOAP message and authenticate via
>>> WS-Security SAML Token Profile, everything is fine because the key
>>> bound to the SAML token is the same key presented to the RP.
>> "the key bound to the SAML token is the same key presented to the RP", here
>> you meant the the key bound to SAML Token is the same key which signs the
>> VOMS-SAML token?
> 
> No.  The use case involves a user who presents an end-entity
> certificate to the VOMS-SAML server, and then later presents that same
> certificate to the RP. 

It would not be the same key/certificate would it, if a proxy cert was 
used to the RP and not a proxy to the SAML server.

  The VOMS-SAML server binds the user's key (or
> the entire certificate, it doesn't matter) to the SAML token.  This is
> called holder-of-key subject confirmation.

I would say dont do that. Simply put the DN in the SAML assertion. You 
dont need the key if you have a proper trust infrastructure.

> 
>> If so, I can not see any real scenario for this. The
>> VOMS-SAML token (or any other attribute token) should be signed by some AA,
>> but the "hold-of key" situation in SAML Token (WS-Security) should present
>> the principle of the identity (which means should be the identity
>> certificate which signed by some CA).
> 
> The SAML token is signed by the VOMS-SAML server, yes, but that's not
> relevant to the point I'm trying to make.  In this use case, the user
> authenticates to the RP using the same credential used to obtain the
> SAML token.  By proving possession of the private key associated with
> the certificate, the user also satisfies the holder-of-key subject
> confirmation in the SAML token since the key in the token is the same
> as the key in the certificate.

Understood, but I dont see why it will always be the same key, esp. when
proxy certs are used in multiple delegations in a chain.

> 
>>>  However,
>>> if you bind a VOMS-SAML token to a proxy certificate, there are
>>> problems since the key presented to the RP is different than the key
>>> bound to the SAML token, and so the holder-of-key subject confirmation
>>> on the assertion is not satisfied.

and this will also be the case in a long delegation proxy chain, wont it?

>> Why is it a problem here? Why can't we just put VOMS-SAML token into proxy
>> certificate, and look it the same way as traditional VOMS AC (attribute
>> certificate)?
> 
> The VOMS-SAML token as profiled is a holder-of-key token whereas the
> VOMS is a sender-vouches token.  The SAML token is stronger than the
> AC.

Its not cryptographically stronger if the same crypto algs are used in
both cases. You might argue that it is stronger from a trust perspective
since the RP knows that the user holds the same key now as he held when
he contacted the AA for the SAML assertion. But I think it is a spurious
argument. If the AA is trusted (but acts fraudulently) then it could put
the wrong attributes in the assertion. So then how "strong" does that
make the SAML assertion with the holder of key token? Its worthless,
since the attributes are wrong. So dont worry about the strength of 
trust in the subject field.
Everything depends upon the trustworthiness of the AA to put the correct
info into the SAML assertion.

> 
> In this case, the user proves possession of the private key associated
> with the proxy certificate, but that leaves the key in the SAML token
> unconfirmed. 

So what? You are trusting the AA to put correct info in there.
So it can just as well put the user DN in there instead of or as well as
the key.

  The key in the SAML token is the same as the key in the
> end-entity certificate, not the proxy certificate.
> 
>>> Now a VOMS AC is essentially a security token with sender-vouches
>>> subject confirmation, so I wonder if the VOMS-SAML assertion should
>>> have sender-vouches subject confirmation as well.
>> I agree.
> 
> That requires a change to the Attribute Exchange Profile, I'm afraid.

Why not scrap the confirmation field anyway? Just have the subject DN.
It is enough isnt it?

> 
>>> Alternatively, the
>>> proxy certificate could be constructed such that its key is the same
>>> key bound to the EEC.
>> The same as above, the AA and CA should not be mixed, I guess.
> 
> See my comments above.  The issue I'm raising here has nothing to do
> with the signature on the token.  The issue is what confirmation
> method to use on the SAML token?  In particular, what are the
> consequences of downgrading the confirmation method from holder-of-key
> to sender-vouches?

Probably nothing in my opinion. You first need to describe your entire
trust model, and who you trust for what. And then it will become
apparent if there is a difference in putting a key or a DN or a cert in
a SAML assertion.

It is the lack of a fully worked out trust model that caused some folk
to require secure time stamps from third parties to accompany attribute
assertions, when they were trusting the sender with the attributes but
not with the time that accompanied them! This is twisted thinking.

regards

David





> 
> Tom
> --
>   ogsa-authz-wg mailing list
>   ogsa-authz-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
> 

-- 

*****************************************************************
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

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