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

["Scott Cantor" <cantor.2@osu.edu>]

Ron Monzillo wrote on 2009-08-20:
> 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.

It is. I wasn't saying they precluded each other, but I don't think any
existing use of KeyInfo really fits.

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

I don't believe so (Josh can correct me). I think the intent is to identify
the principal and assume that the ticket + authenticator is presented
outside the assertion to satisfy the confirmation. 

> 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.

Right, and we could extend KeyInfo. The question is what that buys. If it
doesn't make code "just work", I don't see the point of using a structure
intended to name a key to instead name a principal. As I said earlier, I
could see it if the intent was to name the principal's *key*, but it's not
the principal's key that's used here, it's a session key encrypted by a pair
of other keys.

>> 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)?

I'm not that familiar with the use of symmetrics, but I understood that at
least in some cases it was done via KeyNames that referred to previously
shared or derived secrets.

> 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.

I would agree, but I don't think that's the plan here, precisely to avoid
the IdP needing to have the service ticket in hand.

-- Scott