Kerberos error codes

[Greg Hudson]

On 04/20/2016 09:51 AM, Dylan Klomparens wrote:
> The gss_accept_sec_context function has a "major" error code (it's return
> value) and a "minor" error code to convey Kerberos specific errors. I am
> able to find plenty of documentation on the major error code. However, I am
> unable to find a list of Kerberos specific error codes within GSSAPI. Does
> anyone know where this might be documented? If it's not documented, I will
> be happy to write the documentation and submit a pull request on Github.

A GSS application cannot draw any inference from minor code values; the
only thing it can do is pass them to gss_display_status() to produce a
human-readable message.

One can easily imagine a world where each mechanism documents its minor
codes, and applications can draw inference from {mech, minor code}
pairs.  Or, you could imagine a world where mech implementations
coordinate assignment of minor codes so that there are no conflicts.
Unfortunately, in the real world:

* You don't always know what mech corresponds to a minor code.  For
instance, a call to gss_acquire_cred() could yield a minor code from any
of the requested mechs.

* There is no coordination of minor codes between mechs, and different
implementations of the same mech (e.g. Heimdal and MIT krb5) use
completely different minor codes.

* Minor codes may be generated by the mechglue as well as from a mech
(for out-of-memory conditions, invalid or unknown mech OIDs, failure to
load mechs, etc.).

* In the MIT implementation, the mechglue will map the minor code into a
table so that gss_display_status() works on the minor code without a
corresponding mech_type.

> My other question is, why does MIT recommend using GSSAPI over the libkrb5
> API directly? From a design perspective, I'd like to minimize the number of
> dependencies that my program has. By minimizing dependencies, complexity
> and potential attack surface (for application security) is reduced for my
> program. If my requirement is that I only need to verify service tickets
> from clients, am I better off using libkrb5 directly?

There are several reasons:

* A GSS-API application can work with security mechanisms other than
Kerberos.

* A GSS-API application using krb5 can interoperate with a Microsoft
application using SSPI; that's essentially impossible if you use libkrb5
directly.

* The GSS token formats, particularly for per-message tokens, are better
designed than the libkrb5 token formats.

If you don't care about the interoperability concerns and aren't using
per-message tokens, and you are concerned about getting more
fine-grained errors, then using krb5_mk_req() and krb5_rd_req() directly
may make sense.  However, you should also be aware of the risks of only
verifying service tickets and not using krb5 or GSS-API to protect
protocol data:

* If you are using an unprotected channel (e.g. raw TCP), a passive
attacker can read your protocol's data, and an active attacker can
modify the protocol's data or use the mk_req token to impersonate the
client.

* If you are using a protected but unauthenticated channel (such as TLS
without verifying the server cert), then an attacker can MITM the
channel and modify the protocol data.  This kind of attack can be
prevented with channel bindings if GSS-API is used.

* A rogue server can use the mk_req token to impersonate the client to a
different server.