RE: [ebxml-msg] What Next?

[Cliff Collins <collinsc@sybase.com>]

Title: RE: [ebxml-msg] What Next?

Sorry for the confusion but it was really 2 points where the first item was informational about what would be exposed in the other points.

 

See comments below in "blue".

 

>1. This doesn't encode the SOAP Envelope. If you

> want to obscure this information (the manifest

> information, etc) you need to encrypt the entire

> message.

 

Actually, all HTTP headers and data, which includes the entire ebXML message, are encrypted within an SSL/TLS session.

 

>2. What about SMTP?

 

Appendix B of the ebMS spec addresses this, ref:

An ebXML Message Service Handler MAY use transport layer encryption to protect the confidentiality of ebXML messages.  The IETF "SMTP Service Extension for Secure SMTP over TLS" specification [RFC2487] provides the specific technical details and list of allowable options, which may be used.

 

Note: RFC2487 has been replaced by RFC3207, ftp://ftp.isi.edu/in-notes/rfc3207.txt

 

TLS is not really a good option IMO. To give you an example why from the security section of the RFC:

 

<!--StartFragment-->7. Security Considerations

   It should be noted that SMTP is not an end-to-end mechanism. Thus, if
   an SMTP client/server pair decide to add TLS privacy, they are not
   securing the transport from the originating mail user agent to the
   recipient.  Further, because delivery of a single piece of mail may
   go between more than two SMTP servers, adding TLS privacy to one pair
   of servers does not mean that the entire SMTP chain has been made
   private. Further, just because an SMTP server can authenticate an
   SMTP client, it does not mean that the mail from the SMTP client was
   authenticated by the SMTP client when the client received it.

Most implementers will want to use the existing mail system at their site and will not be able to convince IT to make all servers between partners to be TLS. There are also some man-in-the-middle attack" problems with TLS that require special consideration outside of the MSH layer.

 

 

>3. What about multihop? Maybe you don't want 

>the information available at the intermediate hop.

 

It would seem to me that an intermediary needs access to the ebXML header information in order to perform it's role as an intermediary. Clearly one may not want an intermediary to have access to the business data contained in the payload container and that should be encrypted using PGP or S/MIME or something else.

 

Encapsulating the message still allows the hop all access to an "ebxml header" but not the "real" message header with the manifest of the real payloads. The hop should be able to route on the header and add signatures or whatever.

 

Cliff