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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos