Re: Using gsasl_encode/decode()

[Phil Pennock]

On 2021-12-12 at 10:31 -0800, Kevin J. McCarthy wrote:
> In Mutt's cyrus-sasl implementation, after authentication occurs, Mutt will
> add a layer over the socket that calls sasl_decode() for reads and
> sasl_encode() for writes; though I've never been clear why this is
> necessary.

Disclaimer: I'm not a GSASL maintainer, just a server and client
developer with experience using both the APIs you reference.

SASL provides both authentication and setup for privacy layers, which
historically were (if memory serves) RC4 streams with DIGEST-MD5 and
whatever Kerberos wants for GSSAPI (typically).

In the modern era where all secure links should be inside TLS, I think
this can be safely ignored as a relic of the past.

As long as you repeat the handshake steps as often as needed to complete
all the steps, you should be fine?  GSASL_QOP defaults to `qop-auth`, so
if you're not changing that then the client side should only be asking
for authentication (not INTegrity or CONFidentiality).

Just make sure you do follow the steps until the step functions say
you're truly done, so that client verification of the server happens and
GSSAPI can send the authorization ID.  But then, IMO, ignore
sasl_encode/sasl_decode.

> Is it correct practice to use those functions after authentication for
> libgss too?  If they are optional, then is there a way to disable needing to
> use them via a property or something?

Don't set GSASL_QOP to request integrity or confidentiality layers and
you won't need them.

-Phil