RE: Security - question about nonrepudiation

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

FYI

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

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
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 08/01/2001
05:25 PM ---------------------------

Martin W Sachs
08/01/2001 04:52 PM

To:   "Collier, Timothy R" <timothy.r.collier@intel.com>
cc:
From: Martin W Sachs/Watson/IBM@IBMUS
Subject:  RE: Security - question about nonrepudiation  (Document link:
      Martin W. Sachs)

Tim,

A few replies below.

Dale is more expert in security than I am, so it would be worth running it
by him as well.

I suggest posting the  email you sent me to the CPPA list for others to
review.

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



"Collier, Timothy R" <timothy.r.collier@intel.com> on 08/01/2001 04:01:08
PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:
Subject:  RE: Security - question about nonrepudiation



Marty,

     I am mostly trying to come up to speed and understand the intent of
the existing structures so, I apologize if I am being overly dense.

MWS:  And I apologize that the set of ebXML specifications is confusing in
the
security area.

In your
new work doc one of the items to be looked at is the nonrepudiation
element,
so I thought I would start trying to understand the issues and start a
discussion around that topic.

MWS:  That's definitely the area with the most problems.

So hence, the thread.  The specific issue,
for me at the start is where each security detail applies.  When I look at
the BPSS+CPP security definitions I get the following hierarchy

Abstract security indicators (or process requirements)


BPSS

MWS:  My problem with BPSS is that there is not enough of a description of
what is
implied by each of the security attributes.  We need clear definitions so
that
an implementation can do the right thing and the CPP-CPA tools can verify
consistency between the attributes in BPSS and the CPP/CPA Characteristics
element
and the IT definitions in the delivery channel.

     isAuthenticated (Document envelope or attachment attribute) -
           a digital certificate is associated with the document
entity
     isConfidential (Document envelope or attachment attribute) -
          is encrypted

MWS:  I believe that isConfidential implies (should state in BPSS ) that
the encryption is
performed above the message service and the document must be delivered
encrypted
to the receiving application.

     isTamperProof (Document envelope or attachment attribute)-
          encrypted message digest and senders digital certificate

     isLegallyBinding (BusinessTransactionActivity attribute) -
          the business transaction is/is not legally binding

MWS:  There was a lot of discussion of isLegallyBinding on the listservers
a few weeks ago.  I believe that the position of the BP team is that
isLegallyBinding is simply a test vs production indicator and not some kind
of legal status issue for the CPA + BPSS instance as a whole.

     isNonRepudiationRequired (businessActivity attribute) -
          must save audit trail
     isNonrepudiationOfReceiptRequired (businessActivity attribute)-
          must digitally sign receiptAcknowledgements (assumes a
receipt ack)
     isAuthorizationRequired (businessActivity attribute) -
          must validate identity of the originator

MWS:  I agree except as commented above.

Given that my business analyst has provided me, the implementer, with a BP
that has the above fields set, I then try to map them into how I am going
to
implement them.

Abstractly I map my requirements (possibly overriding them with my own)

     BPSS                          CPP Delivery Channel
characteristics

isAuthenticated                    authenticated + secureTransport
isConfidential                confidentiality
isTamperProof                 authenticated and confidentiality

isLegallyBinding                   ?
isNonRepudiationRequired      nonrepudiationOfOrigin
isNonrepudiaitonOfReceiptRequired  nonrepudiationOfReceipt
isAuthorizationRequired            authorized
     ?                        secureTransport
     ?                        syncReplyMode

MWS:  These seem OK.


Concretely I implement my requirements. (Here is where I seem to not
understand the uniqueness of the nonrepudiation)


     Delivery Ch.             Implementation Details
authenticated                 TransportSecurity (Transport -
ReceivingProtocol)
                              + NonRepudiation
(DocExchange)

secureTransport                    TransportSecurity
confidentiality                    DigitalEnvelope (DocExchange)
authorized                         ?

nonrepudiationOfOrigin             NonRepudiation (DocExchange)
                               + TransportSecurity

nonrepudiationOfReceipt            NonRepudiation (DocExchange)on an
assumed
acknowledgement
                               + TransportSecurity


My misunderstanding seems to center on the line between authenticated and
nonrepudiation.  The BP seems to indicate that isAuthenticated implies that
a signature is associated with the document, I assume that is an
application
level signature.  So CPP's "authenticated", in trying to meet the BPs
"isAuthenticated", would require the use of the nonrepudiation element.
Likewise, the "nonrepudiationOfXX" implies an application level signature,
so I don't see how the two are different.

MWS:  I think that authenticated by itself only says to check that the
signature
is of whom it is supposed to be.  Nonrepudiation also implies tamperproof
and the
necessary audit trail to prove that the document was sent or received.  It
may well
be that the technology description in the delivery channel is the same for
both and that
authentication and nonrepudiation imply (possibly different) additional
actions
on the part of sender and receiver (application or application-support
functions
in the middleware).

My basic thinking is, if I can,
as an implementer, describe

     document security details
          encryption, and signature
     transport security details
          encryption and endpoint authentication
     business transaction security details
          like authorization and entity authentication
( and maybe some way to describe the ordering of the processing)


haven't I covered all of the bases?

MWS:  You have covered a lot of bases. I am not sure if there are more but
running it by the whole team will flush out more bases if there are any.

Nonrepudiation is then covered by the
document signature.  Whether I keep a log is entirely an internal issue and
my trading partner should neither need to know nor care.

MWS:  On the last sentence, I partly disagree.  I believe that the
implication
of nonrepudiation is that both parties agree that each will retain enough
information for audit purposes.  That agreement is probably embodied in the
attributes in the BPSS instance document and CPA Characteristics element.
Whether it is a log or some other realization is, of course, an internal
matter.


Thanks for your help,

          Tim







-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, August 01, 2001 8:27 AM
To: Collier, Timothy R
Subject: RE: Security - question about nonrepudiation



Tim,

As I said in the reply that you appended to your posting, what the
nonrepudiation element defines is the variables that have to be agreed to
between two parties in performing XML DSIG - hash function, signature
algorithm and certificate reference.  These details are not defined in the
BPSS instance document.  It only says "thou shalt sign".  My earlier reply
appended below points out other open matters and loose ends that have to be
dealt with under message security.

The authenticated attribute of the Characteristics element does not spell
out the details of how to authenticate. It only says whether authentication
is or isn't required.  The "how to" details that have to be agreed to
between the parties belong in the document-exchange section.

The attributes of Characteristics are simply counterparts of the same
attributes in the BPSS instance document.  There purpose is to possibly
override the values in the BPSS instance document.  The document-exchange
section has to spell out the "how to" details.

If I didn't understand your question, please try again.

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

*********

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

*********



"Collier, Timothy R" <timothy.r.collier@intel.com> on 07/31/2001 06:58:38
PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-cppa@lists.oasis-open.org
Subject:  RE: Security - question about nonrepudiation



Marty,


I was reading the risk assessment and that is what started this.  I do
think
we need to address, in the CPP/A, how to indicate what the signature is
applied to - header, body, attachment, entire thing - but I don't see how
the nonrepudiation elements adds something new.

What I was wondering is if we define the document exchange details, like
nonrepudiation (digital signature) and digital envelope (encryption) don't
they cover all of the requirements already?  Even the existing delivery
channel definition does not need the nonrepudiation element as it covers
the
signature requirement via the authenticated element.  In the delivery
channel definition, IMHO, the authenticated and nonrepudiation elements are
redundant.

I was mostly trying to get some discussion started on some of these areas
within security.

     Tim

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, July 31, 2001 3:41 PM
To: Collier, Timothy R
Subject: Re: Security - question about nonrepudiation



Tim,

The attributes in the BPSS instance document don't say anything about how
to actually do nonrepudiation.  The CPP/CPA is precisely where the two
partners agree on what standard to use (actually XML DSIG is the only one
we support) and various details of XML DSIG such as certificates, signature
algorithm, transforms, etc.

There are some questions as to whether what is in the CPP/CPA is correct
and whether it is comprehensive enough to, for example, cover the
application-level response, signing of payload vs signing of the entire
message,  and the signals that may need to be signed.  Some of these
questions are covered in my new.work document and the previous Changes
document.  Others may be called out in the ebXML Risk Assessment document.
It does need a thorough going over.

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


*********



"Collier, Timothy R" <timothy.r.collier@intel.com> on 07/31/2001 05:25:40
PM

To:   ebxml-cppa@lists.oasis-open.org
cc:
Subject:  Security -  question about nonrepudiation




All,

     If two parties agree on complimentary roles within a process
specification, and agree on the document properties (in particular signing)
don't the nonrepudiation elements in the delivery channel characteristics
become superfluous?  After all, the parties have agreed on a process
specification that includes acknowledgement of receipt, and they have
agreed
on which documents have signatures attached (in the document exchange).  To
me NRR sounds like a requirement on the BP, and NRO is a document
requirement for digital signature.
     I have heard that the delivery channel is an implementation
convenience, which is ok, but it seems even for that the authenticated tag
covers the digital signature requirement. And the implementation already is
monitoring the runtime process according to the BPSS.
     Do you think the nonrepudiation tags in the delivery channel express
unique requirements that are not already covered?


     Tim


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org