bug: krb5_get_host_realm() no longer uses DNS

Nicolas Williams Nicolas.Williams at oracle.com
Mon May 17 18:21:04 EDT 2010


On Mon, May 17, 2010 at 11:00:36PM +0100, Simon Wilkinson wrote:
> On 17 May 2010, at 22:07, Nicolas Williams wrote:
> > You can always use GSS_C_NO_CREDENTIAL and then inquire the established
> > security context's acceptor principal name to see that it matches what
> > you expected.
> 
> When I added StrictAcceptorCheck support to my OpenSSH patches (and to
> rot in their bugzilla) I thought about doing this. But I never managed
> to find a mechanism and GSSAPI implementation independent way of
> getting a name out of the GSSAPI in a format that I could check
> against the expected name (host@<something>). If that now exists, I'd
> be happy to revisit this.

There's technically two ways to do this comparison:

Method #1: Use gss_compare_name() to compare a name obtained by calling
           gss_import_name() on "host@<hostname>" to the acceptor name
	   returned by gss_inquire_context().

Method #2: Use memcmp() to compare exported name tokens obtained by
           applying gss_export_name() to the acceptor name returned by
	   gss_inquire_context() and to the MN returned by applying
	   gss_canonicalize_name() to the name returned by
	   gss_import_name("host@<hostname>").  (Obviously, if the two
	   exported name tokens have different lengths then the names
	   are not equal and there's no need to memcmp().)

In _this_ case I think method #1 is best.  (Normally, for name-based
access controls method #2 is better.)

(The method that might seem more obvious to newcomers, of trying to
compare display forms of names, is not correct nor portable across
mechanisms.)

> Bear in mind that the OpenSSH GSSAPI code is designed to work with
> mechanisms other than Kerberos, and with implementations other than
> MIT. Changes that require mechanism or implementation specific hacks
> are not desirable.

The above is intended to be portable across mechanisms.

GSS-API principal name comparison is described in RFCs 2743 (section
1.1.5) and 2744 (section 3.10).

Nico
-- 



More information about the Kerberos mailing list