RE: Security protocols for TRP

[Krishna Sankar <ksankar@cisco.com>]

PY/CF,

	Prasad, thanks for the thoughts. They echo what I was thinking of. Instead
of embedding again, I will summarize :

	1.	CPP and to an extent CPA will have the possibilities. But the TRP
message should contain, in the envelope, what method was actually used (for
signature, encryption) and possibly the artifacts used (certs et al) as
well. This way, the application can use this information in more than one
way - authentication, reject message, authorization et al.

	2.	An important part of non-repudiation is the audit trail and persistence
of the messages (I think the law requires for 7 years). I agree with Prasad
that the MSH and the application should do it's own persistence for proving
the non-repudiation aspects. Yes, this could get more complex. What we could
do is to provide simple mechanisms to allow persistence at the MSH layer.
The application can have it's own persistence.

	3.	Chris, one suggestion for the MSH<-> application interaction is thru the
envelope. I do not know how this will workout. The good news is that if we
come up with a scheme, we can test if it works for the RegRep security. Even
if the information is available in CPP/CPA, it is always better for the MSH
to include the information "real-time".

	cheers

	I hope I am not spamming the three lists, especially the folks who are
subscribed to more than one list ! Any suggestions ?

> -----Original Message-----
> From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
> Sent: Thursday, December 14, 2000 6:39 PM
> To: christopher ferris
> Cc: Krishna Sankar; ebXML Transport (E-mail);
> 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>
>
> > >         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
> > >
> > >