On 2012-08-16 19:31, Russ Allbery wrote:
Peter Mogensen <[email protected]> writes:
Yes, but ...
Maybe I've misunderstood Kerberos, but isn't the session-key inside the
TGT entryped with the key of the krbtgt/REALM@REALM principal?
... which I suppose the WebKDC hasn't got access to.
Right, you have to do an TGS-REQ with the TGT to the KDC to get a service
ticket for the service to which you're authenticating, which gives you a
session key. That's what krb5_mk_req does. The WebKDC talks to the
regular Kerberos KDC as part of the process of generating the krb5
authenticator.
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?
From what I hear you say above that's not the source for the key needed
to create PA-TGS-REQ authenticators. ... so I must have missed something
important.
/Peter
