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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos