SOAP-SECURITY proposal

["Brown, Keith" <KB...@develop.com>]

As a guy who is innately interested in security, I'd hate to see an adjunct
to the SOAP spec that attempts to define new cryptographic authentication
protocols. It's extremely difficult to design cryptographic protocols that
really work, and I for one would prefer not to be in this business (the
protocols listed below completely ignore server authentication, just for
starters).

I think the idea of defining the relationship between SOAP and XML
Signatures is a good one. I also think that it might be a useful exercise to
define the relationship between SOAP and SSL over HTTP (just to get our feet
wet and see what the issues are).

I'm really concerned that we don't jump in and get over our heads. SOAP
works well as an encoding scheme; it has incredibly loose ties to HTTP
(which arguably should be segmented into an entirely different spec that
addresses SOAP over HTTP).

Keith
http://www.develop.com/kbrown

-----Original Message-----
From: James Snell [mailto:jsnell@lemoorenet.com]
Sent: Monday, September 04, 2000 9:42 AM
To: soap-dev@xml.apache.org; matkovitsg@uswest.net
Subject: RE: SecureSoap (was SSLSoap) Part3 of 3.


George,

I haven't taken a look at this yet, but I'm interested in knowing more about
how you are doing the PKI security.  Are you planning to use 100% transport
layer security, or are you rolling security into extended SOAP headers?  If
so, what exactly is this going to look like?

I've been doing some thinking about this for a while and am close to
proposing a draft SOAP-SECURITY proposal that covers authentication, message
integrity and privacy issues.  Each of these deal with extensions to the
SOAP envelope itself, rather than relying on security built into the
transport mechanism.

Here's the gist of what I'm thinking:

  A. Authentication
     1. Basic Authentication (Level 1): Implemented as a single SOAP Header
containing the login ID and password encoded as a Base64 string

     <SOAP:Envelope>
         <SOAP:Header>
             <SOAP-SEC:authenticate mustUnderstand='1'>
                 akj4499sdl23-00=
             </SOAP-SEC>
         </SOAP:Header>
         <SOAP:Body>
             <...>
         </SOAP:Body>
     </SOAP:Envelope>

     2. Challenge-Response (Level 2): Implemented as a short series of SOAP
Requests aimed at creating a logon-session between the client and server.

        * First, the client notifies the server (via a standard SOAP
request) that it wishes to gain access.
        * Second, the server issues a challenge to the client.  The
challenge requires the client to properly encrypt a randomly generated
sequence of bytes.
        * Third, once the server verifies that the client has properly
encrypted the bytes, a session ID is issued.  The session ID is transmitted
back and forth between the client and the server and is only valid for X
amount of time.  Once the session timeout period has elapsed, the client and
server must perform the logon handshake process again.

     3. Digital Certificates (Level 3).  Based around the XML Digital
Signature specification, the client embeds their digital certificate in the
SOAP Headers and transmits their request to the server.

  B. Message Integrity.  Basic just a full implementation of the XML Digital
Signature specification.  The body of the SOAP request is signed and the
signature is embedded in the SOAP Headers.

  C. Privacy.  Element-wise encryption of select portions of the SOAP Body.



Please, let me know your thoughts.

- James