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

wz qiang weizhongqiang at gmail.com
Fri May 9 09:30:47 CDT 2008


hi Tom,
:) I more or less misunderstood your point initially.


On 5/9/08, Tom Scavo <trscavo at gmail.com> 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.  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-authz-wg/attachments/20080509/8c7489a2/attachment.html 


More information about the ogsa-authz-wg mailing list