Kerberos & front-channel bindings (was Metadata IOP & the front-channel bindings)

[Josh Howlett <josh.howlett@gmail.com>]

On 5 Oct 2009, at 22:22, Scott Cantor wrote:

> Josh Howlett wrote on 2009-10-05:
>> I'm curious how the IOP addresses the confidentiality and integrity
>> requirement of the front-channel bindings (c.f. "Security and Privacy
>> Considerations") from the 'metadata alone'.
>
> I believe that the front-channel bindings take some care to  
> distinguish the
> bindings' requirements for confidentiality/integrity, and the front  
> channel
> itself. Specifically, Redirect and POST say:
>
> "The presence of the user agent intermediary means that the  
> requester and
> responder cannot rely on the transport layer for end-end  
> authentication,
> integrity and confidentiality."
>
> The artifact binding text is a bit more muddled, I admit.
>
> Anyway, this was the justification for speaking broadly in the spec  
> without
> intending to pull in the browser-facing stuff.

So, if I understand you correctly, front-channel security is  
considered entirely orthogonal to SAML message security and the IOP is  
intended for the latter?

The reason I ask is because I have recently been trying to understand  
the feasibility of using the Kerberos protocol within a SAML system  
(as opposed to the more typical use of X.509 credentials or public key  
crypto in general).

The use-case is a large organisation with a small number of IdPs and  
many SPs within an organisational CoT. The organisation already has a  
mature Kerberos infrastructure that provides authentication for users  
and applications. The SAML entities in question are probably already  
principals within the organisation's Kerberos realm and therefore the  
organisation would prefer to use the same Kerberos infrastructure for  
trust establishment within the CoT to avoid the overheads imposed by  
the use of PKI or PK credentials in general.

I have tentatively arrived at the conclusion that there is nothing in  
SAML2Core that would prevent the use of Kerberos in those places where  
XML-SIG and XML-ENC are invoked, assuming the presence of:
     (1) a mechanism that allows the Requesting, Responding or  
Asserting parties to provide a Kerberos service ticket in the  
<KeyInfo> elements (which contains the session key used in the crypto  
operations)
     (2) a mechanism that allows these parties to determine if a  
Kerberos principal is associated with a particular SAML entity.

At present, I'm inclined to address (1) by defining a new Kerberos  
type for <KeyInfo> (see the Kerberos XSD already defined for the  
proposed "Kerberos Subject Confirmation Method" and "Kerberos  
Attribute Profile") and (2) by naming the authorised Kerberos  
principal in the <RoleDescriptor> metadata (again, using the same  
Kerberos XSD).

The main difficulty that I have encountered is satisfying the  
confidentiality and integrity requirements of the front-channel  
bindings using Kerberos and TLS alone. Most browsers only provide  
these properties, using TLS, in concert with cipher suites using  
authenticated X.509 server credentials (there are browser  
implementations supporting the use of TLS and Kerberos-based ciphers,  
but these implementations are not widely used).

I was initially of the opinion that a 'mixed economy' of Kerberos (for  
SAML message security) and X.509 (for front-channel security) would be  
a cop-out. But, on reflection, this approach would still yield  
benefits assuming that the key management imposed by front-channel  
bindings is equivalent to that which would be required anyway for  
protecting /general/ (ie. non-SAML specific) HTTP access to the  
entities in question. This at least still avoids the requirement to  
establish a parallel trust system (special purpose CA, inline keys in  
metadata, etc), even if is still necessary obtain certificates from a  
CA recognised by the browser.

I would be very interested in any opinions on this analysis and  
approach.

josh.