OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] JPMorgan/RSA message


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