JPMorgan/RSA message

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

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.


-