SOAP, Security, Kerberos V, indigestion
By nico on Sep 17, 2007
Twice in the past 5 or so years I've sent the OASIS WSS TC some comments on the Kerberos V Token Profile 1.1 for SOAP Message Security 1.1. You can probably go find the mails in the archives. I never got answers to the questions that really mattered, and then I dropped the matter -- I'm not a SOAP implementor, after all -- though I had cared out of fear that someday the Solaris krb5 team would be asked to make it possible to implement a problematic spec.
A colleague asked me about this profile today. So I went to find answers, again.
Nowadays the Kerberos V Token Profile 1.1 is no longer a draft.
Now, reading the two specs (SOAP Message Security 1.1 and the Kerberos V Token Profile 1.1) I note that:
- The TC added support for using the initial context token from the Kerberos V GSS-API mechanism, probably in response to a question from me as to why they didn't. I so wish they hadn't. The right thing to do would have been to use all of the GSS-API mechanism, including its per-message token services, or that they use the GSS_Pseudo_random() function to extract keys from the mechanism's security contexts. As it is I think we'll need GSS-API extensions to get at mechanisms-specific internal contents: the krb5 session and sub-session keys.
- Key derivation is still unspecified, in the token profile and in the base spec, which means that you can only use XMLenc ciphers and XMLdsig signature algorithms whose key sizes are compatible with the enctype used in the Kerberos V AP-REQ Authenticator for the sub-session keys (or in the Ticket for the session key), or you must come up with some profile that specifies key derivation, or you can choose not to interop.
- Negotiation of things like XMLenc ciphers is also out of scope (in the base SOAP security spec; perhaps it's specified elsewhere?).
I think SOAP would benefit from using TLS for transport security and PKI/Kerberos/... for authentication with channel binding to the TLS session. Of course, that would require further profiling, and I gather everything SOA is political, so getting there seems unlikely. But I think I'll try, particularly when On Channel Bindings is published as an RFC (it's in the RFC Editor's queue!).