[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 Scott and Josh, I've been trying to follow the discussion. fwiw, I did not see the msg sent to the wss tc, maybe my email address has been removed from that list. the WSS Kerbros Token Profile (KTP) was defined to allow a relying party to validate signatures using the session key (or subkey) defined in a kerberos AP_REQ. The KTP was defined for use by clients and relying parties that want to rely on a KDC to provide them with service tickets for use in in AP_REQ packets used as WS-Security security tokens. 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. 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; if you have a way to do that, then it would seem relatively straight forward to define a way to carry the corresponding keydata within the keyInfo of the assertion. (my expectation is that) existing implementations of the STP only support keyData of the types requried to be supported by XML-DSIG (since the STP deffered to XML-DSIG and SAML to define the keydata forms to be supported within SAML assertions), and I am not aware of any requirments other than those specified by XML-DSIG. having said that, it seems like SAML could easily use the existing key confimation structures to represent what you are trying to represent, and that any profile that relies on a symetric confirmation key could define an appropriate keydata type to carry the keydata.....that is, assuming I am even close to understanding what you are trying to do. Ron Josh Howlett wrote: > > On 19 Aug 2009, at 02:06, Scott Cantor wrote: > >> Josh Howlett wrote on 2009-08-18: >> >>> I think it would be useful to understand whether it is acceptable to >>> use subject confirmation methods other than those that are mentioned >>> in the WSS SAML TP spec. >> >> >> I think I'm coming to believe you're right, that there's no >> precluding of >> other types. Even if there were, I don't find the current TP to be >> particularly attractive for newer applications anyway, so I think >> it's moot. > > > ... > >>> Interestingly, WRT the IMI spec (section 12) defines a set of >>> identifier-types that are represented through an <Identity> WS- >>> Addressing <EndpointReference> property. Two of these are Service >>> Principal Name and User Principal name, and the semantics associated >>> with those fit the Kerberos use-case. >> >> >> Sort of in reverse, yes, they tell you who you're getting an >> assertion from >> or sending it to, but I agree that the structure is applicable. > > > Ok, personally I'm satisfied that a new Subject Confirmation method > that uses this structure to encode a Kerberos principal name is a > defensible approach for my use-cases (Web SSO & WSS). Unless I hear any > advice to the contrary, I will propose a strawman for discussion shortly. > > 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]