Oh wait. As always, just after sending the email is when you find the answer.
I think the answer is that the enc-part isn't just an opaque blob, it's etype kvno cipher So that's where the enctype comes from. Can someone confirm my understanding? On Wed, Jan 4, 2012 at 3:17 PM, Frank Cusack <fr...@linetwo.net> wrote: > How can I learn the enctype of the TGS key? That is, the long lived > krbtgt key. Without having kadmin privileges. > > 'klist -e' reports "Etype (skey, tkt)", where I take it that skey = the > enctype of the session key and tkt = the enctype of the ??? opaque ticket I > guess? > > I question if this is the enctype of the TGS key because RFC 4120 5.4.2 > says that an AS-REP is: > > ... > ticket > enc-part > ... > > The enc-part, AIUI, is the session key data, encrypted with the user's > long term key. > > The ticket is the RFC 4120 5.3 ticket: > > tkt-vno > realm > sname > enc-part > > The enc-part here is encrypted with the TGS key. > > If the "tkt" part of 'klist -e' output is the enctype of the TGS key, from > what field did it learn it? If it's something else, what is it? klist.c > says that the tkt value is tkt->enc_part.enctype, which does make me > think it's the enctype of the TGS key (the enctype used to encrypt the > enc-part), but how/where was this sent to the client? > > Thanks. > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos