[32364] in Kerberos
Re: bug: krb5_get_host_realm() no longer uses DNS
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Mon May 17 18:23:07 2010
Date: Mon, 17 May 2010 17:21:04 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Simon Wilkinson <simon@sxw.org.uk>
Message-ID: <20100517222104.GH9429@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <463B58EF-E216-4EE0-8E3C-C6AC23C31370@sxw.org.uk>
Cc: Richard Silverman <res@qoxp.net>, "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
