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

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

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

I think what Josh is trying to define is analagous to this in the context of
protocols that include SAML assertions and have some kind of integrity
mechanism keyed to a Kerberos service ticket.

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

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

-- Scott