SANON cred export/import never worked correctly as the export function was
producing the wrong form of token, which was leading gss_import_cred() to
allocate more than 64MB of memory to parse the SANON exported credential. The
recent change to reduce the default `max_alloc` of krb5_storage exposed this.
SAnon includes channel bindings as part of the key derivation function, so they
cannot be ignored. Always set GSS_C_CHANNEL_BOUND_FLAG in the SAnon acceptor.
SAnon unconditionally sets the replay, sequence, confidentiality, and integrity
flags on the acceptor; do so on the initiator as well. Some indentation
cleanups are also included in this commit.
In SAnon, the optional flags send in the initial context token are input into
the key derivation function. Mask out the flags we wish to ignore after (not
before) calling the key derivation function, as the initiator may not know
which flags we wish to ignore.
In SAnon:
The is_initiator bitfield must be unsigned to avoid undefined behaviour, as
there is only a single bit defined. Thanks to Nico Williams for explaining
this.
We were passing SANON flags to _gss_mg_import_rfc4121_context(), which
wants GSS flags. Meanwhile, I broke gss_inquire_context() on imported
SAnon contexts when I did my review of SAnon.
This commit fixes both issues and removes SANON_FLAG_*, which were only
ever needed because of a flag to track whether a context was locally
initiated or accepted. Now we use a separate int field of the sanon_ctx
to track whether a context was locally initiated. Once an SAnon context
is fully established, we rely on gss_inquire_context() on the rfc4121
sub-context for all metadata that isn't the initiator and acceptor names
nor the mechanism OID.
Add support for SAnon, a simple key agreement protocol that provides no
authentication of initiator or acceptor using x25519 ECDH key exchange.
See doc/standardization/draft-howard-gss-sanon-xx.txt for a protocol
description.
