RE: [dss] Authentication in DSS

I agree with Robert on all four items and think they should become requirements.

It seems to me that item 2 is particularly important, because this allows the signature service to be implemented without

making assumptions about the security of a separate authorisation service.

I would also like to add that the protocol should accomodate two-step authentication (i.e. authentication using two server roundtrips),

in order to support challenge-response authentication. 

If others agree I think we should add this as a requirement as well.

Simeon Sheye

Cryptomathic

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:] 

> Sent: Thursday, January 16, 2003 2:11 PM 

> To: '' 

> 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> 

>