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