gss-client encryption types

[Donn Cave]

Quoth Sam Hartman <hartmans at mit.edu>:
| >>>>> "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.

Isn't it true that the set of enctypes GSSAPI uses will be a _subset_
of the enctypes that Kerberos supports?  If krb5.ini gives you the list
of enctypes that are supported at this site, is GSSAPI required to ask
for more that aren't on that list?

Cf. "Re: KRB5 1.2.2+Solaris 8 SPARC + imap-2001a rc2 == enc_type_not_supported",
krbdev Nov 2001.

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

	Donn Cave, University Computing Services, University of Washington
	donn at u.washington.edu