Re: [wss-comment] Comments on Kerberos Token Profile 1.1 draft 07

[Nicolas Williams <Nicolas.Williams@sun.com>]

On Tue, Dec 06, 2005 at 05:49:59PM -0600, Anthony Nadalin wrote:
> >The TC seems to have responded by adding a plethora of choices.
> 
> There are folks that will use the GSS-API and folks that will use raw
> Kerberos, so we responded and support both, so I guess I don't understand
> your issue now unless you only want GSS-API and that approach was not
> accepted by the TC.

Given the choice of {a choice between raw Kerberos V or GSS-API} on the
one hand and {raw Kerberos V} on the other I'd choose the latter over
the former even though I'd prefer that the GSS-API be used exclusively.

> >I'm also still very curious as to how Kerberos V session keys are used or
> how AP-REQ and/or GSS initial context >tokens are bound to session
> protection provided by other layers.
> 
> The session keys from the Kerberos Token Profile are not used by or bound
> to other session layers.

But section 3.4 says "When a Kerberos ticket is referenced as a
signature key ..." -- what exactly does that mean?

Similarly in section 3.5.

As for the lack of binding, surely this is a security consideration,
that validating the AP-REQ does nothing to authenticate subsequent
messages.

Are Kerberos Tokens bound to other SOAP Security keys or key exchanges?

> 
> >Also, I'd appreciate a pointer to the complete set of OASIS documents
> (i.e., not including W3C or IETF docs) one >must read in order to perform a
> security analysis of this profile.
> 
> 
> Not sure what you mean by "perform a security analysis of this profile" but
> since you have seem to have read the profile you will see a reference
> section, you can start with these and if you find that there are missing
> references please send a comment back to this list.

Indeed, I have, but I'm not sure I'm finding everything I need.  Please
excuse my unfamiliarity with OASIS documents.  Specifically, in "Web
Services Security: SOAP Message Security 1.1," section 1.1.1 I see this
goal:

 - End-to-end message content security and not just transport-level
   security

and in section 1.1.2 I see this non-goal:

 - Establishing a security context or authentication mechanisms.

and you tell me that neither the Kerberos session keys are used nor are
the tokens bound to other layers (and I'm guessing they're not bound to
other SOAP Security keys or key exchanges either).

So, I'm struggling to see how WSS provides end-to-end message content
security using the Kerberos Token Profile.

I'm taking "end-to-end message content security" to mean that end peer
identities are [mutually] authenticated and their post-authentication
messages are at least integrity-protected, if not confidentiality-
protected.

Perhaps I've missed something?

Nico
--