[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]