gss-client encryption types

Sam Hartman hartmans at MIT.EDU
Tue May 7 22:51:01 EDT 2002


>>>>> "Frank" == Frank Balluffi <frank.balluffi at db.com> writes:

    Frank> 1. Why does krb5_gss_init_sec_context pass the hard-coded
    Frank> wanted_enctypes to get_credentials even though krb5.ini,
    Frank> which was read, said otherwise?


First, that should only control the session key type not the ticket
enctype.  The client should generally have no control at all over the
ticket enctype.  I believe Microsoft allows the client to influence
the ticket encryption type, but this seems like a bug to me in their
KDC.  

The GSS client needs to make sure that a session key is issued with an
enctype that it knows how to use for GSSAPI.  There is not a guarantee
that the set of enctypes GSSAPI uses will be the same as the set of
enctypes that enctypes that Kerberos supports.  Because of the way the
Kerberos GSSAPI spec is written, you need to specially handle each
enctype at the GSSAPI layer.




    Frank> 2. Is there a way to force gss-client and/or the GSS-API to
    Frank> request and send a ticket of encryption type des-cbc-md5?

No.  As I explain above, the ticket encryption type is the decision of
the KDC, not the client.  You need to make sure your server has keys
for all enctypes that the KDC might issue in its keytab.



More information about the krbdev mailing list