On Mon, Feb 24, 2014 at 3:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If it's possible to get a name out of a ticket without contacting a
> realm server, I think what you're talking about would likely be all right.
> IIUC this approach would also save one round trip to the client to get
> the ticket once we've decided to use SSPI auth, so that seems like a
> potential benefit independently of where the username is coming from.
Well, for starters, it turns out I'm wrong about the principal. Only
the target principal (that of the Postgres server) is in clear text.
The source principal (my user name) is in the encrypted part of the
request, so that can _only_ be decrypted by the server. However, if I
remember right, the server will be in direct possession of the
decryption key (IIRC, its own password), and therefore should be able
to determine the user name without contacting a third server.
This will require more research.
> One question worth asking is whether exposing the ticket in the startup
> packet is problematic if the startup packet is unencrypted and can be
> snooped by third parties.
Kerberos takes care of encryption of the ticket. It's really just the
same mechanism that's already in place, and with the same encryption,
just pushed to Postgres instead of Postgres asking for it.
MD5 passwords, on the other hand, have to wait for a salt from the
server before they can be sent, so they can't take advantage of this
shortcut.
--Brian