Re: krb_match_realm

On Nov 1, 2007, at 1:40 PM, Magnus Hagander wrote:

> Henry B. Hotz wrote:
>> Thank you very much. This helps, but I'm still evaluating how much.
>>
>> I *can* point at one problem though: you do a strchr(gbuf.value,
>> '@')
>> and then error out if there isn't a Kerberos realm there. In fact
>> that
>> is exactly the default username of at least one of the GSSAPI
>> implementations I've tested if the realm is the same as the local
>> default realm.
>
> Eh, so how do we then determine the difference between local realm and
> no realm given?

Well, what I've seen is: no realm given if and only if the default
local realm matches the realm for the GSSAPI username. I don't think
that's guaranteed.

>> I'm not entirely sure what the intended semantics of krb_match_realm
>> are, but if you're trying to match the GSSAPI-authenticated name
>> against
>> "value_of(PGUSER)@value_of(krb_match_realm)" then you need to
>> construct
>> that string, gss_import_name() it, and then gss_compare_name() the
>> imported name with the authenticated name that GSSAPI already gave
>> you.
>> I know the API overhead of doing that is a PITA, but that's what's
>> going
>> to work.
>
> Why?

Because if we're using the GSSAPI then we need to use the properties
defined by the GSSAPI, and not depend on observed behavior of
specific implementations of specific mechanisms. Otherwise things
will be non-portable or unreliable in ways that may be non-obvious.

In particular gss_display_name() produces a character string intended
for display to a human being. It is *NOT* intended for access
control. As another example, Heimdal gss_display_name() puts '\'
escapes in front of special characters in the username. I don't
think it's worth writing special case code for that either.

The standard defines two ways to do comparisons for access control.
We should use one of them. Anything else is going to be more work
and less reliable.

> (FWIW, it works perfectly fine in my test setups, so I'd really
> like to
> know why this won't work)

I may be able to flag specific failures, as I've done here, but I'm
sure I can't imagine all the ways that evading the standard might
cause problems. Perhaps that's not helpful or not what you want, but
it's all I can do.

>> I also notice you have some code to do case insensitive name
>> matching.
>> I assume this is to take care of the fact that Microsoft Kerberos
>> does
>> case insensitive name matching (contrary to the standard and the
>> other
>> Kerberos implementations out there). I suspect issues there, but it
>> will be 3-6 months before I will have an environment where I can
>> easily
>> test this. Most likely, the way to handle this is by figuring out
>> what
>> case Microsoft uses for each name inside the protocol and then
>> pre-mapping to that case before feeding things to (non-Microsoft)
>> GSSAPI.
>
> Yes, it's for supporting Active Directory. It's there in the same way
> it's there for krb5.
>
>
>> I don't regard the case mapping issues as serious. We may not
>> have the
>> intended level of Windows/Unix compatibility, but I don't expect
>> other
>> issues. In other words I'm not even going to think about it until
>> it's
>> easy for me to investigate.
>
> Note that it's turned *off* by default, so it shouldn't even affect
> you.

Not my current concern. If I find a problem, then I'll be in a
position to define how it ought to be done (*IF* it needs to be done
differently).

>>> Attached patch implements krb_match_realm for krb5, gssapi and
>>> sspi per
>>> complaint from Henry. Comments welcome.
>>>
>>> Working on documentation which will of course be ready when it's
>>> committed :)
>>>
>>> Oh, and it changes the krb username handling to be the same as the
>>> gssapi one. I've never heard of anybody actually using the other
>>> version
>>> that it used to support, and the comment clearly states that it was
>>> broken for the really complex scenarios anyway - something nobody
>>> has
>>> complained about.
>>
>> Well, *I* complained about it. ;-)
>
> Um, not sure we're talking about the same thing. I know you complained
> about the inability to match realm, but did you complain about the
> inability to use things like full X.500 names as usernames?
>
>
> //Magnus

Well, it's not a high priority for me, but there is a GSSAPI
mechanism called SPKM which uses X500-syle names (X509 certificate
subject names to be precise). If we use gss_name_compare() properly
then it should "just work".