[19232] in Kerberos_V5_Development
gss_acquire_cred_with_password() and mech selection
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jul 10 13:21:57 2015
From: Greg Hudson <ghudson@mit.edu>
To: krbdev@mit.edu
Date: Fri, 10 Jul 2015 13:21:43 -0400
Message-ID: <x7dy4iodj2w.fsf@equal-rites.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
I noticed the other night that, after the change to use a unique memory
ccache for gss_acquire_cred_with_password(), we have some poor behavior:
* When called with a desired_mechs of SPNEGO, we perform three AS-REQs,
one for each non-IAKERB krb5 variant.
* When called with a desired_mechs of GSS_C_NO_OID_SET, we perform six
AS-REQs, three inside SPNEGO and three outside.
http://k5wiki.kerberos.org/wiki/Projects/GSS_mechanism_selection
describes some steps which could improve this and similar problems. But
I also wonder what the best mechglue behavior is for the function when
called with a desired_mechs of GSS_C_NO_OID_SET.
I believe Heimdal (on master) behaves like MIT krb5, except that it
doesn't have the "three OIDs for krb5" problem. So I would expect it to
perform two AS-REQs, one inside SPNEGO and one outside, and also to
acquire creds with a password for every other mech twice.
Solaris acquires a cred for the default mech (typically krb5). This is
also the Solaris behavior for gss_acquire_cred(), and was the MIT krb5
behavior for gss_acquire_cred() before 1.10. That behavior isn't very
nice for acceptor creds, but gss_acquire_cred_with_password() is
basically only used to get initiator creds.
[I haven't CC'd heimdal-discuss because I know the most likely
interested parties are on this list, but feel free to loop in anyone
else on replies.]
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
