On 2012-08-16 19:08, Russ Allbery wrote:
So the question is, how do the WebKDC get knowledge of the TGT session
key?
It's part of the TGT, which is contained in the webkdc-proxy token. In
order to generate the krb5 authenticator, the WebKDC extracts the user's
TGT from the webkdc-proxy token and stores it in a Kerberos ticket cache,
just as if it had run kinit on behalf of the user. It then does a normal
krb5_mk_req call to create a Kerberos authenticator from that TGT for the
principal of the WAS, and then stuffs that authenticator into the id
token.
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.
At least that's also what Wireshark tells me when I ask it to decrypt
the TGT returned in the AS_REP message in the first login.
And isn't the only other way to access that key (not having the
krbtgt/REALM@REALM key) to extract it from the enc-part response of the
AP_REQ at a time where you have the users password ?
/Peter
