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

[Trevor Perrin <trevp@trevp.net>]

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