OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]