Re: [security-services] Drafts for review: Kerberos & SAML profiles

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

Hi Ron,

Apologies if if I haven't properly articulated the use-case in question.

To be clear, the intent is to enable a SAML requester to confirm an  
attesting entity using some Kerberos-based evidence that is bound to  
the assertion. This is needed both for Web SSO and WSS STP use-cases  
where the presenters are a web browser and WS client respectively.

The original idea was to attempt an analogue of the X.509 HoK  
Assertion Profile, where the attesting party can be confirmed by  
matching a Kerberos principal name (contained within a <KeyName>  
within the SAML HoK) to the principal authenticated at the transport  
layer (through HTTP Negotiate & the K5 GSS mechanism).

However, Scott observed that the HoK is intended to "name a key" and  
not "name a principal" and so the recent discussion has turned to  
finding some other way of expressing the principal name within a  
subject confirmation method.

> IMO, SAML should define how one defines the analogue of a kerberos  
> service ticket as a SAML assertion with a HOK confirmation mechanism  
> containing (or identifying a session key), and then protocols like  
> the WSS STP should be able to use such assertions to convey signing  
> keys to relying parties. Perhaps you are not looking to solve that  
> problem, and are looking to do something more akin to what the WSS  
> KTP did; but I don't think that likley since I presume you are  
> expecting some SAML authority to issue tokens/assrtions containing  
> attributes that can be confirmed by some proof provided by their  
> intended user.

I don't think I understand your use-case. For what it's worth, I'm  
definitely interested in addressing the use-cases in which a SAML  
Requestor can obtain a SAML assertion that contains a Kerberos service  
ticket, which it subsequently uses for access to either (1) a local  
Kerberised service, or (2) a remote Kerberised service, or (3) a web  
service using the WSS STP (i.e. Kerberos service ticket embedded  
within a SAML assertion over WSS STP).


> if so, you need a way for the ticket requestor to authenticate to  
> the authority (which could be the KTP), and for the token response  
> to make the token and is associated session key available for use by  
> the requestor;

For me, this is a distinct  use-case from the one I describe above: I  
think you're describing trust establishment between SAML Issuers and  
Requesters (as opposed to a SAML Requester establishing trust in an  
attesting entity). Nonetheless, I think this is a very interesting use- 
case; there are certainly folks who would prefer to use Kerberos to  
establish trust between these types of entities, rather than the more  
traditional asymmetric methods which are seen to incur unwelcome  
overheads (...because Kerberos is used for everything else).

However, since you raise it, it seems that it introduces an argument  
for using <KeyInfo> to identify the principal, because SAML2Meta uses  
this element to "directly or indirectly identifies a key". Metadata  
consumers and publishers could therefore attempt to match the  
principal claimed by the remote entity against the identity named in  
the <KeyInfo> element in the <RoleDescriptor>. To avoid redundancy,  
there is an argument that you could use the same <KeyInfo> syntax to  
identify a Kerberos principal for both the Subject Confirmation and  
metadata.

A purely identifier-based syntax is not sufficient, of course, because  
you also need a way to represent the Kerberos service ticket used to  
sign SAML Requests and Responses (again, within a <KeyInfo> element).  
Consequently, there is an argument that there is a requirement for  
representations of both Kerberos principal names and Kerberos service  
tickets in the <KeyInfo> element.

In summary, I think there are now two candidate approaches:

  1) define a new subject confirmation method that names the attesting  
entity within a Kerberos NameID. This satisfies the original use-case,  
and avoids significant invention, but does not address the "trust  
establishment between Issuers/Requestors" use-case.

  2) use the existing HoK confirmation method, naming the attesting  
entity within a new <KeyInfo> type. This satisfies (I think) both use- 
cases, but requires some invention (the <KeyInfo>-based  
representations of a Kerberos principal name and a Kerberos service  
ticket).

It seems to me that the selection of approach depends on how  
interesting we consider the "kerberos trust establishment" use-case.

Sorry if I've rambled a bit.

best regards, josh.