Subject: [kitten] gss_userok

From: [email-masked]
Date: Tue, 5 Apr 2011 14:41:49 -0400 (EDT)

I just merged Luke's implementation gss_userok to the MIT krb5 trunk,
and Sam brought to my attention that it conflicts with the Gnu GSS
version of the symbol, which has the prototype:

  int gss_userok(const gss_name_t name, const char *username);

The version Luke committed is based on OpenSolaris's private
__gss_userok():

  OM_uint32 __gss_userok(OM_uint32 *minor, const gss_name_t name,
                         const char *user, int *user_ok);

We don't want to conflict with Shishi, but we do want the major and
minor return codes; we believe an app should get "I ran into an error
trying to find the answer" rather than just "no" if something goes
wrong.  So, our plan is to rename the symbol to gss_login_ok() and
make a wrapper for the Gnu GSS gss_userok().

I think this is all pretty straightforward, but I wanted to raise the
issue here in case other implementors thought we should do something
different.

(gss_userok/gss_login_ok are not the subject of a current work item,
as far as we believe; we expect that it might be standardized in the
future, and we think that the OpenSolaris version with major/minor
returns is more likely to make it through standardization than the Gnu
GSS version.  The other open question is whether a function like this
should take some kind of context argument which an application could
hang configuration onto, but we don't want to solve that problem
today.)

---

From: Martin Rex <[email-masked]>
Date: Tue, 5 Apr 2011 20:55:52 +0200 (MEST)

> hang configuration onto, but we don't want to solve that problem

To pass printable strings to GSS-API functions, GSS-API uses
gss_buffer_t (with an explicit length field), but not "const char *user".

-Martin

---

From: Luke Howard <[email-masked]>
Date: Wed, 6 Apr 2011 09:45:52 +1000

>                         const char *user, int *user_ok);

Simon can correct me if I'm wrong, but there's probably more code that uses the Sun prototype than the Shishi one (e.g. dovecot). What's the impact of Shishi changing its prototype?

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Apr 2011 20:09:19 -0500

> Simon can correct me if I'm wrong, but there's probably more code that uses the Sun prototype than the Shishi one (e.g. dovecot). What's the impact of Shishi changing its prototype?

I too prefer the Solaris prototype and prefer using it with the name
gss_userok().  However, this is really bikeshed painting -- whatever
Greg et. al. decide will do.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Apr 2011 12:01:36 +0200

Luke Howard <[email-masked]> writes:

> Simon can correct me if I'm wrong, but there's probably more code that
> uses the Sun prototype than the Shishi one (e.g. dovecot). What's the
> impact of Shishi changing its prototype?

Fixing that would require an ABI incompatible library release, with all
the pains that goes with that.  I'd prefer to avoid that unless there
are compelling reasons.

All code that is using the Sun prototype needs to be updated anyway, as
far as I can tell: they call it __gss_userok and not gss_userok.  When
updating that code, it is equally hard to do s/__gss_userok/gss_loginok/
as it is to do s/__gss_userok/gss_userok/.  So I'm not sure what would
be gained by adding a new symbol gss_userok that would be incompatible
with GNU GSS?

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Apr 2011 10:46:11 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> I too prefer the Solaris prototype and prefer using it with
    Nico> the name gss_userok().  However, this is really bikeshed
    Nico> painting -- whatever Greg et. al. decide will do.

I don't like any of the existing prototypes, but will live with the
Solaris prototype.
I expect to propose an expanded prototype on the order of a year or so.

I prefer that we not stop on Simon's prototype and would recommend that
implementations implement Simon's prototype as a wrapper.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Apr 2011 17:00:56 +0200

> I expect to propose an expanded prototype on the order of a year or so.

Then it sounds as if this is not something that we want to standardize
at all at this point?

> implementations implement Simon's prototype as a wrapper.

Given the questions about different semantics of the interfaces, maybe
it is not useful to coordinate even that.

This interface and password prompting are the two most important GSS-API
additions that I'd like to see standardized.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Apr 2011 17:09:47 +0200

> additions that I'd like to see standardized.

Password prompting is the main reason I have not implemented SCRAM as a
GSS-API mechanism.  Has anyone implemented SCRAM for GSS-API in any way
that makes sense for a reasonable application?  If so, how do you handle
password prompts on the client side, and password/verifier storage on
the server side?

I have considered using a gnupg-agent/pinentry style approach to let the
GSS-API library directly query the user for a password on the client
side without the application knowing, but until I have figured out how
to resolve the same problem on the server side, I don't want to write
the implementation.

/Simon

---

From: Luke Howard <[email-masked]>
Date: Thu, 7 Apr 2011 01:17:27 +1000

> I expect to propose an expanded prototype on the order of a year or so.

OK, how about this then?

int
gss_userok(const gss_name_t name,
           const char *username);

typedef struct gss_userok_config *gss_userok_config_t;

#define GSS_C_USEROK_NO_CONFIG ((gss_userok_config_t) 0)

OM_uint32
gss_userok_ext(OM_uint32 *minor,
               const gss_name_t name,
               gss_const_buffer_t user,
               const gss_userok_config_t config,
               int *user_ok);

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Thu, 7 Apr 2011 01:27:51 +1000

> gss_userok_ext(OM_uint32 *minor,

^^^ Keep Simon/Nico/Greg happy

>               gss_const_buffer_t user,

^^^ Keep Martin happy

>               const gss_userok_config_t config,

^^^ Keep Sam happy

:-)

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 10:32:19 -0500

> Then it sounds as if this is not something that we want to standardize

I don't see why we wouldn't standardize it.

> it is not useful to coordinate even that.

I've seen no questions about semantics.  The semantics are simple: the
function answers this question: "is this principal allowed to login to
this local user account?".  The specific mechanical details of how
that question is answered do not fall under "semantics".

> additions that I'd like to see standardized.

For me they are among many.

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 10:34:21 -0500

>               const gss_userok_config_t config,

What would the config argument be for?  How do you acquire any values
for it other than the NO_CONFIG one?

I'd rather avoid adding such arguments until we need them.  If this
about Simon's question regarding semantics, no I don't think it's
important, because be details of how this function works are
implementation-specific.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Apr 2011 17:38:05 +0200

> important, because be details of how this function works are

So we are back to something like this then?

OM_uint32
gss_loginok(OM_uint32 *minor,
            gss_const_name_t name,
            gss_const_buffert_t user,
            int *user_ok);

/Simon

---

From: Luke Howard <[email-masked]>
Date: Thu, 7 Apr 2011 01:39:05 +1000

To be specified. From Sam:

> Nico, I was talking to Luke about gss_userok.
> 
> I was thinking that it wanted to take a context for configuration so,
> add an input of a gss_userok_config_t, today only defining
> GSS_C_USEROK_NO_CONFIG.
> 
> I'm thinking we might want a number of configuration options in the
> future:
> n
> 1) Whether fallback to aname == lname is permitted?
> 
> 2) Whether to search for things like .k5login
> 
> 3) what mechanisms to allow authorization from.
> 
> I'm not sure whether we actually want those or not, but I think that's
> compelling enough to argue for extensible configuration.
> 
> We need to change the symbol name anyway because we don't want to make
> either gssint or __gss_ symbols public.
> 
> What are your thoughts?

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 10:40:56 -0500

>> I'm thinking we might want a number of configuration options in the

To me these are host configuration matters, not ones that the app
should specify.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Apr 2011 12:05:40 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    >> 
    >> I don't like any of the existing prototypes, but will live with
    >> the Solaris prototype.  I expect to propose an expanded prototype
    >> on the order of a year or so.

    Simon> Then it sounds as if this is not something that we want to
    Simon> standardize at all at this point?

No, please let's standardize this.

The issue I have is that I think you might want a configuration context
as an input.
So, for example you can have multiple usesO:

* Use for authorizing logins  say for ssh and friends
* use for authorizing sasl authorization identities--here checking home
     directory etc  or assuming a posix user would be bad
* possibly feeding in mechanism specific configuration

I initially wanted to standardize with a GSS_C_DEFAULT_USEROK_CONFIG and
not actually define manipulators for the config.
The functionality we need today is roughly what the solaris prototype
gives.
I just don't want to box us in.
However I'm happy to accept the Solaris prototype now and give an
extended API later if needed.

I definitely want to see standardization soon here because that will
help us convince applications to adopt.

---

From: Simon Wilkinson <[email-masked]>
Date: Wed, 6 Apr 2011 17:07:32 +0100

> To me these are host configuration matters, not ones that the app

I think this applies to many of the recent discussions about adding context or configuration parameters into GSS. All of the use cases I've seen so far are for host configuration matters that the application has little knowledge of. As use of GSS expands, and more and more pluggable GSS mechanisms become deployed, it's going to be unrealistic to expect applications to provide UI to allow every aspect of every possible GSS mechanism to be configured.

Cheers,

Simon.

---

From: Greg Hudson <[email-masked]>
Date: Wed, 06 Apr 2011 12:29:22 -0400

> extended API later if needed.

I would prefer not to add a config parameter that we don't have a
current use for.  I don't think there's a problem with changing the name
if we decide to add caller configuration later.  (More generally, I
favor extensibility plans which place the least complexity burden on the
current system, even if they don't lead to the most elegant future
result.  In many cases extensibility hooks turn out to be unneeded or,
worse, not quite the right shape.)

> help us convince applications to adopt.

I agree that standardizing is beneficial, although I'm not volunteering
to write a draft.  I think Martin raises a compelling point that we
shouldn't make this the first standardized GSSAPI function which takes a
"const char *" parameter; fixing that requires a departure from the Sun
prototype.

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 11:48:47 -0500

On Wed, Apr 6, 2011 at 11:29 AM, Greg Hudson <[email-masked]> wrote:
> current use for.  [...]

+1

We can always add a new function later.

> "const char *" parameter; fixing that requires a departure from the Sun

The only places where the GSS-APIv2u1 deals with strings are:

 - gss_import_name(), where the input is overloaded and can be
non-text, so it has to be a buffer
 - gss_display_name(), where the output must be released, so re-using
buffer so as to avoid having to add yet another release function must
have been quite tempting
 - gss_display_status() -- same deal as gss_display_name()

Now that we're adding a funciton with a string input which is always
text, never binary data, we really don't need to use gss_buffer_t for
that.  It hardly matters what the GSS-APIv2u1 did if it never had this
particular sort of input.

Nico
--

---

From: Tom Yu <[email-masked]>
Date: Wed, 06 Apr 2011 12:52:11 -0400

> typedef struct gss_userok_config *gss_userok_config_t;

Standards nitpick: the "_t" C identifier suffix is reserved by POSIX.
I know we already have a bunch of non-conforming names suffixed with
"_t" in the GSS-API C bindings, but have we deliberately chosen to
continue making new ones for the sake of consistency?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Apr 2011 13:16:58 -0400

Responding.

I've proposed specific non-host uses for the config parameter.
namely determining the authorization scope--whether we're authorizing
over SASL authorization identities, local accounts, or what.
That is clearly an application matter.
In preference I would prefer:

1) Luke's example with a config parameter
2) gss_userok with simon's prototype and gss_loginok with the Solaris
prototype
3) gss_loginok with the solaris prototype
4) gss_userok with the Solaris prototype
5) gss_userok with Simon's prototype
6) no standard

I believe that const char * is the appropriate thing to take for local
account names and authorization identities, so I disagree with Martin,
but I'd rather a gss_buffer_t than no standard.

---

From: Greg Hudson <[email-masked]>
Date: Wed, 06 Apr 2011 13:23:16 -0400

> but I'd rather a gss_buffer_t than no standard.

I am swayed by Nico's arguments on this point, so I no longer favor
changing to a gss_buffer_t.  A const char * is likely to be more
convenient for callers.

(Just for consensus-counting purposes.)

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 12:30:23 -0500

Sam, I'm really skeptical of the application specific userok options,
but let's grant that they are necessary for the sake of argument.  We
still couldn't standardize your proposed gss_userok() function without
also standardizing a function or set of functions for manipulating the
configuration argument for gss_userok().

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Apr 2011 13:34:31 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> Sam, I'm really skeptical of the application specific userok
    Nico> options, but let's grant that they are necessary for the sake
    Nico> of argument.  We still couldn't standardize your proposed
    Nico> gss_userok() function without also standardizing a function or
    Nico> set of functions for manipulating the configuration argument
    Nico> for gss_userok().

I disagree.  You may not want to.  That's fine.  However, we certainly
could. I argue that we should if we believe that we'll need that
extensibility, we are convinced it will be the right extensibility, but
we believe that the specifics of such an approach will take longer than
the base API.  I believe all those things are true.

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 12:34:55 -0500

> (Just for consensus-counting purposes.)

Thanks.  BTW, in the v3 API, should I ever restart that project, I
intend to split gss_import_name() into two functions:
gss3_import_query_name(), taking a const char *, and
gss3_import_name(), taking a buffer containing an exported name token.
 As for display_name and status, I'll make them output a const char **
that is released automatically (in the case of display_name it'd be
released when the name is release, and in the case of display_status
it'd be released when either display_status is called again or when
the caller context handle is released).

I'm not really happy, as you can tell, with some of the design choices
in the v2 API, particularly regarding memory management and the
gss_import_name() conflation.

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Apr 2011 12:36:39 -0500

> the base API.  I believe all those things are true.

I'm not interested in standardizing a half-specified API.  If you have
secret sauce for the configuration parameter then just add a private
version of gss_userok() with a different name and be done, but please
don't pollute the namespace for the rest of us.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Apr 2011 13:48:33 -0400

I think there's a way of stating what I want in a more gss friendly way.
This even addresses Martin's objection:

OM_uint32 gss_loginok (
		       OM_uint32 *minor,
		       gss_name_t authname,
		       gss_name_t lname);

Where authname is the result of authentication
and lname is the login/authorization/local name.

Lname SHOULd NOT|MUST NOT be an MN.

This addresses the concerns about const char * use and provides several existing options for exttensibility.

With gss_userok (Simon's prototype) as a common case convenience function, even the argument that having to import the lname is inconvenient goes away.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Apr 2011 21:49:52 +0200

> particular sort of input.

RFC 2744 discusses character strings too:

3.2.2. Character strings

   Certain multiple-word data items may be regarded as simple ISO
   Latin-1 character strings.  Examples are the printable strings passed
   to gss_import_name via the input_name_buffer parameter. Some GSS-API
   routines also return character strings.  All such character strings
   are passed between the application and the GSS-API implementation
   using the gss_buffer_t datatype, which is a pointer to a
   gss_buffer_desc object.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Wed, 6 Apr 2011 22:06:37 +0200 (MEST)

> The only places where the GSS-APIv2u1 deals with strings are:

I would like to draw your attention to

http://tools.ietf.org/html/rfc2744#section-3.2

http://tools.ietf.org/html/rfc2744#section-3.2.2

-Martin

---

From: Luke Howard <[email-masked]>
Date: Thu, 7 Apr 2011 08:33:05 +1000

> This addresses the concerns about const char * use and provides several existing options for exttensibility.

OK, I'm happy with this, although I would really prefer the name gss_userok_ext. I really don't like gss_loginok.

Do we have consensus?

-- Luke

---

From: Chris Newman <[email-masked]>
Date: Wed, 06 Apr 2011 18:48:37 -0700

> to resolve the same problem on the server side, I don't want to write

I find RFC 5803 a satisfactory option for server-side SCRAM storage.

		- Chris

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 7 Apr 2011 13:12:58 +0000

> additions that I'd like to see standardized.

The problem with gss_userok() is many of the protocols using gssapi there is no username to validate (sasl based one for example) and in may cases the OS, esp when connected to directory services, can do a lot better then "string-before-@" as username.

Love

---

From: [email-masked]
Date: Thu, 7 Apr 2011 11:45:36 -0400 (EDT)

Discussion is petering out a bit.  Here is where I stand (which is
important insofar as it will affect what happens on the MIT krb5
trunk, in the absence of progress on a standard):

* I like Sam's prototype which looks like:

OM_uint32 something(OM_uint32 *minor, gss_name_t authname, gss_name_t lname);

* I like the idea of a gss_userok() convenience wrapper using the Gnu
  GSS prototype, which will save some callers the trouble of importing
  the username and processing the error status.  I am open to Simon's
  concerns that what we are implementing does not match the
  documentation for the Gnu GSS gss_userok() symbol, but at this time
  I believe that the Gnu GSS documentation overspecifies the function
  (and specifies something inconsistent with GSSAPI concepts, and also
  inconsistent with what the Gnu GSS implementation does).

* A couple of people have pointed out circumstances to which
  gss_userok() is not applicable.  I'm not sure why.  The primary use
  case here is a protocol implementation which integrates with system
  accounts (e.g. sshd, ftpd), for a protocol which takes a requested
  username argument.  Other kinds of local names could be added into
  Sam's suggested prototype, but we don't currently have use csaes for
  those.  There are lots of authorization problems for which
  gss_userok is not interesting, and probably lots of mechanisms which
  won't have an interesting answer.  All of this was known going in.

* The name is, as usual, the most vexing question.  With Sam's
  prototype, variants on "gss_userok" and or "gss_loginok" are
  probably too restrictive in scope for the function name.  I've
  unfortunately lost Sam's most recent list of suggestions (I guess it
  didn't go to this list).  I currently favor
  gss_authorize_localname().

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Apr 2011 10:54:34 -0500

+1

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Apr 2011 09:12:23 +1000

> OM_uint32 something(OM_uint32 *minor, gss_name_t authname, gss_name_t lname);

What happened to user_ok boolean?

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Apr 2011 09:14:27 +1000

> OM_uint32 something(OM_uint32 *minor, gss_name_t authname, gss_name_t lname);

If this name is not a MN, this breaks SPI-as-API. Not that there's anything wrong with this, but the SPI will need to take a gss_const_buffer_t for now (unless you can explain to me how we should represent non-MNs as MNs).

Hence, +1 for gss_const_buffer_t or const char * (back where we started) from me.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Apr 2011 09:22:47 +1000

OK, I committed an untested implementation to moonshot-mechglue-fixes (this branch is otherwise merged now so I figure I can re-use it). Tweak away.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Apr 2011 10:18:31 +1000

Here's the prototype. I'm not saying I like anything about this API. OK, maybe that's a bit harsh. Using gss_name_t is clever.

int

OM_uint32
gss_authorize_localname(OM_uint32 *minor,
                        const gss_name_t name,
                        const gss_name_t user,
                        int *user_ok);

The SPI prototype is:

        OM_uint32               (*gssspi_authorize_localname)
        (
                    OM_uint32 *,        /* minor_status */
                    const gss_name_t,   /* pname */
                    gss_const_buffer_t, /* local user */
                    int *               /* user ok? */
        /* */);

-- Luke

On 08/04/2011, at 9:22 AM, Luke Howard wrote:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Apr 2011 10:57:19 +1000

It's kind of ugly that we're using "local-login-user" (as suggested by Sam) for the GSS attribute for the local name, but "localname" in gss_authorize_localname().

We should either 

* do nothing
* change the symbolic name from GSS_C_ATTR_LOCAL_LOGIN_USER to GSS_C_ATTR_LOCAL_NAME
* change both symbolic name and actual attribute name

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Apr 2011 10:59:44 +1000

> OK, I committed an untested implementation to moonshot-mechglue-fixes (this branch is otherwise merged now so I figure I can re-use it). Tweak away.

Similarly untested implementation committed to moonshot branch of Heimdal.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 8 Apr 2011 16:50:58 +1000

So, use something else, like gss_get_name_attribute...

Von meinem iPhone gesendet

---

From: Greg Hudson <[email-masked]>
Date: Fri, 08 Apr 2011 10:46:37 -0400

> What happened to user_ok boolean?

A good question.  Sam, was that an oversight, or did you intend the
function to return GSS_S_SUCCESS for authorized and GSS_S_UNAUTHORIZED
for unauthorized?  That way the mech could provide a reason for failure
via the minor code if it wants.

---

From: Greg Hudson <[email-masked]>
Date: Fri, 08 Apr 2011 10:54:35 -0400

On Thu, 2011-04-07 at 20:57 -0400, Luke Howard wrote:
> It's kind of ugly that we're using "local-login-user" (as suggested by
> Sam) for the GSS attribute for the local name, but "localname" in

My intention in picking gss_authorize_localname() was that "localname"
could eventually be a larger category than usernames (system login
accounts), even though right now we only have a use case for usernames.

>                     gss_const_buffer_t, /* local user */

I'd suggest a name type parameter in the SPI, to fully specify the
internal name.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Apr 2011 12:34:00 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    >> What happened to user_ok boolean?

    Greg> A good question.  Sam, was that an oversight, or did you
    Greg> intend the function to return GSS_S_SUCCESS for authorized and
    Greg> GSS_S_UNAUTHORIZED for unauthorized?  That way the mech could
    Greg> provide a reason for failure via the minor code if it wants.

That was an oversight.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 8 Apr 2011 17:25:35 +0000

7 apr 2011 kl. 08:45 skrev <[email-masked]>
 <[email-masked]>:

>  A couple of people have pointed out circumstances to which
>  those.

usecase: nfsd, smbd <- protocol that integrates with system accounts and don't have username.

Love

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Apr 2011 13:03:29 -0500

> usecase: nfsd, smbd <- protocol that integrates with system accounts and don't have username.

Solaris is probably a good example of how to handle this.  Its
RPCSEC_GSS library has an entry point where you pass it a GSS
principal name and it returns a UID, primary GID, and a list of
supplementary GIDs.

Because it takes a name as input it could work in any number of ways, such as:

 - extract PAD/PAD from the principal name, map SIDs and/or whatever
to UIDs/GIDs
 - call an aname2lname API on the given name and the do traditional
getpwnam_r() and getgroupsbymember() calls
 - lookup a database by principal name and return whatever is found there

Note that Solaris does have a GSS aname2lname function.  We should
standardize it as well!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Apr 2011 14:41:11 -0500

> via the minor code if it wants.

Strictly speaking the major status code would do.  If GSS_S_COMPLETE
then the principal is authorized, and if anything else then the
principal is not authorized and the major and minor status codes would
tell you that and possibly why.

The redundancy implied in the boolean output + major status code
output means that the API could be used incorrectly quite easily.
Dropping the boolean output may well be a valuable thing to do!

In any case, if we retain the boolean output we should state that it
must be used to output FALSE in any and all error conditions, that it
may only be set to TRUE when the function would return GSS_S_COMPLETE.

Nico
--

---

From: Simon Wilkinson <[email-masked]>
Date: Fri, 8 Apr 2011 20:42:01 +0100

> usecase: nfsd, smbd <- protocol that integrates with system accounts  

SSH is actually a use case here as well. The protocol specification  
permits the client to provide a null username, which makes the server  
pick the username that's appropriate for that authentication identity.  
The GSI folk implemented this for their fork of OpenSSH, but I haven't  
pulled their change into my patches, because they're pretty intrusive.  
Now that I've given up any hope of OpenSSH themselves doing GSSAPI  
completely, I should probably revisit this.

Cheers,

Simon.

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Apr 2011 08:37:26 +1000

> Note that Solaris does have a GSS aname2lname function.  We should

So does MIT, the same as Solaris.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Apr 2011 17:46:15 -0500

> So does MIT, the same as Solaris.

Oh, actually, Solaris doesn't have one.  SunSSH's sshd has an internal
one.  Excuse my lousy memory.

Can you post the MIT prototype?  Thanks!

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Apr 2011 08:54:51 +1000

Sorry it's not quite 2lname.

OM_uint32
gss_pname_to_uid(OM_uint32 *minor,
                 const gss_name_t pname,
                 const gss_OID mech_type,
                 uid_t *uidp)

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Apr 2011 10:23:14 +1000

Re: name type, good idea, I shall fix. Shall we require it in the Kerberos mech to be the null OID or...?

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Apr 2011 10:25:22 +1000

Is GSS_S_UNAUTHORIZED defined anywhere? I sort of prefer the separate argument but I realize it may set a trap for API consumers. I do want a way to distinguish between an authorization failure and some other error.

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Apr 2011 11:35:25 +1000

On 09/04/2011, at 10:23 AM, Luke Howard wrote:

> Re: name type, good idea, I shall fix. Shall we require it in the Kerberos mech to be the null OID 

OK, SPI fix committed to both MIT (moonshot-mechglue-fixes) and Heimdal (moonshot).

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Apr 2011 11:38:39 +1000

Which looks like (from Heimdal sources):

typedef OM_uint32 GSSAPI_CALLCONV _gss_authorize_localname_t (
               OM_uint32 *,             /* minor_status */
               const gss_name_t,        /* name */
               gss_const_buffer_t,      /* user */
               gss_const_OID,           /* user_name_type */
               int *                    /* user_ok */
              );

---

From: Greg Hudson <[email-masked]>
Date: Fri, 08 Apr 2011 23:20:31 -0400

On Fri, 2011-04-08 at 20:25 -0400, Luke Howard wrote:
> Is GSS_S_UNAUTHORIZED defined anywhere? 

Yes, in RFC 2743 and RFC 2744.

> Kerberos mech to be the null OID or...?

How would that work?  I would expect to require it to be
GSS_C_NT_USER_NAME.

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Apr 2011 13:24:59 +1000

> Yes, in RFC 2743 and RFC 2744.

OK, perhaps this is cleaner then.

> How would that work?  I would expect to require it to be

Right you are.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 9 Apr 2011 13:42:40 +1000

> Yes, in RFC 2743 and RFC 2744.

OK, now it looks like:

OM_uint32
                        const gss_name_t user);

Committed for Heimdal and MIT. Not tested yet. I'll try and do that next week.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sun, 10 Apr 2011 15:58:30 +1000

> Committed for Heimdal and MIT. Not tested yet. I'll try and do that next week.

Tested with MIT and OpenSSH.

-- LUke

---

From: Gerd Stolpmann <[email-masked]>
Date: Mon, 11 Apr 2011 16:23:35 +0200

> to resolve the same problem on the server side, I don't want to write

I've recently implemented SCRAM for GSS-API, but not as a C library, so
not the same limitations apply. I did it in Ocaml, and the GSS-API is
here an object interface. This opens the additional possibility that one
can pass down configurations at object instantiation time. This is of
course non-standard, but GSS-API is here not in the role of a
system-wide security provider, but merely as a "security plugin helper
technology" for client/server applications.

Anyway, at GSS-API instantiation time the caller specifies how to get
the password (on the client), or how to check the credentials (on the
server), just by providing additional callbacks. In some sense, these
are examples of context parameters that were recently discussed
(PGSSAPI).

For the applications I have in mind, the client password would simply
come from a config file. The server checks the credentials with an
authentication database.

Gerd

-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
[email-masked]          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 10:08:29 -0500

> are examples of context parameters that were recently discussed

Indeed.  If we had a caller context handle on every call, or an
implied one from name import time (the GSS-API really starts and ends
with NAMEs), then it'd be trivial to add a function by which to set a
callback on the caller context handle and presto: prompting without
adding complex variants of gss_acquire_cred(), gss_init_sec_context(),
gss_accept_sec_context(), ...

Ditto for setting an I/O event loop entry point and callback data.
Ditto for lots of things, really.

> come from a config file. The server checks the credentials with an

The simplest thing to do on the client side for now (so that one can
ship) is to have an externally primed cache of SCRAM passwords indexed
by {[initiator name], acceptor name}.  The next simplest thing is to
add an out of band interaction facility (i.e., a GUI dialog, when
there is an X11 display or what have you).  The last thing to do, and
the hardest, is to actually extend the GSS-API -- the hardest because
we have so many different opinions as to how best to design such
extensions :(

My recommendation to SCRAM GSS mechanism implementors is to pursue the
progression described above, including experimenting with GSS-API
extensions.  Eventually we'll have enough experience to standardize
something.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 10:13:28 -0500

> gss_pname_to_uid(OM_uint32 *minor,

Ah, yes.  Excuse my poor memory (and laziness -- I could have checked
OpenSolaris source to refresh my memory).

Anyways, we can't use uid_t in a standards-track API.  We should do
something else, say:

OM_uint32
gss_get_localname(OM_uint32 *minor, const gss_name_t pname,
gss_buffer_t localname);

Or maybe we want to output a non-MN gss_name_t, just like the new
userok API will use such a thing as a local name:

OM_uint32
gss_get_localname(OM_uint32 *minor, const gss_name_t pname, gss_name_t
*localname);

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Apr 2011 01:58:24 +0200 (MEST)

> gss_authorize_localname(OM_uint32 *minor,

Just an observation: what you're trying to accomplish here is actually
within the definition and scope of the combination of the two
existing GSS-API calls

gss_import_name() + gss_compare_name()

http://tools.ietf.org/html/rfc2743#page-70

And for the local account name you could use any one of these generic
nametypes:

   GSS_C_NT_MACHINE_UID_NAME or GSS_C_NT_STRING_UID_NAME 
   GSS_C_NT_USER_NAME

The former might result in a "more local" resolution than the latter.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 19:20:30 -0500

> gss_import_name() + gss_compare_name()

Martin,

Yes, we could all just implement the kind of logic that krb5_kuserok()
implements (roughly: scan a file associated with the given username
looking for a match for the given principal name) using the GSS-API
and at the application layer -- nothing new is needed.

And yet, that would be a lot of duplication.  Yes,
gss_authorize_localname() is a pure utility function, but a very, very
useful one.  And it's useful to have the mechglue implement it.  And
it's useful even for the mechglue to dispatch it to the mechanisms for
which 'name' is an MN.  Iit's useful to be able to have many apps
share the same implementation of this function, and to be able to
change the implementation at run-time (by changing system
configuration, for example).

And, as you know, some utility functions really belong in libraries.
This is one of those.  There are others in the GSS-API too, so it's
not like we're setting some sort of awful precedent.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Apr 2011 02:58:46 +0200 (MEST)

> not like we're setting some sort of awful precedent.

It was not and is not my intent to keep you from standardizing
this function.  And I previously indicated that I do not consider
the function to be "fully generic", so I'm fine with a new function with
clearly defined semantics for the purpose that you're envisioning.

However, I believe it is appropriate to document the limited
applicability of such a function to specific usage scenarios,
and it's likely dependence of a close integration of the gssapi
mechanism with the underlying OS.

As far as Kerberos 5 is concerned: is the Microsoft Kerberos implementation
and platform, which seems to clearly distinguish "network login" from
"interactive login", completely out-of-scope?

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Apr 2011 21:02:41 -0500

I'd be OK with adding a flag to distinguish between interactive and
non-interactive logins.  And a gss_name_t for the service performing the
login.  And...  well, we have to draw a line somewhere.  Here's the thing: I
don't see a real security distinction to be made here, or, if this
distinction matters, then.so do many others (remote vs. local, service type
-difficult to ascertain in the case of SSHv2-, and many things for which we
have no GSS analogs).

I'm for the KISS principle.  We can always add another function.  But if
others want this...

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Wed, 13 Apr 2011 12:37:13 +0200

> and at the application layer -- nothing new is needed.

Well, if I understand Martin correctly, we could also implement it at the GSS layer using gss_compare_name() and a name type that implied the mapping performed by krb5_kuserok().

-- Luke

---

From: Greg Hudson <[email-masked]>
Date: Wed, 13 Apr 2011 10:47:31 -0400

On Wed, 2011-04-13 at 06:37 -0400, Luke Howard wrote:
> Well, if I understand Martin correctly, we could also implement it at
> the GSS layer using gss_compare_name() and a name type that implied
> the mapping performed by krb5_kuserok().

I considered that interpretation too, but it seems like a bit of a
stretch.  If [email-masked] is listed in /home/buildbot/.k5login
on a machine, does that mean that the MN [email-masked] and the
internal name GSS_C_NT_USERNAME/buildbot "refer to the same entity" (RFC
2743 2.4.3)?  The first is authorized to perform arbitrary actions as
the second, but the reverse is not necessarily true.

> "interactive login", completely out-of-scope?

The simple answer is that, from my perspective, a remote/local
distinction is out of scope at this time, and I don't know what impact
that would have on someone trying to implement this for Microsoft
Kerberos.

The immediate use case is to make sshd more useful for GSS-EAP without
adding mechanism-specific logic to sshd (and in fact, taking the krb5
mechanism-specific logic out).  The people involved have a strong
understanding of the mechanism-specific login authorization policies
used on Unix login agents, but not necessarily for Windows.

Should this extension become a standard, the issue would definitely bear
further study.  For instance, does the MS Kerberos policy decompose into
something like (MN X lname) -> is-authorized and (lname X is-remote) ->
is-authorized?  Is it possible to guess with confidence whether a login
is remote/local based on global process state, as it is on Unix using
the tty name?  Does it make sense to use GSSAPI acceptor logic in a
Windows protocol implementation interfacing with system accounts, and if
so, does it only make sense for remote access, or for local access as
well?  If the remote/local distinction does turn out to be in scope,
would it be best represented as a flag parameter to gss_authorize_name,
or an attribute on the MN or local name?

I'm not qualified the answer these questions at the moment, and I'd
rather bear the cost of possibly choosing a new function name later than
of adding possibly misguided complexity now.

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Apr 2011 10:34:59 -0500

> the second, but the reverse is not necessarily true.

I thought that Martin meant that the application ought to implement
what krb5_kuserok() does using GSS' naming functions -- as opposed to
us specifying this function.  That's the only interpretation of
Martin's comment that made any sense.

But I want a portable API because I don't want apps to duplicate this
code, and I want the algorithm to be able to change at runtime.

> that would have on someone trying to implement this for Microsoft

It wouldn't be hard.  My problem is where do we stop?  I want to stop
here.  It costs little to add new functions.  Well, _this_ thread is
so long that the cost is not as low as I'd like it to be, but it's
still much lower than the cost of trying to figure out the Ultimate
API (tm) right now.  It would be nice if we could lower the cost of
each addition somewhat more without completely sacrificing review -we
did get useful review here, so this thread is not as bad as I just
made it sound-, but hey, c'est la vie.  The IANA registry will help!
(Right, I gotta get on that.)

I think it's fair enough to say that we have consensus on the specific
function prototype(s) and to move forward.  All we need is an I-D and
a track to aim for.  Informational will do, yes?  Proposed Standard
would be nice, but de facto will do for me.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Apr 2011 17:42:44 +0200 (MEST)

> the mapping performed by krb5_kuserok().

I did _not_ mean to suggest that you should use the existing calls.

I actually wrote in a followup:
=
= It was not and is not my intent to keep you from standardizing
= this function.  And I previously indicated that I do not consider
= the function to be "fully generic", so I'm fine with a new function with
= clearly defined semantics for the purpose that you're envisioning.

I just made an observation that there could already be implementations
of gss-api mechanisms doing what you want to do with
gss_import_name() + gss_compare_name(), and, while not being obvious,
it would be perfectly within the defined semantics of these functions.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Apr 2011 17:53:29 +0200 (MEST)

> the second, but the reverse is not necessarily true.

But now you're describing a behaviour that is completely different
from the previous discussion (I have no idea what krb5_kuserok() does).

What you're describing looks extremely app-specific, and not a result
of a tight integration of a gssapi mechanism with the underlying OS.

> that would have on someone trying to implement this for Microsoft

While I can perfectly understand anyone's reluctance to describe
behaviour for environments and platforms one is not familiar with,
the Microsoft Windows platform is probably the largest installed
base of an implementation of Kerberos 5 and it might really be
interesting to e.g. the Cygwin32 folks how to implement gss_userok()
for this environment.

Could we get some comments/thoughts from Larry Zhu on this?

-Martin

---

From: Greg Hudson <[email-masked]>
Date: Wed, 13 Apr 2011 12:44:57 -0400

> from the previous discussion (I have no idea what krb5_kuserok() does).

Which part of the previous discussion?  I probably didn't frame the
extension clearly enough when I started the thread.

The immediate goal of this extension is to make sshd useful with GSS-EAP
by replacing sshd's current call to krb5_kuserok() with a
mechanism-neutral API.  For Kerberos MNs and a Unix-ish krb5
implementation, this API should result into a call to krb5_kuserok().
How krb5_kuserok is implemented isn't really all that important, except
to note that it consults files and configuration rather than just
comparing pieces of the principal name and username.

> of a tight integration of a gssapi mechanism with the underlying OS.

sshd certainly didn't invent krb5_kuserok().  It was originally invented
(as I understand it) for the krb5-enabled versions of rlogin/rsh/rcp and
telnet.

I've already discussed the narrow applicability of this extension, at
least for unadorned GSS_C_NT_USERNAME lnames.  To want to use it, you
need to (1) be in the business of providing system account access to
authenticated entities, and (2) be implementing a protocol where the
initiator identifies a target username.  Right now that roughly
translates into being sshd or gssftpd.  SMB and NFS servers would be
candidate users except (as I understand it) the initiator doesn't
identify a target username in those protocols, so for those you need an
MN-to-lname mapping facility instead.  krb5 has one of those too, and
maybe people will some day want a mechanism-neutral interface for that
as well.  But that's out of scope for now.

My primary goal in starting this thread was to coordinate the
specification of this extension across the MIT krb5, Solaris, Heimdal,
and Gnu GSS mechglues, as there was a conflict in the first pass.  A
secondary goal was choosing a specification which might be extensible to
related use cases and which might be appropriate to standardize (while
still minimizing complexity).  It won't particularly bother me if the
secondary goal doesn't come to light.

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Apr 2011 12:04:34 -0500

> secondary goal doesn't come to light.

As long as it ends up on the upcoming IANA registry, I don't care if
an RFC is even published.  I don't want to see any further collisions
occurring as a result of implementors shipping extensions not
registered anywhere.

I would prefer that an RFC be published and I don't see why there
would be any obstacle to that at this point, certainly not for an
Informational RFC.  I don't see a problem with making this a Proposed
Standard either -- every OS has a notion of username, and ones that
don't can just implement a stub for this function.

---

From: Luke Howard <[email-masked]>
Date: Thu, 14 Apr 2011 14:17:00 +0200

> or an attribute on the MN or local name?

If we were doing an SSPI implementation of a new mechanism then we'd need a PAC anyway (at least for any service that wanted to do impersonation), and at that point we have enough information to delegate the authorization to Windows.

-- Luke