holder-of-key or sender-vouches SAML token?
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. 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. An RP is obliged to reject the SAML token in that case. Here's an example of a SAML token with holder-of-key subject confirmation: http://www.globus.org/mail_archive/gridshib-user/2008/05/msg00011.html 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. Alternatively, the proxy certificate could be constructed such that its key is the same key bound to the EEC. In that case, the SAML holder-of-key subject confirmation requirement would be met since all the bound keys (EEC, proxy, SAML) are the same. Thoughts? Tom
hi, On 5/8/08, Tom Scavo <trscavo@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? 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). 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.
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)? An RP is obliged to reject the
SAML token in that case.
Here's an example of a SAML token with holder-of-key subject confirmation:
http://www.globus.org/mail_archive/gridshib-user/2008/05/msg00011.html
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. 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. In that case, the SAML holder-of-key subject
confirmation requirement would be met since all the bound keys (EEC, proxy, SAML) are the same.
Regards, Weizhong
Hi Weizhong, On Fri, May 9, 2008 at 9:31 AM, wz qiang <weizhongqiang@gmail.com> wrote:
On 5/8/08, Tom Scavo <trscavo@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. 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.
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.
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.
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. 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. 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.
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? Tom
hi Tom, :) I more or less misunderstood your point initially. On 5/9/08, Tom Scavo <trscavo@gmail.com> wrote:
Hi Weizhong,
On Fri, May 9, 2008 at 9:31 AM, wz qiang <weizhongqiang@gmail.com> wrote:
On 5/8/08, Tom Scavo <trscavo@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. 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.
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.
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.
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.
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. 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.
I guess we have to if we need to use proxy certificate.
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?
Thanks, Weizhong
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@gmail.com> wrote:
On 5/8/08, Tom Scavo <trscavo@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@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@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 *****************************************************************
On Sun, May 11, 2008 at 7:45 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
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?
The AA doesn't have any choice with respect to the name identifier since the query completely determines the name identifier that the AA MUST use in the assertion. The <SubjectConfirmation> element, on the other hand, is up to AA's discretion. It essentially tells the RP what it must do to confirm the subject (and therefore accept the assertion). So the question is: What should the RP be instructed to do to confirm the subject? Rephrasing the question in terms of VOMS: What does an RP need to do to accept a VOMS AC? The SAML assertion should be profiled similarly, I suspect. Tom
Hi Tom the answer to your question is that the RP should authenticate the subject itself and check that the subject is the same as the holder mentioned in the attribute assertion. But how the authentication is done cannot be determined by the AA I am afraid. It is not within its remit, and has somehow mixed up the trust models. Remember that the RP is in charge of the trust model and deciding who he trusts. So the RP is the correct entity to determine how to authenticate the subject, and how to validate the assertions from the AAs. The AA might provide advice to the RP, and even policy information to (try to) control use of the assertion, but the RP can choose to ignore the whole lot of it and do what it wants with the assertion. You have two modes of access to the AA, the user himself and a third party. When the user accesses the AA, the AA can put something in the attribute assertion to say how it authenticated the user, and advise the RP to do the same. When the RP accesses the AA and asks for assertions about the subject, the AA cannot in general provide any info about how the subject should be authenticated by the RP. The subject might use a Kerberos token, un/pw, proxy cert or anything else in general. In your case, if this is an X.509 profile, then you can assume that PKIs and proxy certs will be used, so the AA could advise the RP to check that the DN in the assertion matches the DN in the subject's certificate. this would then be identical regardless of whether it was push or pull or ACs or SAML assertions. regards David Tom Scavo wrote:
On Sun, May 11, 2008 at 7:45 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
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?
The AA doesn't have any choice with respect to the name identifier since the query completely determines the name identifier that the AA MUST use in the assertion. The <SubjectConfirmation> element, on the other hand, is up to AA's discretion. It essentially tells the RP what it must do to confirm the subject (and therefore accept the assertion). So the question is: What should the RP be instructed to do to confirm the subject? Rephrasing the question in terms of VOMS: What does an RP need to do to accept a VOMS AC? The SAML assertion should be profiled similarly, I suspect.
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@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 *****************************************************************
participants (3)
-
David Chadwick -
Tom Scavo -
wz qiang