RE: Security protocols for TRP

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

I think there is a terminology problem in the appended.

The conversation is an instance of a CPA.  Definitions in the CPA apply to
all conversations under that CPA.  So the most coarse-grained information
from a CPA perspective is on a CPA basis, i.e. it applies to all
conversations under the CPA.
Within the CPA, the granularity can be as fine as per message definition.
Different message definitions can have different values of a given
parameter.  Thus, business timeouts can be different for each message
definition (i.e. for requests under different business transactions).  The
CPA cannot deal with a granularity of "per instance of a message".  Thus if
each instance of (for example) "Purchase Order Request" under the same
business transaction must have a different business timeout, this
information must be conveyed in the payload of the request and would
override any timeout specification in the TPA for the same message.

We definitely want to avoid making the message header a moving target.
Some people use the term "creeping elegance".

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



Scott Hinkelman/Austin/IBM@IBMUS on 12/15/2000 12:47:36 PM

To:   "Burdett, David" <david.burdett@commerceone.com>
cc:   "'stefano.pogliani@sun.com'" <stefano.pogliani@sun.com>,
      ebxml-ta-security@lists.ebxml.org, "ebXML Transport (E-mail)"
      <ebxml-transport@lists.ebxml.org>
Subject:  RE: Security protocols for TRP



>
You can quite
imagine a standard value for this that would apply to all conversations
between two parties. You can also imagine that this could vary from
instance
to instance, e.g. I need a response to this Purchase Order within 5,15,300
minutes, as if you can't deliver or don't respond I want to place an order
elsehwere.
>

Values applicable for all conversations between two parties is not being
explicitly considered on
its own, which is interesting. Currently the thinking is that the most
coursed grain agreement data
is at an instance of a conversation. David's comment may indicate to think
otherwise.

The guidelines seem logical to me execpt the above (?) but I am concerned
that header will continue
to be a moving target moving target moving target moving target.....

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"Burdett, David" <david.burdett@commerceone.com> on 12/15/2000 10:23:12 AM

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



Stefano says ...

>>>A layered approach would grant the possibility to use the MSH
"independently" from
the full ebXML context. <<<

We have two extreme choices that we could make:
1. Put all the information that a MSH needs to know in the CPA with nothing
in the header, or
2. Put everything in the header and nothing in CPA

The first approach is ideal for the situation when the messages are being
sent repeatedly between the same two parties as it avoids resending the
information
The second approach is ideal if the two parties have never communicated
before.

Actually I think we are doing is neither of these two extremes (which also
I
think is right). More specifically we are:
1. Including a (candidate)CPA in the first message of a conversation that
proposes the rules that apply to the conversation. This information then
only needs to be sent once.
2. Providing additional information in each header where this is required
(see later), and
3. "Default" or "Standard" CPAs to be used when the process that the
exchange of messages are supporting does not warrant an individually
tailored set of rules.

So how do we decide what goes in the head and what goes in the CPA. I
suggest we use the following guidelines:
1. Information that always (or nearly always) remains constant over many
conversations between a party always goes in the CPA
2. Information that changes from message to message should always go in the
message
3. Information that is usually constant, but can vary from message should
go
in the CPA but with the opportunity for it to be over-ridden by data in the
header.

An example of this last type of data might be "Time To Live" which
indicates
a time, after which the message should no longer be processed. You can
quite
imagine a standard value for this that would apply to all conversations
between two parties. You can also imagine that this could vary from
instance
to instance, e.g. I need a response to this Purchase Order within 5,15,300
minutes, as if you can't deliver or don't respond I want to place an order
elsehwere.

Thoughts?

David

-----Original Message-----
From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
Sent: Friday, December 15, 2000 2:09 AM
To: ebxml-ta-security@lists.ebxml.org
Subject: RE: Security protocols for TRP


I have been looking to this thread and would like to give my 2 cents.
Please, accept in advance my apologies for not going in the "technical
details" of this interesting discussion, since I am not a security expert.
The aim of this mail is to contribute to positioning this discussion in
the context of the different parts of the ebXML architecture.

In Krishna's first answer, I found that a lot of questions were actually
related to some "architectural" considerations on the layering of the
runtime
software.
Splitting of responsabilities between the layers on respect to the
different
functionalities that need to be provided (including security, of course)
seems
to me a thing that needs to be done.

In its contribution
http://lists.ebxml.org/archives/ebxml-transport/200012/msg00079.html,
Scott Hinkellman proposed the following layering which, seems, no one
contraddicted:

a.   Application (perhaps an existing non-collaborating application)
b.   Application Collaboration Adapter (makes an existing
non-collaborating
     app collaboration)
c.   Middleware (supports behavior needed to for BP Signals, etc)
d.   MSH (packaging, etc)
e.   Transport (http, etc)

Now, many of the things here asked (by Krishna but also enforced by others)
seem
to refer to layers c. and b. which are the layers that depend "strictly" on
the
CPA/CPP (and, indirectly, on the BP).

I personally (but I may be wrong) think that the MSH should not depend on
the CPA/CPP.
So, all things that seem to be prescribed by the CPA/CPP "should" not be
enforced by
the MSH. This does not mean that the MSH could not be delegated of some
actions from
the above layers, but that the control of those actions is not autonomously
defined
by the MSH.

A layered approach would grant the possibility to use the MSH
"independently" from
the full ebXML context.

I am not an expert in security and, thus, I cannot really contribute
"technically" to
the discussion. I think, though, that perhaps an approach which maps the
different
security items to the different responsabilities in the proposed layering,
would
benefit the common agreement on how the security can be enforced and would
benefit the
people implementing the specs in properly layering the developed software.

I am not, with that, preaching for an implementation architecture. Simply
to
try to
map the security items against some behaviour and the associated need (and
place) for
that behaviour.

Best regards

/Stefano



> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: Friday, December 15, 2000 2:24 AM
> To: ebXML Transport (E-mail)
> 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 ?
>
>    2.   On the flip side, I assume the layers above can specify the
requirement
> for encryption and signature when sending a message.
>
>    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 ?
>
>         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.
>
>    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
> >
> >
>
>