RE: Security Discussion/Registry Security Spec Version 003

[Maryann Hondo <mhondo@us.ibm.com>]

I believe we have intended to support SSL all along through the "transport"
section of the CPP.
I've been working with Chris Ferris and Ralph Berwanger on how to specify
the security elements at the BP level as well as in the
CPP and how this relates to TR&P.

These are the current "scenarios" I have suggested. Note the actual tags
are just my construction, but I think
it shows the "flow". In the examples below the business process would
specify the tags in the "MSH" section,
meaning that a business process could assert that TransportAuthentication
is Required.  This means the
Delivery Channel section in the Collaboration Party Profile needs to
include details on how the "MSH" is
able to provide this   The DeliveryChannel sections need A LOT MORE detail,
and Chris, Dale & Dick Brooks
have been working on this. It is left to the "MSH implementor" to provide
something
that matches the configurations specified in the CPP for the business
entity.

The CPP also specifies things related to the "document" .  I have suggested
that this is out of scope for
TR&P, but should be included in the CPP and I have used this in Scenario 3
as an example.

I have also suggested that the "conformance" part of the Technical
Architecture document be where
rules for profile conformance be specified.  It would be great if POC could
test out a few of these and
give feedback on what is needed to provide interoperability with a subset
of the profiles.

I also have anticipated that S2ML might provide a solution for putting
authorization information
in the extensible portion of the ebxml header although this has not been
completely explored.


Scenario 1......SSL with Client Auth & a signed receipt


<MSH>
     <TransportAuthenticationRequired>
     <TransportConfidentialityRequired>
     <DigitalSignatureReceiptRequiredOnMessages>
</MSH>
<DeliveryChannel>
     <TransportEnvelope>
          <SSL Details>
          <AuthenticationRequired>
               <client auth>
          <ConfidentialityRequired>
               <SSL v3 details>
     </TransportEnvelope>
     <ebxmlMessageEnvelope>
          <DigitalSignatureRequired Receipt=yes>
               <XML-DSIG>
     </ebxmlMessageEnvelope>
</DeliveryChannel>


Scenario 2 .......XML Dsig for signing header & payload
<MSH>
     <DigitalSignatureRequiredOnMessages>
</MSH>
<DeliveryChannel>
     <ebxmlMessageEnvelope>
          <DigitalSignatureRequired>
               <XML-DSIG details>
     </ebxmlMessageEnvelope>
</DeliveryChannel>


Scenario 3 ........SSL authentication with SMIME payload
<MSH>
     <TransportAuthenticationRequired>
</MSH>
<DeliveryChannel>
     <TransportEnvelope>
          <SSL details>
          <AuthenticationRequired>
               <client auth>
     </TransportEnvelope>
</DeliveryChannel>

<DocumentObject>
     <ConfidentialityRequired>
          <SMIME v2>
</DocumentObject>





Krishna Sankar <ksankar@cisco.com> on 12/27/2000 07:09:47 PM

To:   ebXML-Regrep <ebxml-regrep@lists.ebxml.org>,
      ebxml-ta-security@lists.ebxml.org
cc:
Subject:  RE: Security Discussion: Changed Agenda: Teleconference : 12/21
      /200012:30-4pm CDT : RIM discussion follow-up



Zahid,

     I am ambivalent about supporting UN/PW in the registry (for a change ;
-)).

> -----Original Message-----
> From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com]

<snip ../>

>  Password based auth is so basic that not having
> support is a problem particularly for light-weight
> registry clients that have access to HTTPS transport
> but no PKI and/or cert mgmnt capabilities.

Yep, agreed. And HTTPS would make the transport secure and would fit very
well with lightweight Registry. Good idea.

> as I pointed out before:
> 1) We can specify UserId/Pwd "credential/login" data
> using S2ML which allows us to encrypt the login
> elements;

If we encrypt the credentials, won't we get into the same problems as
before. Where would one get the keys without some kind of a PKI?

> 2) Having password based authentication features
> is very compatible with existing enterprises that
> want to re-use password databases (either in LDAP,
> in existing single-signon user database, or even
> a standard web server).
>

It will also help us in debugging, testing interoperability et al.

cheers