More on enctypes vs. VPN

Sam Hartman hartmans at MIT.EDU
Sun Oct 12 20:07:34 EDT 2003


>>>>> "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.


    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.


    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.


    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.





More information about the Kerberos mailing list