RFC 4121 & acceptor subkey use in MIC token generation

[Ken Hornstein]

To give some background, we are required to do security scanning of our
systems using Tenable's security scanner product (which is variously
known as Nessus, Tenable.sc, or ACAS if you're in the DoD; I'm aware
that these all aren't the same thing but in practice they all seemed to
be lumped together).  This requires the scanning software to actually
log into our systems and run a bunch of commands.

This product actually supports Kerberos (ssh using gssapi-with-mic)
and I got that working fine to our Linux systems.  Those systems are
running the CentOS vendor ssh which is linked against the CentOS MIT
Kerberos libraries.  It is worth noting that the client side Kerberos
implementation on the Tenable side is written in the NASL language and
is relatively primitive; the source code to this implementation is
available and it is relatively straightforward to follow.

I tried to get this working to MacOS X systems, using the vendor ssh
which is linked against the Apple Heimdal-based Kerberos libraries, and
that did not work (but did not return or log a useful error); using the
CentOS vendor ssh client worked fine against the same system.  After a
whole lot of debugging (which included staring at a bunch of hex dumps
and hand-decoding some ASN.1) here's what I found.

The Tenable code is doing the AP-REQ/AP-REP exchange with the MacOS ssh
server fine, but the GSSAPI MIC is being rejected by the sshd daemon.
This is because (a) the AP-REP from the ssh server includes a subkey
(b) the MIC sent by the Tenable client does NOT use the subkey from the
AP-REP but instead unconditionally uses the service ticket session key
and the 'flags' field in the MIC is 0x00 (c) the Heimdal code rejects
the MIC based on the rules in RFC 4121 § 2.

This works against MIT-linked ssh daemons because even though the MIT
code does return a subkey in the AP-REP it does not enforce the requirement
in RFC 4121.  Instead the appropriate code has this comment (k5sealv3.c):

    /* Two things to note here.

       First, we can't really enforce the use of the acceptor's subkey,
       if we're the acceptor; the initiator may have sent messages
       before getting the subkey.  We could probably enforce it if
       we're the initiator.

(There's more, but not exactly relevant to this).  The code below
this comment only uses an acceptor subkey _if_ there is one available
and the initiator sets the appropriate flag in the MIC token.

So, obviously this is a problem with the Tenable client code and I
have to figure out how to submit a bug to them (which sadly might be
a challenge, sigh; at least from my looking at the Tenable code it's
80% of the way there).  But this makes me wonder ... is the above comment
correct?

I ask because it doesn't seem to me like it is.  I was under the impression
that when you're doing mutual authentication (which in my experience
is pretty much all of the time) you can't send any other GSSAPI tokens
until authentication is complete and if authentication is complete then
you can definiteley be assured any subkeys have already been exchanged.
Clearly Heimdal enforces this and other than this obviously wrong client
code I am not aware of any operational issues.  Am I wrong?  I admit
that is always a possibility!

--Ken