More on enctypes vs. VPN

[John Hascall]

> >>>>> "John" == John Hascall <john at iastate.edu> writes:
> 
>     John> The reply 'ISSUE: ... etypes {rep=3 tkt=1 ses=1}' is not
>     John> something I understand completely though (and it seems to be
>     John> unacceptable to the VPN).
> 
> Well, then the VPN should be more picky about what it requests.  Is
> that the VPN doing the initial request, or is that your kinit?  For an
> old VPN program, it's supporting a lot of newer enctypes--all the ones
> that Kerberos 1.3.1 supports.

Sam,

   Thanks for all your help.
   It's not old VPN software, it's some new thing from cisco.
   Given your explanations, I'm going to assume that everything
   is right with Kerberos and see if our telecomm people (whose
   VPN it is) can find something wrong at their end.

> 
>     John> I assume that means that: * the reply itself is encrypted
>     John> using ENCTYPE_DES_CBC_MD5(#3), * the ticket inside the reply
>     John> is using ENCTYPE_DES_CBC_CRC(#1), * as is the session key
>     John> Correct?
> 
> Yes.
> 
>     John> How is it decided what enctype is used for the reply,
> First long-term key in the database that is supported by the client.
> 
>     John> ticket, 
> 
> First key for the service in question, in this case krbtgt.  Nothing
> the client can do can influence this decision.
> 
> 
> 
>     John> and session key?
> First key supported by both the client and server in the client's
> preference order.  Keys of type des-cbc-md5 are never issued and keys
> of type des-cbc-crc are always assumed to be supported by all parties.
> 
> 
> These answers valid for krb5 >= 1.2.5.
   (which includes us)

> 
>     John> Is it a reasonable guess that the VPN wants the tkt to be
>     John> enctype#3 too?
> 
> The VPN has no business caring about what enctype the TGT is encrypted
> in.  It doesn't know the key and thus cannot decrypt it.  That said,
> sufficiently old versions of Kerberos did have bugs that caused
> clients to care more about ticket enctypes than is appropriate.
> Someone writing VPN software could have implemented other bugs
> themselves.
> 
> It's also possible the VPN wants a des-cbc-md5 session key.  Without
> modifications our KDC will not issue such a key.

     I'm now guessing this is not the case.
     I'm curious, why is a des-cbc-md5 session key avoided?

> 
>     John> If so, how to make this happen?
> 
> If it really is caring about the TKT key for the TGT, then change the
> password of your TGT to be des-cbc-md5 based.  This will invalidate
> all existing tickets in the realm unless you use the flag to keep the
> old key around.  This will also make it difficult for you to migrate
> your realm to a TGT key stronger than DES, which is a fairly serious
> problem.

    If I'd have thought harder about this I should have known this.


Thanks again,
John