[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] JPMorgan/RSA message
Glen, Your input are very useful in bringing in a fresh perspective on what we are doing in DSS. Firstly, can I check that I have a proper understanding of the operation of the PSTP protocol. Is the private key used to protect the symmetric keys (referred to as Ke) loaded up to the client system within the Applet / Active X code, or loaded separately into the client system by some other means? Secondly, I like the idea of the Signature Gateway profile. I can see this have a wide number of uses, taking a signature, adding information on its validity and applying a second signature. I could be useful to have the option of adding a trusted time and also information on certificates / CRLs used if necessary to later double-check the validation (this is a technique used in our XAdES profile) on the original signature. Do I understand the proposed operation of the Secure Gateway is an in-line message service. Would this be using SOAP or similar protocol? The DSS currently operates on a request / response with the response going back to the original client. However, I believe such an in-line service would be within our charter and given the general usefulness of such an approach I would hope this would have general support within DSS. Alternatively, the in-lne service could be build on top of the existing request / response service. Finally, regarding the "Embedded Client Authentication Profile", as you say this is close to the existing Entity Seal profile. If we were not hoping to go out for the first stage of agreement (Committee Draft), I would be tempted to include this as an option /subprofile in the entity seal profile. Perhaps we may wish to consider adding this whilst the document is being is going through public review. Nick > -----Original Message----- > From: Glenn.Benson@chase.com [mailto:Glenn.Benson@chase.com] > Sent: 15 October 2004 21:51 > To: dss@lists.oasis-open.org > Subject: Re: [dss] JPMorgan/RSA message > > > > Topic: > Initial brainstorming of "Signature Gateway Profile" and "Embedded Client > Authentication Profile" > > New DSS Profiles: > We require at least one, and possibly two new DSS profiles. The first > profile is the "Signature Gateway Profile". This profile specifies a > server that accepts a signed message from a client. After validating the > request, the server re-signs a message using the server's key. > We call the > profile a gateway because the signing technology used in the request does > not necessarily match the signing technology employed in the > response. The > following use case provides motivation. > > Example Use Case: > Most businesses use a DMZ to separate an internal "safe zone" from an > external network. Sophisticated firewalls or bastion hosts located in the > DMZ validate traffic received from the external network, and forward the > traffic into the "safe zone". In some cases, end-user signs data; and the > DMZ's traffic validation process performs the requisite signature > validation. Servers located in the "safe zone" do not need to re-validate > the end-user's signature because the "safe zone" server trusts the DMZ's > validation. > > The DMZ server forwards all transmissions that it receives from the > end-user regardless of the status of the signature validation. However, > the DMZ server injects a token into the transmission which indicates the > signature validation status. Presumably, the server located in the "safe > zone" merely validates the token, and does not need to validate the entire > end-user's signature. > > The overall security architecture mandates two distinct authentication > infrastructures. The first infrastructure provides an underlying platform > through which the end-user authenticates to the DMZ server via signature > technology. The second authentication infrastructure permits the DMZ > server to authenticate to the server located in the "safe zone". The > business requires the flexibility to handle the technologies, logistics, > and governance of the disparate authentication infrastructures > independently. For example, the business may deploy one-time passwords or > PKI credentials to external end-users; and deploy fixed shared keys to the > DMZ servers and "safe zone" servers. In this example, the DMZ server > handles the relatively complex management task of validating signatures > that originate from a multitude of external clients. The DMZ server may > potentially employ hardware acceleration in an effort to enhance > throughput. The "safe zone" servers; however, merely validate an HMAC > produced by the central server. The relative speed and simplicity of the > HMAC alleviates the "safe zone" servers from any requirement that would > dictate cryptographic acceleration. > > New technologies such as XML firewalls, deep packet inspection firewalls, > and network cryptographic acceleration appliances would be ideal platforms > for hosting a Signature Gateway. > > Signature Gateway Profile: > We may establish a Signature Gateway Profile under the auspices of DSS. > The Signature Gateway Profile transforms the end-user's signature, into a > token produced by the Gateway Server. We may specify the token > in the form > of an XMLDSIG-compliant signature. We should explicitly note that XMLDSIG > permits HMAC. The profile should allow a configuration in which the token > is a signature computed over the original, end-user's signature. This > configuration would free the "safe zone" server from the requirement to > validate message digests of the original data payload. > > >From the perspective of syntax, the Signature Gateway Profile closely > resembles the Entity Seal Profile. However, the profiles differ in their > requirements for the security binding. The following two requirements of > Entity Seal's security binding (Section 2.6.1) would not be present in the > Signature Gateway Profile. > i) Authenticate the requester to DSS server > ii) Protects the integrity of a request, response and the association of > the response to the request > Instead, both of these requirements would be satisfied within the DSS > request, through the use of a signature. > > 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 motivating > 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 an > "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 would > explicitly specify an OTP parameter. > > > Treasury and Security Services Global Client Access - Tel 978 805 1046 > > > Glenn Benson > > To: > dss@lists.oasis-open.org > 10/13/2004 10:11 cc: > > AM Subject: Re: [dss] > JPMorgan/RSA message(Document link: Glenn Benson) > > > > > > > > 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_wo > rkgroup.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_wor > kgroup.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_wor > kgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]