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

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

Josh Howlett wrote:
> 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.
> 
Hi Josh,

Is it too much of stretch to view the principal as the name of the
shared secret that must be known in order to obtain and use a service
ticket acquired from the kdc?

if not, the confirmation method can be seen as requiring that the 
attestor demonstrate knowledge of the secret the principal shares with 
the kdc.

The STP is flexible wrt to how the attestor may demonstrate knowledge of 
the key, and it would seem that the attesting entity could accomplish 
this by following the WSS KTP to use the session key of a service ticket 
issued to the principal (to act at the receiver) to sign content within 
the message or messges that it sends to the receiver..

sinc keyInfo, already supports keyName, I think you could schieve this 
by conveying the principal name in KeyName, or perhaps you could take 
the additional step of naming both the principal and the target service 
which should b analogous to naming the service ticket(s).

>> 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).
> 

yes, and I may be over the top wrt to this use-case, but I could see 
SAML assertions as an XML replacement for kerberos service tickets, 
where the confirmation method would include the xml equivalent of the
EncTicketPart of a kerberos service ticket, and the assertion could
carry various statements, attributes or claims pertaining to the client
at some target service. The assertion authority would in effect become 
the kdc; which may or may not be practical, depending on whether ther 
are sufficient api's and protocols to get tickets form the authority. In 
the past when I looked at this, I wasn't quite sure that it was clear 
how one would request an assertion for use by principal x at some 
service y.

> 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.

I am not sure this is the case since the receiver can impose a 
requirement that the service ticket used by the attester to sign the 
message be targeted to it (the receiver). The receiver could also check 
other attributes of subjectConfirmation, if it needs to confirm that the 
assertion was intended for it.

> 
> 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.

(for case 1) if you cannot accomodate the view that a kerberos principal 
names the key the principal shares with the kdc, then I think you will 
need to define a new confirmation mechanism.

In either case, it looks like validation will basically involve 
confirming that the client principal named in the service ticket (whose 
session key was proved by the attesting entity) matches the principal 
named in the confirmation method of the assertion.

If either case, this is likely a simple variation on the existing 
implememtations of the WSS STP and KDC.

thanks for taking the time to review this.

Ron

> 
> best regards, josh.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php