Re: [dss] JPMorgan/RSA message

[Trevor Perrin <trevp@trevp.net>]

Hi Glenn,

A few things about PSTP and its relation to DSS were unclear to me:

  - In the "Document Signature" case, a signature is performed on the 
client side.  Is this a public-key signature?  How is the one-time-password 
used?

  - In the "Web Services Authentication" case, it says "the client executes 
a PSTP signature".  What is a PSTP signature and how is it executed?

  - Where would the DSS sign or verify protocols fit?  I'm guessing you 
could use DSS to produce a "PSTP signature" based on the client 
authenticating to a DSS server with a one-time-password?

  - You talk about DSS in the context of an in-line validation server, 
which validates a signature and then marks the document so that downstream 
parties know it was validated.  DSS is a request/response protocol, so I'm 
curious how you would use it here.  Would the in-line validation server 
call out to a DSS server?  Or would the inline DSS server mark the document 
with a DSS <VerifyResponse> element, so that downstream parties could 
process it as if they had made a <VerifyRequest>?


Trevor



At 05:25 PM 10/4/2004 +0200, Juan Carlos Cruellas wrote:
>Dear all,
>
>I have received the message below sent by Glen asking
>me to forward it to the group.
>
>Regards
>
>Juan Carlos.
>
>-------- Original Message --------
>Subject:        failure notice
>Date:   Mon, 4 Oct 2004 10:05:33 -0400
>From:   Glenn.Benson@chase.com
>To:     administration@lists.oasis-open.org
>CC:     cruellas@ac.upc.es
>
>
>
>Administrator:
>
>My e-mail would not forward.  Please forward to the dss list server.
>
>Thank you,
>
>Glenn Benson
>
>
>
>Standardization Vision
>
>Glenn Benson, JPMorgan
>Burt Kaliski, RSA Security
>
>
>XMLDSIG
>The Portable Security Transaction Protocol (PSTP) is a digital signature
>mechanism that leverages one-time password technology.  The PSTP
>specification is XMLDSIG-compliant.  While one may employ either PSTP or
>PKI in any XMLDSIG scenario, PSTP has some advantages in interactive
>environments; and PKI has some advantages in non-interactive environments.
>In an interactive environment, PSTP allows a user to consult a secured,
>two-factor authentication token such as RSA SecurID without installing
>hardware, customized software, or device drivers on client machines.  One
>may employ PSTP in many different use cases.  As examples, we depict two
>below.
>
>Document Signature:  A user obtains a document, transaction data, or other
>information and applies a signature.  The user consults a disconnected
>one-time password device, and enters the current value into an Applet or
>ActiveX control through a browser interface.  The Applet or ActiveX control
>cryptographically processes the user's data in accordance to the PSTP
>specification, and applies the signature.  The user uploads the signed
>document to a server for verification.
>
>Web Services Authentication:  SAML injection is a technique whereby a
>client makes a request, which may include proprietary authentication
>material.  A proxy intercepts the request prior to the request's arrival at
>the destination.  The proxy interacts with an authentication server in
>order to validate the authentication credential which the proxy extracts
>from the request.  Subsequently, the proxy injects a SAML token for
>subsequent consumption at the destination.
>
>One may deploy SAML injection at either the server or the client.  The
>advantage of server-based SAML injection is that it does not require
>client-based software.  However, server-based SAML injection does not bind
>authentication credentials with the payload until after the payload
>traverses the network.  The advantage of client-based SAML injection is
>that it binds data to authentication material at the client's location.
>However, the disadvantage is that it requires a  session-based service that
>operates on the client's machine.  This service initiates an out-of-band
>authentication invocation which authenticates credentials, and then obtains
>a SAML token for injection into subsequent packets.  PSTP provides an
>alternative to client-based SAML injection.  At the client location, the
>client executes a PSTP signature over a SOAP payload.  The client inserts
>the PSTP signature into the message under the auspices of WS-Security.  The
>client uploads to a server-based SAML injection service.  The service
>validates the PSTP signature, and then injects a SAML assertion into the
>payload.  The service forwards the modified payload to the destination.
>The destination leverages a SAML-aware web services Single Sign-on
>mechanism to authenticate the payload.
>
>DSS
>One signature validation use case deploys the signature validation server
>in-line between the client and the application, as in the case of the
>PSTP-aware SAML injection proxy described above.  First, the client sends a
>message that contains signed information.  The in-line signature validation
>server receives the message and performs the requested validation,
>potentially via a DSS signature validation service.  The signature
>validation server then injects a token, which binds the document and/or
>signature to a validation result code and forwards the binding to a
>downstream application.  The application validates the binding and accepts
>the signed information.  Presumably, the application requires a simpler
>utility for validating the binding than would be required for signature
>validation.
>
>A second aspect of DSS is that it includes a mechanism by which the client
>may submit a request for a signature. There are various ways to bind strong
>client authentication to such a request. This could be done within the
>security binding, e.g., via TLS. The current DSS specification supports
>X.509 mutual authentication (Sec. 6.3.2) but not specifically one-time
>password authentication for the client; such authentication, e.g., over
>SASL, could potentially be added.
>
>Alternatively, the binding could be done within the DSS request itself (for
>instance, in <OptionalInputs>). This has the advantage of providing
>cryptographic consequential evidence of the signer's intent within the DSS
>request. The DSS request itself could contain a one-time password. The
>password could also be combined with the request in various ways, e.g., by
>hashing. PSTP is one example of such a combination that provides a strong
>cryptographic coupling.
>
>
>-
>
>
>
>
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of 
>the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php.