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

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

Scott Cantor wrote:

> 
> My point has been that while this is admittedly still "holder of key", there
> needs to be a clear indicator that the key involved is really the session
> key from a service ticket issued to a principal. While we could bury that
> information inside of ds:KeyInfo, it doesn't seem as clean to me as just
> defining a new method (and possible using the NameID element that Josh just
> noticed to identify the principal that the ticket will be coming from).
> 
using keyInfo within subjectConfirmationData would not preclude you from 
using the NameId within Subject or SubjectConfirmation; IIRC the value 
within Subject is used to identify the claimed identity, while that 
within SubjectCOnfirmation is used to identified the entity expected to 
satisfy the confirmation, so it may be the latter on which Josh was 
intending to hang the client principal.

I think you expect the assertion issuer to embed one or more kerberos 
service tickets somewhere within a subjectconfirmation element

fwiw, although ws-security defined the STR to reference and encapsulate 
(via its concept of "embedded") security tokens in keyInfo, Th STP did 
not adopt the use of STR's to convey the confirmation keys within HOK 
confirmed assertiosn. we did that to mak sure that SAML would be free to 
extend keyInfo without dependence on wsse (specifically for its HOK) 
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 think we already have that capability with HoK directly by means of a
> symmetric key proof in place of the more usual approach.

how do you represent such keys (presuambly in keyInfo)?

If you have already gotten into the business of exchanging symetric keys 
in KeyInfo; it would seem like a relatively small step to support a 
Kerberos service ticket in a mananer analogous to way Keyinfo uses 
X509Data to convey whole certificates.

Ron

> -- Scott
> 
>