RE: [dss] Representing requestor's identity (As a signed attribute ofsignature)

["Nick Pope" <pope@secstan.com>]

Trevor,

You are wanting to use SAML as a general structure used by DSS.

I strongly suggest that we use the SAML structure when the user is
authenticated to the DSS using a authentication already wrapped in SAML.  If
other methods are used for presenting the authentication to the DSS, eg the
WSS UserNameToken, then this should be provided.

In addition, where it is not required to pass on an identity in the form
that it was authenticated to DSS there should be a syntax for representing
the name which allows for the range of name forms that can occur.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 29 April 2003 20:02
> To: Anthony Nadalin; dss@lists.oasis-open.org
> Subject: RE: [dss] Representing requestor's identity (As a signed
> attribute ofsignature)
>
>
> At 03:50 AM 4/29/2003 -0500, Anthony Nadalin wrote:
>
> > >Are you saying the DSS could be a KDC, and issue a ticket to the client
> >and
> > >then hmac-sign with the symmetric key inside the ticket?  If
> so, since the
> >
> > >DSS is signing with the client's key, wouldn't it be more
> appropriate to
> > >put the Kerberos ticket inside the signature's ds:KeyInfo?
> >
> >The requirement is to be able to use Kerberos with XML Signature, so the
> >DSS could
> >be a KDC. Its a little more complicated then how you describe. But
> >basically the DSS
> >MUST include an XML Signature <ds:KeyInfo> containing a ticket
> >identifying the security context token that was established
>
> Sure, that's fine.  See the response I just made to Nick, though.  I
> intended this thread, and 3.2.1 of the requirements doc, not to discuss:
>   -  how to authenticate to the DSS, or
>   -  how to sign using different types of KeyInfo
>
> but:
>   -  If a DSS signing service is signing with a key that is not uniquely
> bound to the requestor, what type of data does the DSS service need to
> attach to the signature as a signed attribute so that the relying party
> will know the client's identity, and possibly also know facts
> about how the
> client authenticated.
>
> I suspect your concerns about the limiting nature of SAML are because you
> don't want to limit the methods used by a client to authenticate
> to the DSS
> service, or by a service to sign.  Those are reasonable concerns, but
> they're misplaced: using SAML as a signed attribute to say "this
> is how the
> client authenticated" imposes no constraints on how the client
> authenticates or how the server signs.
>
>
> > >If the schema was general enough that other forms of "authentication
> > >assertions" could be defined later besides SAML, but we initially only
> > >supported SAML, would that be good enough?
> >
> >No, I would like to see the base being:
> >
> >- Simple name string
> >- RFC 3280/X.509 general name (possibly encoded as an LDAP string)
> >- SAML Assertion
> >- WSS UsernameToken
> >- Kerberos
> >- Other name forms to be identified at a later date
>
> I agree with the first 3, for identifying the requestor or how he
> authenticated.
>
> As for WSS UsernameTokens and Kerberos tickets: If you want to
> use them to
> authenticate to a DSS, that's fine.  If you want to use them inside a
> KeyInfo to identify the signing key, then we're not doing anything to
> preclude that.
>
> But if you want to use those things to represent the identify of the
> requestor as a signed attribute of a signature that was produced
> with some
> other key, then I don't think that makes much sense.
>
> So hopefully we've just been talking about different things.
> Maybe if you
> defined the requirements or use cases you want in terms of
> Kerberos and WSS
> support, then we could examine the requirements doc and make sure we can
> support them?
>
> Trevor
>
>
>