gss_acquire_cred_with_password() and mech selection

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

gss_acquire_cred_with_password() and mech selection

Greg Hudson
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: gss_acquire_cred_with_password() and mech selection

Greg Hudson
On 07/10/2015 01:21 PM, Greg Hudson wrote:
> * When called with a desired_mechs of GSS_C_NO_OID_SET, we perform six
>   AS-REQs, three inside SPNEGO and three outside.

Oops, this is incorrect.  Our gss_acquire_cred_with_password() already
defaults to using just the default mech in this case.  So the majority
of my previous message is moot.

> * When called with a desired_mechs of SPNEGO, we perform three AS-REQs,
>   one for each non-IAKERB krb5 variant.

I would still like to solve this problem, and am trying to decide on the
scope of the changes I want to make right now.  Two options include:

* Omit GSS_C_MA_DEPRECATED mechs from gss_indicate_mechs().  This would
have the following secondary effects for the old and mskrb5 OIDs unless
we take additional steps:

  - gss_acquire_cred would not use them when no desired_mechs is given.
  - SPNEGO would not acquire creds for them and would not offer them,
even if specified by gss_set_neg_mechs().  They would still be accepted
as synonyms for krb5 by SPNEGO acceptors and mirrored properly in responses.
  - gss_indicate_mechs_by_attrs() would never return them, regardless of
what attributes are queried.
  - gss_inquire_mechs_for_name() would never return them.
  - gss_inquire_mech_for_saslname() would never return them.
  - OpenSSH would not try to negotiate them.

  Although not offering the mskrb5 OID in SPNEGO seems like it might be
a problem, [MS-SPNG] suggests that it is not.  Only Windows 2000 doesn't
understand the standard krb5 OID, and that release is both ancient and
client-only.

* Omit GSS_C_MA_DEPRECATED from the default gss_acquire_cred() set and
the set of mechs used by SPNEGO, probably using
gss_indicate_mechs_by_attrs().  This is a more conservative change; it
would not affect OpenSSH or hide the mechs from the other utility functions.

Either of these options create a problem for one of the test cases in
t_spnego.c which I would have to solve somehow.  One option is to make
it possible to use non-SPNEGO credentials with a SPNEGO
gss_init_sec_context().

Either of the above options could also be extended to IAKERB by giving
IAKERB the GSS_C_MA_NOT_DFLT_MECH default attribute and excluding mechs
with that attribute from the same operations.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev