Re: SAML attributes for Kerberos

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

On 1 Jul 2010, at 18:20, Jeffrey Hutzelman wrote:
> We're specifically looking at a multi-tier system in which an SP  
> needs Kerberos credentials in the user's name for some backend  
> service.  By "credentials" here, I mean a ticket plus the  
> information the SP needs to use that ticket in the role of a client;  
> most notably, the session key. The required credentials must be  
> forwarded to the SP by the IdP, only when a user attempts to use the  
> service in question and according to policy set at the IdP.  Using  
> S4U2Proxy at the SP is not an acceptable solution

That's not what I was suggesting; but I agree that the IdP should  
mediate the credential request/response and that the IdP <-> KDC  
interaction is immaterial (S4U or otherwise) and should be decoupled  
form the SP <-> IdP exchange.

> Fortunately, Kerberos does provide a standardized way of conveying  
> credentials from one place to another, in the form of the KRB-CRED  
> message. This is described in RFC4120, sections 3.6 and 5.8.   
> Unfortunately, construction of a correct KRB-CRED message requires  
> encryption of some parts of the message, using a Kerberos enctype  
> and a key shared by the two parties involved; in this case, the IdP  
> and SP.  This poses an interesting challenge if there is not already  
> a shared secret; for example, if the IdP and SP are operated by  
> different members of a federation.  However, I'm confident we can  
> find a solution.

Scott's proposal sounds very practical if it is reasonable for the  
parties to obtain the key in the way he suggests. Alternatively, use  
HTTP Negotiate and the K5 mechanism at the transport layer during the  
SP's request to the IdP in order to establish the key?

josh.