RE: [dss] Authentication in DSS

[John Messing <jmessing@law-on-line.com>]

Can we include simple usernames and passwords, perhaps with requirements as to security for transportation to and storage at the DSS server, in 2? 

---------- Original Message ----------------------------------
From: Simeon Falk Sheye <Simeon.Sheye@cryptomathic.com>
Date:  Tue, 28 Jan 2003 10:10:10 +0100

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