RE: [dss] Authentication in DSS

[Robert Zuccherato <robert.zuccherato@entrust.com>]

Title: RE: [dss] Authentication in DSS

Burt;

It seems to me that in order to deal with the security requirements of the various environments where a digital signature service is likely to be deployed, any protocol that we develop should support:

1)  no authentication (well, really authentication provided by other means, or another layer, for example over TLS),
2)  authentication directly to the server within the protocol (using WS-Security maybe?),
3)  authentication using an authentication authority (using SAML?),
4)  combinations of above (in order to allow the two-authentication policy).

If others agree, I think this should be added as a requirement.

        Robert.

> -----Original Message-----
> From: Kaliski, Burt [mailto:BKaliski@rsasecurity.com]
> Sent: Thursday, January 16, 2003 2:11 PM
> To: 'dss@lists.oasis-open.org'
> Subject: [dss] Authentication in DSS
>
>
> At the January 13 teleconference, I raised the question of
> how requesters
> will be authenticated to a DSS service.
>
> In some digital signature policies, authentication steps occur at two
> levels, initially to establish the valid identity corresponding to the
> signer's session and subsequently for individual digital
> signatures that are
> to be applied. In a smart card environment, this corresponds
> to the policy
> where a second PIN is required to approve a digital signature.
>
> If the DSS service relies on an authentication authority
> (e.g., SAML), the
> two-authentication policy could be achieved via two separate
> authentications. Alternatively, the DSS service could manage its own
> authentication (e.g., accept a PIN) in addition to a SAML
> assertion from an
> authentication authority.
>
> Key-splitting raises interesting authentication requirements.
> If the DSS
> service cryptographically splits its signing key between two
> servers, then
> each server needs assurance that the user has been
> authenticated. If both
> servers rely on a single authentication authority, however,
> then compromise
> of the authentication authority would undermine the benefits of
> key-splitting.
>
> I'd be interested in hearing the group's suggestions on these
> authentication
> issues.
>
> -- Burt Kaliski
> RSA Laboratories
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>