RE: Security protocols for TRP

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

See my replies embedded in the copy of the email 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
*************************************************************************************



Krishna Sankar <ksankar@cisco.com> on 12/14/2000 08:23:48 PM

To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
cc:   ebxml-ta-security@lists.ebxml.org, ebxml-regrep@lists.ebxml.org
Subject:  RE: Security protocols for TRP



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 ?

MWS:  Layers above the TRP should know whether to expect that a given
message (i.e. payload) is signed and/or encrypted since this information is
in the CPA.  It may be worthwhile to have indicators in the message header
to verify that the message is as expected from the CPA as well as to
support applications that don't use a CPA.

     2.   On the flip side, I assume the layers above can specify the
requirement
for encryption and signature when sending a message.

MWS:  For payload, this is specified in the CPA.  If the actual signing and
encryption process are carried out by the messaging service, then the
application will have to specify the security requirement for each message
by means of the messaging service's API.

     3.   The major question is, at the receiving end, have the application
layers
access to the certificate and other artifacts used in the MSH level
encryption and signature ?

MWS:  The application layers should obtain the cerficate and related
artifacts by means of information provided in the CPA.  This information
should be obtained when the CPA is activated and then used with each
message in the business process.

          Just as a background, the registry security service could rely on
the CN
from the certificate used in the security layer, for authentication. But if
the certificate is not visible, then the registry needs to add some more
requirements.

          Also for assuring integrity of the content, the registry needs
the content
signed, which from your scenario, looks like a payload related issue. But
if
you have step "1.5. Sign Payload", then we get the signature capability
from
the message layer. (May be your Issue 2. pertains to the same question)

     4.   Also, how does the MSH know who is "acceptable" and who is
"unacceptable" ? It can know whether the signature passed or failed
(including expired certs) - but anything else is at the application layer,
which is not accesible to the MSH.

MWS:  This point bears on the question of which security functions the MSH
should perform and which should be performed by the application.  Any
security functions which require access to extensive information held in
the application layer should probably be performed by the application
layer.

MWS:  IMPORTANT:  A well-designed B2B server will implement application
functions such as security processing in middleware once for all
applications.

     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 ?

     6.   The next one is, how does non-repudiation happen on the sending
side ?

     Again, IMHO, we do have the luxury of not addressing all these issues
in
this Phase.

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