RE: [dss] Representing requestor's identity

[Anthony Nadalin <drsecure@us.ibm.com>]

>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

>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 don't see anything in these documents about UsernameTokens being used
for
>this.  Could you elaborate?

Username Tokens are one type of security tokens, security tokens may be
signed
or unsigned, security tokens can be used to provide message authentication.

>An authentication assertion needs to represent at least:
>  - name of subject
>  - name of issuer
>  - possibly a cryptographic signature by issuer
>  - how subject was authenticated
>  - when subject was authenticated

So a signed Username Token can meet your requirements (I don't agree with
all
items on your list).

 Anthony Nadalin | work 512.436.9568 | cell 512.289.4122


|---------+---------------------------->
|         |           Trevor Perrin    |
|         |           <trevp@trevp.net>|
|         |                            |
|         |           04/28/2003 05:21 |
|         |           PM               |
|---------+---------------------------->
  >----------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                              |
  |       To:       Anthony Nadalin/Austin/IBM@IBMUS, dss@lists.oasis-open.org                                                                   |
  |       cc:                                                                                                                                    |
  |       Subject:  RE: [dss] Representing requestor's identity                                                                                  |
  >----------------------------------------------------------------------------------------------------------------------------------------------|




At 04:04 PM 4/28/2003 -0500, Anthony Nadalin wrote:

> >I disagree here - I think we should *only* support SAML as far as
> >representing the authentication event goes, since it's the only
well-known
> >technology for doing this (that I'm aware of).  WSS UsernameTokens
aren't
> >intended for this purpose - they don't provide for expressing usernames
in
> >different "name forms", and they don't provide for saying anything about
> >who authenticated the subject, the authentication method, or the
> >authentication time.
>
>Disagree, there are lots of technologies that represent an authentication
>event, Kerberos is one of them.

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?

In other words, the point of identifying the requestor is when the server
is signing with its own key, so it needs some extra step to identify the
client, but if the server is signing with the client's key, such an extra
step isn't needed (for example, if the server had a database of its'
clients' private keys which it used to sign, it wouldn't need to identify
the requestor either).


>Need a extensible mechanism, what you propose is not, so we
>need a way expressing name forms including:
>- 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

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?


>Also who ever told you that UsernameTokens aren't intended for this
purpose
>is wrong, these can and are used as name assertions.

I don't see anything in these documents about UsernameTokens being used for

this.  Could you elaborate?
http://www.oasis-open.org/committees/download.php/1044/WSS-SOAPMessageSecurity-11-0303-merged.pdf

http://www.oasis-open.org/committees/download.php/1046/WSS-Username-02-0223.pdf


An authentication assertion needs to represent at least:
  - name of subject
  - name of issuer
  - possibly a cryptographic signature by issuer
  - how subject was authenticated
  - when subject was authenticated


Trevor