RE: SAML attributes for Kerberos

["Russell J. Yount" <rjy@cmu.edu>]

To clarify what our current implementation does.
We send the a kerberos service ticket and session key information pair from
IDP to SP as a mime encoded attribute.
On the SP side we then collect the various ticket and session key
information pairs and create a ticket file.

-Russ

-----Original Message-----
From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] 
Sent: Thursday, July 01, 2010 1:20 PM
To: Josh Howlett; Thomas Hardjono
Cc: security-services-comment@lists.oasis-open.org; Russell J. Yount;
cantor.2@osu.edu; Thomas Hardjono; jhutz@cmu.edu
Subject: Re: SAML attributes for Kerberos

--On Wednesday, June 30, 2010 09:50:50 PM +0100 Josh Howlett 
<josh.howlett@gmail.com> wrote:

>
> On 30 Jun 2010, at 20:06, Thomas Hardjono wrote:
>> To answer your question, the attribute profile currently does not (as
>> yet) support the delivery of pieces of a Kerb message (eg.
>> ticket/session-key pair).
>
> /If/ I've understood the use-case correctly (n-tier, SP wanting access to
> a Kerberised service), I believe that we can address this in three ways.
> The first two are fairly obvious:
>
>   (1) create a new MessageType in the attribute schema for this payload.
>   (2) define a schema extension point to permit (1) as an extension.
>
> (These are semantically equivalent.)
>
>   (3) use the Kerberos S4U mechanisms, where the IdP obtains a ticket
> from the KDC on behalf of the SP. The SP uses the already-defined
> Kerberos Attribute Profile facilities to request the ticket from the IdP.
>
> On the basis of the information available to me, (3) is my suggested
> approach.


OK; there's a bit of confusion here, in part because I think we're talking 
about two different things.  I don't have a copy of the Kerberos SSO 
profile document handy at the moment, but my recollection is that this is 
primarily about using Kerberos to authenticate to the IdP, and possibly 
also to an SP.  That's interesting, but not the problem Russ and I are 
working on.


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, 
firstly because that would imply the SP has the authority to get tickets on 
behalf of any user it wants whenever it wants, rather than only when the 
user accesses the service and for the lifetime of the delegated ticket, and 
secondly because it requires that both the SP's client and the KDC support 
S4U, which is a Microsoft extension and _not_ a standard part of Kerberos 
(or even a standardized extension).

Thus, what we're trying to do is provide a means for the IdP to forward to 
an SP those credentials which the SP is authorized to have.  Whether the 
IdP obtains these credentials via S4U, by being co-located with the KDC or, 
as in our case, by having the user's password (and thus a TGT in the user's 
name), is IMHO immaterial to the discussion at hand.  The important 
question is, once the IdP has credentials, how does it forward them to the 
SP?

The implementation that Russ currently has does this, as I understand it, 
by means of an attribute whose contents are a ticket file, in the format 
shared by MIT Kerberos and Heimdal.  This is workable as a 
proof-of-concept, but not really suitable for standardization; Kerberos 
does not specify the form in which cached credentials are stored, and there 
exist a variety of implementations for which the "ticket file" format is 
not their native credential store or which do not understand it at all. 
Even those which do understand it are generally not capable of importing 
tickets in that format other than by reading an actual file from the 
filesystem.  IMHO we should not be requiring SP's to commit tickets to 
stable storage before being able to use them (though in practice, many of 
the applications we have in mind will do exactly that).

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.


-- Jeff