enctype of TGS key

[Frank Cusack]

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