SOAP indigestion continued

Ah, a friend tells me that negotiation of all security related things too, like key derivation, is left to application profiles. Even such crucial aspects of a security system like protection against replay attacks is left to application profiles. I see no discussion of reflection attacks in SOAP, so I hope that there's some indication of directionality in the parts of SOAP messages that are signed, or that app profiles always use different session keys for each direction. \*sigh\*

In the IETF we have security frameworks like TLS and SASL that could be as profiled as SOAP is, but by and large all such frameworks come with required-to-implement functionality that makes it possible to have off-the-shelf implementations that Just Work (tm). The IETF mostly does not produce standard APIs and specific programming language APIs for them (exceptions: the GSS-API, SCTP), so each off-the-shelf implementation of, say, TLS, may have its own APIs, but at least implementations of application protocols that use TLS just work and just interop without having to have per-application profiles of TLS. TLS handles most of the security-sensitive aspects of a serious security framework, such as negotiation of key exchange and authentication mechanisms, ciphers, MACs, key-derivation, re-keying, replay protection, reflection protection, etc...

Application developers are usually not cryptographic protocol designers. They shouldn't have to know too much about mundane (to them) issues like key derivation, damn it. Complicating a security analyst's job by pushing so much of a security specification to every application profile doesn't help either. The OASIS WSS TC has done SOAP developers a disfavor here, to say nothing of what it's done for SOAP users.

Of course, SOAP can use TLS. But when it does there is no binding between the use of SOAP Security token profiles for authentication and the TLS sessions used. But at least that's no worse than the sate of authentication for web applications. And there is hope for them still (I'll blog about that sometime).

Comments:

Post a Comment:
Comments are closed for this entry.
About

I'm an engineer at Oracle (erstwhile Sun), where I've been since 2002, working on Sun_SSH, Solaris Kerberos, Active Directory interoperability, Lustre, and misc. other things.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today