Peter Mogensen <[email protected]> writes:
> Sure - the WebKDC can create an authenticator from the TGS-REP session
> key and make a AP-REQ for the service and put it in the id-token (sad),
> right?
> But that is not the session key / authenticator I was wondering about.
> What I didn't understand was how the WebKDC could create the
> authenticator for the TGS-REQ, since it had to be encrypted with the
> session key from the TGT, which (when inside the TGT) is enrypted with
> the private key of the krbtgt/REALM@REALM.
> Granted, the WebKDC has access to that key, when it performs the AS-REQ
> and it's returned in the enc-part of AS-REP encrypted with the users
> private key, which the WebKDC knows at that pointe, because it has the
> password.
> ... but if that's the source then where's it kept until the user returns
> at a much later time doing SSO with the webkdc-proxy token?
Oh! I see what you're asking.
What's stored in the webkdc-proxy token is not just the TGT. It's a
complete serialization of a krb5_creds structure as returned by
krb5_get_init_creds_password. So it includes all of:
typedef struct _krb5_creds {
krb5_magic magic;
krb5_principal client; /**< client's principal identifier */
krb5_principal server; /**< server's principal identifier */
krb5_keyblock keyblock; /**< session encryption key info */
krb5_ticket_times times; /**< lifetime info */
krb5_boolean is_skey; /**< true if ticket is encrypted in
another ticket's skey */
krb5_flags ticket_flags; /**< flags in ticket */
krb5_address **addresses; /**< addrs in ticket */
krb5_data ticket; /**< ticket string itself */
krb5_data second_ticket; /**< second ticket, if related to
ticket (via DUPLICATE-SKEY or
ENC-TKT-IN-SKEY) */
krb5_authdata **authdata; /**< authorization data */
} krb5_creds;
and therefore, specifically, the krb5_keyblock component of the krb5_creds
structure, which I believe is what's used to protect further TGS-REQ
requests.
Indeed, if we only serialized the ticket component, it wouldn't really be
usable later.
I'm guessing that the protocol specification doesn't describe this
properly currently and incorrectly conflates the TGT with the complete
creds structure.
--
Russ Allbery <[email protected]>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University
