Re: BUG #9337: SSPI/GSSAPI with mismatched user names

On Mon, Feb 24, 2014 at 6:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Um.  I spoke imprecisely, I see.  The objection to involving a Kerberos
> server in determining the username is not solely about the cycles
> involved; it's that it requires identifying a specific Kerberos server
> to do it.  Don't we lose multi-realm support if we have to know the
> server's password in advance of examining pg_hba.conf?

Not as far as I know. For GSSAPI, the server determines which password
to use based on the ticket, which includes the server's principal
name, and it looks it up in its own key file (PG's krb_server_keyfile
option). (For SSPI, I don't think you can use multiple passwords; if
coming from another domain, you'd need Active Directory's assistance
to cross the domain correctly.)

I also went back and checked, and the server does not have to contact
a Kerberos server to authenticate the client or determine its user
name. So long as the ticket is encrypted with the correct password
(Postgres's password), Postgres can decrypt it and know who the client
is and that they're really who they say they are.

The picture on this page will help:

http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fintroductiontokerberosauthentication.htm

Steps 1 and 2 in that graph are the client authenticating to the KDC.
Step 3 is the client telling the KDC it wants to talk to a Postgres
server, and it gives Postgres's principal name (such as
"POSTGRES/mymachine.realm.com@REALM.COM"). In step 4, the KDC returns
a ticket encrypted with Postgres's password.

In step 5, Postgres receives the client's ticket, and decrypts it with
its own password. If it decrypts properly and checks out, Postgres
knows it's legit, because only the KDC should know Postgres's
password. Inside will be the user's name.


> I looked at our docs again and notice that there is no authentication
> server specification option for the GSSAPI auth method.  I guess that
> that information is buried within the "server key file" or someplace;
> this goes beyond my knowledge of Kerberos internals I fear.  I do see
> that there isn't any visible specification of a server password either,
> so even absent the multi-realm issue it's not clear to me that what
> you propose is practical for code outside the Kerberos libraries.

Yes, the password is in the key file.

Since this request has turned out to be a little more complicated than
I thought, I'd like to volunteer to research it further and maybe
bring it along. It's not part of my job duties right now, so I'll have
to come back and visit it later, but so far I don't see anything
obvious that would make it unfeasible. The GSSAPI/Kerberos case looks
the easiest. SSPI/Negotiate will be harder because that requires
passing data back and forth; you couldn't finish in one packet.

Interesting problem.

--Brian