Design Considerations for New Authentication Methods

I've been looking at adding SASL or GSSAPI as an auth method. I have
some questions about how to handle the flow of control changes.

When you do one of the above, an authentication is not (necessarily)
a simple one-packet exchange. In fact the exchange may involve
trying several different authentication mechanisms before you find
one that works.

The question is how do I handle the multiple round-trips where one
trip is now assumed?

The simple approach is for me to just put the loop inside the
relevant fe-auth.c and auth.c sections, corresponding to where the
pg_krb5_{send,recv}auth() calls are. However the comments in the
code make it sound like people are very concerned about the number of
round trips and network accesses done. I notice that all the
authentication (pg_fe_sendauth()) is done inside PWConnectPoll(),
which sounds like something that isn't expected to block on network
access.

Is this behavior important during startup? Or is it only important
once the connection is fully established?

I haven't looked at the corresponding logic on the server side, but
I'd assume that it forks before we get to this point so it doesn't
matter.
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu