[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Drafts for review: Kerberos & SAML profiles
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]