Re: Security protocols for TRP

[Martin W Sachs <mwsachs@us.ibm.com>]

Please see my comments (MWS:) below.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Prasad Yendluri <pyendluri@webmethods.com> on 12/14/2000 09:38:33 PM

To:   christopher ferris <chris.ferris@east.sun.com>
cc:   Krishna Sankar <ksankar@cisco.com>, "ebXML Transport (E-mail)"
      <ebxml-transport@lists.ebxml.org>, ebxml-ta-security@lists.ebxml.org,
      ebxml-regrep@lists.ebxml.org
Subject:  Re: Security protocols for TRP



Please see below my few cents  in <PY>..

christopher ferris wrote:

> Krishna,
>
> Some comments below.
>
> Cheers,
>
> Chris
>
> Krishna Sankar wrote:
> >
> > David,
> >
> >         Couple of questions (Actually more !) :
> >
> >         1.      Will the layers above the TRP (e.g.. Application layer)
know that the
> > (received) message was signed and encrypted ?
>
> This depends. It is our intent to have the CPA define/describe the
packaging
> and security aspects that the parties agreed to employ. If the scheme
> employed is to delegate the signing of the header/payload to the MSH
> (using XMLDSIG) then the answer would be no, although we should probably
> discuss how the MSH should interface with the application/application
services
> layer above to communicate signature validation info, etc.
>
> If the payload is signed/encrypted with a MIME-based approach (S/MIME
> or PGP/MIME) then this is completely within the domain of the
> application or application services layer to process (validate
> signature and/or decrypt with private key, etc.)
>
> Again, our intent is to capture all of this information in the CPP/CPA.

<PY> It is possible for the CPA to specify > 1 valid possibilities,
including
signing/encrypting/both and the specific mechanisms (S/MIME, PGP/MIME,
XMLDSIG etc.) to be used.
Which particular one is employed by a message instance needs to be
identified somewhere. CPP/CPA
may not be enough. I think this needs to be captured in the envelope. </PY>

MWS:  If the security parameters may be different for each message
definition, the security parameters can be attached to the message
definitions in the CPA, i.e. to <Request> or <Response> in each business
transaction.  Allowing each instance of the same message definition to have
different security parameters would indeed require specifying this in the
message envelope.  Is allowing each instance of the message definition in
the same CPA to have different security parameters really necessary?

> >         2.      On the flip side, I assume the layers above can specify
the requirement
> > for encryption and signature when sending a message.
>
> That would again be in the CPA/CPP. The BPM specification actually
determines
> the required security characteristics (non-repudiation, confidentiality,
> etc.) which are to be employed by the runtime. This is mapped/matched
> to a DeliveryChannel (DocExchange+Transport) which can support these
> characteristics which both parties can support (e.g. sending and
> receiving DeliveryChannels must support the same set of features). The
CPA then
> describes how each message will be treated... Of course, all of this
> is dependent upon the application software (or application services
> software) also being able to read the CPA so that it "knows" how
> to handle sending/receiving messages, etc.

<PY> Again this would accommodate > 1 valid choices/combinations </PY>

> >         5.      On the question of non-repudiation, does the MSH
perform the persistence
> > or is it a function of the application ? Thinking this thru, if the app
has
> > to do the (non-repudiation related) persistence, it also needs to get
the
> > message as received and also the decrypted message. Am I making sense ?
>
> Not sure I follow that one...

<PY> Since there is a choice to sign just the payload/headers or both,
non-repudiation becomes
really subjective here. Both MSH and the application should persist the
relevant parts as
applicable; MSH the entire message (for just headers/entire message signed
case) and the payload
by the application for the payload signed case, IMHO.</PY>

> >         6.      The next one is, how does non-repudiation happen on the
sending side ?
>
> In the security f2f, we identified two aspects of non-repudiation.
> non-repudiation of origin (signing the message) and non-repudiation
> of receipt (returning an ack which is signed and includes the signed
> digest of the original message). On the sending side, the message
> must be signed.
>
> Now, there are really two types of signing involved here. If the
> application holds the signing key, then IT has to be the entity which
> performs the non-repudiation function (I believe that this was also
> discussed during today's con-call). This would then involve MIME-based
> signing of the payload object and an application-level non-repudiation
> ack message (a BUSINESS message, not an MSH ack).

<PY> Whene there is a choice (architecturally) to sign either just the
headers / payload or
both, non-repudiation aspects would be more complex than this..</PY>

> >
> > cheers
> >
> > > -----Original Message-----
> > > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > > Sent: Thursday, December 14, 2000 4:29 PM
> > > To: ebXML Transport (E-mail)
> > > Subject: Security protocols for TRP
> > >
> > >
> > > This note outlines how the Messaging Services spec should use digital
> > > signature technology to:
> > > 1. Digitally sign the ebXML Header,
> > > 2. Bind together the ebXML Header and the ebXML Payload
> > > 3. Encrypt the ebXML Payload.
> > >
> > > This is based on the consensus reached in the TRP conference call
this
> > > morning.
> > >
> > > It is proposed that this description is discussed on the list and a
vote
> > > taken at next weeks conference call.
> > >
> > > Note that this is a outline rather than the actual words that
> > > will go in the
> > > spec.
> > >
> > > Here's the description ...
> > > =======================
> > >
> > > EBXML HEADER SIGNATURE CREATION
> > > A digital signature, within the ebXML header, conforming to the W3C
XML
> > > Signature specification MAY be used by a MSH that is sending a
message to
> > > digitally sign:
> > > 1. the ebXML Header Document,
> > > 2. the complete ebXML Payload, or
> > > 3. the ebXML Header Document and the complete ebXML Payload so as to
bind
> > > the ebXML Header Document and the ebXML Payload together
> > >
> > > When the XML Signature is created by the From Party's MSH, it must
contain
> > > an XML Signature Manifest that contains digests of:
> > > 1. TBD ... we must itemize what gets signed including any
> > > references to the
> > > ebXML Payload
> > >
> > > When an Intermediate Party is forwarding a message to another
> > > Party then it
> > > must contain an XML Signature Manifest that contains digests of:
> > > 1. TBD ...
> > >
> > > EBXML HEADER SIGNATURE VALIDATION
> > > A MSH that receives a Message that contains a signature in the
> > > ebXML Header
> > > MAY verify the signature if the CPA indicates that signature
validation is
> > > required.
> > >
> > > Verification of a signature must include:
> > > *     verification of each digest in the signature Manifest ...
> > > *     etc, etc.
> > >
> > > If the verification of the signature fails then the the MSH that
verifies
> > > the message MUST send an Error Message to the From Party that created
the
> > > Message.
> > >
> > > If the verification of the signature succeeds then it MAY be used by
a
> > > recipient or reader of the Message to prove:
> > > 1. the authenticity of the Party that sent the Message. This may be:
> > >   a) the From Party that created the Message, and/or
> > >   b) the Sender of the Message
> > > 2. what data and information forms the message
> > >
> > > If the authenticated sender of the message is a Party that is
unacceptable
> > > to the recipient of the Message, then the Party that verified the
Message
> > > MUST send an Error Message to the From Party that generated the
Message.
> > >
> > > EBXML PAYLOAD SIGNATURES
> > > Data contained within the ebXML Payload may be signed using
> > > either: W3C XML
> > > Signature, S/MIME, or PGP/MIME.
> > >
> > > If W3C XML Signature is being used, then it is RECOMMENDED that the
> > > following conventions are followed:
> > > *     TBD
> > >
> > > If S/MIME is being used, then it is RECOMMENDED that the following
> > > conventions are followed:
> > > *     TBD
> > >
> > > If PGP/MIME is being used, then it is RECOMMENDED that the following
> > > conventions are followed:
> > > *     TBD
> > >
> > > =======================
> > > ISSUES
> > > A few issues ...
> > > 1. Do we want to allow the MSH to sign data that is carried outside
of the
> > > message (e.g. on the web) but is referenced by the Manifest. My guess
is
> > > that we probably do, but how this is done is implementation
dependent.
> > > 2. Do we need to spell out how the Payload should be signed, or
> > > do we leave it to the application protocol designer?
> > > 3. If the authenticated sender of an ebXML Header Message is a
> > > party who is unnacceptable, do we really want to let the sender of
the
> > > messaage know that  they are "unacceptable".
> > >
> > > Regards
> > >
> > > David
> > >
> > >
> > > Product Management, Commerce One
> > > 4400 Rosewood Drive, Pleasanton, CA 94588, USA
> > > Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> > > mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
> > >
> > >