[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] JPMorgan/RSA message
Can you make a patent disclosure at this point?
regards, Frederick
Frederick Hirsch
Nokia
-----Original Message-----
From: ext Glenn.Benson@chase.com [mailto:Glenn.Benson@chase.com]
Sent: Wednesday, October 13, 2004 12:35 PM
To: dss@lists.oasis-open.org
Subject: RE: [dss] JPMorgan/RSA message
Yes, there are IP issues and claimed patents. I would like to suggest
that we proceed with the investigation into the profile. Before we get
too far along, I will initiate the work toward resolving the IP issues
in a manner suitable for DSS.
Glenn
John Messing
<jmessing@law-on- To:
Glenn.Benson@chase.com
line.com> cc:
dss@lists.oasis-open.org
Subject: RE: [dss]
JPMorgan/RSA message
10/13/2004 10:29
AM
Are there any IP issues surrounding this profile? Either use of IP of
others (e.g., OTP), or claimed patents that should be disclosed?
> -------- Original Message --------
> Subject: Re: [dss] JPMorgan/RSA message
> From: Glenn.Benson@chase.com
> Date: Wed, October 13, 2004 7:11 am
> To: dss@lists.oasis-open.org
>
> Trevor,
>
> Yes, your summation is correct; however, the syntax is:
>
> PSTP Signature = 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
>
>
>
>
> Trevor Perrin
> <trevp@trevp.net> To:
<dss@lists.oasis-open.org>
> cc:
> 10/12/2004 03:30 Subject: Re: [dss]
JPMorgan/RSA message
> AM
>
>
>
>
>
>
> 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
this
> >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
> >could
> 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 = 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-compliant
> >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
> >security 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.
> >This structure cryptographically fuses its elements into a single,
> >atomic
PSTP
> >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
other
> >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
> >sender,
> >(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
> >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_workgrou
p.
> > 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_workgrou
>p.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_workgroup
.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_workgroup
.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_workgroup
.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_workgroup
php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]