[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
We may specify that the Signature Gateway Profile accept any
XMLDSIG-compliant signature in the DSS request. However, we recommend =
an
explicit reference to XMLDSIG-compliant PSTP technology as one motivati=
ng
example. PSTP's one-time password technology greatly benefits from
centralization.
Other DSS Profiles:
In addition to the Signature Gateway Profile, we may wish to consider a=
n
"Embedded Client Authentication Profile". The Embedded Client
Authentication Profile would be nearly identical to the Entity Seal
profile. The difference is that the security binding would not require=
an
authentication of the requester to the DSS server. Rather, profile wou=
ld
explicitly specify an OTP parameter.
Treasury and Security Services Global Client Access - Tel 978 805 1046
=
=20
Glenn Benson =
=20
To: dss@lists.oasis=
-open.org =20
10/13/2004 10:11 cc: =
=20
AM Subject: Re: [dss] JPMor=
gan/RSA message(Document link: Glenn Benson) =20
=
=20
=
=20
Trevor,
Yes, your summation is correct; however, the syntax is:
PSTP Signature =3D Enc(Ke,K1|K2) | Enc(K1,OTP|Mac(K2,Data))
Some MACs have cryptographic vulnerabilities attributed to data hiding.=
So, we covered the MAC in the second encryption. Also, we provide an
elliptical curve option.
Glenn
=
=20
Trevor Perrin =
=20
<trevp@trevp.net> To: <dss@lists.oas=
is-open.org> =20
cc: =
=20
10/12/2004 03:30 Subject: Re: [dss] JPMo=
rgan/RSA message =20
AM =
=20
=
=20
=
=20
At 11:59 AM 10/9/2004 -0400, Glenn.Benson@chase.com wrote:
>Trevor,
>
>Thanks for your questions. I will answer the first two questions in t=
his
>e-mail. I will send a subsequent e-mail answering your second two
>questions about JPMorgan's and RSA's ideas about how PSTP and OTP coul=
d
fit
>into DSS.
[...]
Thanks Glenn,
My understanding is something roughly like:
Ke : RSA public key, used to encrypt K1 and K2
K1 : symmetric key, used to encrypt OTP
K2 : symmetric key, used to MAC document
PSTP Signature =3D Enc(Ke,K1|K2) | Enc(K1,OTP) | Mac(K2,Data)
I'm looking forward to your thoughts on DSS integration.
Trevor
>Glenn
>
>PSTP Technical Executive Summary
>The Portable Security Transaction Protocol (PSTP) is an XMLDSIG-compli=
ant
>vehicle used for signing documents with One-Time Passwords (OTP) such =
as
>RSA SecurID. A motivation of PSTP is to address some logistic
impediments
>in the Public Key Infrastructure (PKI). The PKI provides good securit=
y
>when it adequately protects its private keying material. Hardware
Security
>Modules (HSMs) address this issue in servers that reside in protected =
data
>centers; and the client may address the issue using smart cards, USB
>tokens, or HSMs. However, some clients may prohibit these hardware
>solutions due to the necessary electronic conduit between the private
>keying material, and the data being subject to the digital signature.
>
>The technical issue addressed by PSTP is that an OTP does not bind the=
>private authentication credential to the data being signed. PSTP
envelopes
>the OTP and the target data into a single cryptographic structure. Th=
is
>structure cryptographically fuses its elements into a single, atomic P=
STP
>signature.
>
>A PSTP signature has three components:
>- The Authentication Component transfers authentication credentials =
from
>the client to the recipient. A symmetrically keyed algorithm protects=
the
>confidentiality of the authentication component.
>- The Message Integrity Component is an HMAC computed over the target=
>dataset.
>- The Key Management Component communicates the keys used for the oth=
er
>two components securely, while binding the two keys together. PSTP
>specifies RSA-OAEP and elliptical curve technology to bind the
>authentication component and message integrity component keys into an
>atomic structure.
>
>PSTP focuses on message authenticity which (i) authenticates the sende=
r,
>(ii) protects the integrity of the communication, and (iii) protects
>against replay attacks. The XMLDSIG-compliant structure provides
>compatibility with standards such as DSS.
>
>
>
>
>
> Trevor
> Perrin
>
> <trevp@trevp.net> To:
> <dss@lists.oasis-open.org>
> cc:
>
> 10/07/2004 03:46 Subject: Re: [dss]
> JPMorgan/RSA message
> AM
>
>
>
>
>
>
>
>
>
>
>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 y=
ou
>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 downst=
ream
>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 serve=
r
>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 signa=
ture
> >mechanism that leverages one-time password technology. The PSTP
> >specification is XMLDSIG-compliant. While one may employ either PST=
P 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 secur=
ed,
> >two-factor authentication token such as RSA SecurID without installi=
ng
> >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 disconnect=
ed
> >one-time password device, and enters the current value into an Apple=
t or
> >ActiveX control through a browser interface. The Applet or ActiveX
>control
> >cryptographically processes the user's data in accordance to the PST=
P
> >specification, and applies the signature. The user uploads the sign=
ed
> >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 arr=
ival
>at
> >the destination. The proxy interacts with an authentication server =
in
> >order to validate the authentication credential which the proxy extr=
acts
> >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. T=
he
> >advantage of server-based SAML injection is that it does not require=
> >client-based software. However, server-based SAML injection does no=
t
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 locati=
on.
> >However, the disadvantage is that it requires a session-based servi=
ce
>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 a=
n
> >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-Securit=
y.
>The
> >client uploads to a server-based SAML injection service. The servic=
e
> >validates the PSTP signature, and then injects a SAML assertion into=
the
> >payload. The service forwards the modified payload to the destinati=
on.
> >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 th=
e
> >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 simp=
ler
> >utility for validating the binding than would be required for signat=
ure
> >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 t=
he
> >security binding, e.g., via TLS. The current DSS specification suppo=
rts
> >X.509 mutual authentication (Sec. 6.3.2) but not specifically one-ti=
me
> >password authentication for the client; such authentication, e.g., o=
ver
> >SASL, could potentially be added.
> >
> >Alternatively, the binding could be done within the DSS request itse=
lf
>(for
> >instance, in <OptionalInputs>). This has the advantage of providing
> >cryptographic consequential evidence of the signer's intent within t=
he
DSS
> >request. The DSS request itself could contain a one-time password. T=
he
> >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 roste=
r of
> >the OASIS TC), go to
>
>http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgro=
up.
> php.
>
>
>
>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_workgro=
up.php
>.
To unsubscribe from this mailing list (and be removed from the roster o=
f
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgrou=
p.php
.
=
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]