The ATEN/Supermicro KVM does not do standard VNC. Their protocol is a hacked up version of vnc’s RFB v3.8. It only supports a proprietary authentication protocol which it claims is type 16 (tight). Alas it is lying and it is not.
http://blog.flameeyes.eu/2012/07/more-on-the-supermicro-ikvm: The problem with the authentication is that for whatever the reason, it’s not a clear user/password auth. Instead it uses some hash or unique identifier, which changes each time I connect to the web interface — I’m not sure if it’s a hash, it’s definitely not an OTP (as I can start multiple instances of the javaws applet without having to re-download the JNLP), or just a nonce-based authentication, but it’s used both as user and as password. Actually I had a hunch while looking into it and I confirmed that what it uses is the same SID saved as a cookie after my login on the web interface.
A prerequisite for this to get integrated will be good documentation of how the protocol works, since I'm neither capable nor interested in reverse engineering it. Even better would be a working patch. Another thing is that compatibility with this KVM can't cause any new compatibility problems with existing servers. Hopefully they're using their own proprietary code numbers at some point to signal their extensions, but some other unambiguous method of detection would also be okay.
One observation I'll make is that Tight authentication is not so much an authentication method so much as a way of activating a number of Tight-specific extensions. It might be using that as a way to signal its own proprietary extensions.