Re: krb_match_realm - Mailing list pgsql-patches

On Nov 9, 2007, at 5:24 AM, Magnus Hagander wrote:

>
> On Tue, 2007-11-06 at 18:10 -0800, Henry B. Hotz wrote:
>> On Nov 6, 2007, at 6:27 AM, Magnus Hagander wrote:
>>> On Fri, Nov 02, 2007 at 11:23:30AM -0700, Henry B. Hotz wrote:
>>>>>>>> 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.
>>>>>
>>>>> Ok. I can see that point. However, if you have those characters in
>>>>> your
>>>>> username, you may have other problems as well :-)
>>>>
>>>> Yeah.  Not many people put spaces inside usernames.
>>>
>>> I think we can easily get away with not covering that case.
>>
>> *sigh*  Yeah, maybe we have to live with it.
>
> Yeah, that's kind of where I'm going - it's certainly not perfect, but
> it's the least bad one.
>
> Given this, I'll go ahead with the current version of the patch,
> and we
> can consider making better changes at a later time assuming we figure
> them out. It's still a lot better than what's in there now, and it
> *will* cover the vast majority of cases.
>
> I'll address Stephens comments separately.
>
>
>>>> It's guaranteed to produce a unique, canonicalized name based on
>>>> the
>>>> specific mechanism in use.  It is suitable for memcmp().  The
>>>> exported name will re-import.  Section 3.10 of rfc 2744
>>>> describes all
>>>> this, and appears to be clearer than the Sun document I pointed you
>>>> at.  Certainly it's more concise.  YMMV.
>>>
>>> Hmm. But it doesn't serve our purpose.
>>
>> Well, it *might* work to do a memcmp() of tolower() of the blobs.
>
> Right, but if they're defined as blobs, that's even less safe than we
> did before.
>
>
>>>> No gss_compare_name() is case sensitive.  I think the way to do
>>>> it is
>>>> to know what case Microsoft is going to use and pre-map
>>>> everything to
>>>> that case (before you do a gss_import_name()).  I *think* Microsoft
>>>> will use upper case for the service name so we will need to change
>>>> from "postgres" to "POSTGRES" as the default name in service
>>>> principals.  I've seen places where they may be using lower case
>>>> realm names (which makes *NO* sense to me).
>>>
>>> No. Microsoft will send you whatever case the user put into the
>>> login box
>>> when he logged into windows. It's case-*preserving*, but case-
>>> insensitive.
>>
>> That can't be entirely true.  Maybe it's true for Microsoft's RC4
>> enctype, but it can't be true for the des-cbc-md5 enctype.  The
>> protocol runs with some case, and the question is what case it uses
>> when it matters.
>
> Haven't protocol-traced it, but our systems use des-cbc-md5. It's the
> only one I managed to get working with pg server running on Linux and
> clients running on Windows. And in this case, the case insensitive/
> case
> preserving behavior is a fact.

I was thinking that the case of the principal affects the protocol,
but actually I guess that's only true for the string-to-key
function.  That would affect a user's ability to get the initial tgt,
but not how service tickets are handled.  Given case preservation,
that would guarantee the correct case for a non-Windows client (for
both Windows and Unix servers), but nowhere else.

Kind of blows the SSPI/GSSAPI compatibility that's supposed to
exist.  I think I may start a discussion of this on an IETF list in
case people want to update the GSSAPI standard.

I suppose you win.  Just do a gss_display_name() and do a case
insensitive compare.  I can't do any independent verification.
*bleah*  Can you leave the compare inside gssapi if it's not  case
insensitive though?

>>>> I assume in AD you can't create both "smith" and "Smith", but can
>> you
>>>> create the latter at all?  If you do, does AD remember the case for
>>>> display purposes?  Here at JPL usernames are lower case, and I
>>>> don't
>>>> think we allow anything special but hyphens in them, so I'm not
>>>> likely to see a lot of the possible corner cases.
>>>
>>> You can and it remembers. But it has no effect on what is sent ni
>>> the
>>> kerberos packets - what's sent there is what the user typed in.
>>> Yes, that
>>> sucks bad, but that's how it is.
>>
>> Hmmm.  See above.  It isn't possible to make it irrelevant
>> everywhere, unless you only use RC4.  Vista uses AES so it looses
>> that loophole though.
>>
> Yeah, I haven't tried Vista at all. I've only done 2000, XP and 2003.
>
>
>> I wonder if case conversion is the right way to create compatibility
>> with GSSAPI though.  If the user always comes in with a specific case
>> then shouldn't we instead find a way to make sure the PG user is
>> created with the corresponding case?  There are several ways you can
>> test for the existence of a user in a Kerberos service, for example
>> kinit with a garbage password will give different errors.
>
> That's why we have krb5_caseninsens_users - to let the user choose it.
>
>
> //Magnus
>

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu