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