flanker (./8) :
Windows est passé à Kerberos, si je ne me trompe pas ^^

C'est plus compliqué que ça, en fait... Depuis Windows Server 2000, le domaine permet une négociation du protocole de la part du client (si le client en est capable, c'est Kerberos qui prime, sinon le ticket est NTLM). Hors d'un domaine, c'est du NTLM qui est utilisé (typiquement, si l'ordinateur de vince n'est pas sur un domaine ou si le proxy n'est pas sur le domaine mais est lié à un environnement Microsoft, c'est NTLM qui sera utilisé - sachant qu'on peut très bien avoir, pour un squid, client Windows [NTLM] -> Auth Samba [NTLM] -> Auth Linux [Kerberos] (ou autre chose, comme une authentification via PAM) -> Auth Squid [Kerberos / ou autre chose]). C'est la magie des SSO, on peut les chaîner de façon transparente (ou presque).
Typiquement, on trouve des configurations dans les universités qui permettent des passages entre les systèmes d'authentification NTLM <-> Kerberos <-> CAS <-> Shibboleth (avec des morceaux de LDAP et d'AD au milieu, et des morceaux de SASL dedans).

flanker (./8) :
Par contre, je ne vois pas du tout pourquoi un proxy HTTP laisserait passer un flux SSH

Tu as des proxy http qui sont liés dynamiquement à un pare-feu. Si tu es authentifié sur le proxy, alors tes flux réseau passent (et peuvent être loggés à minima, c'est à dire timestamp, identifiant, source, destination). En cas de coupure du lien avec le proxy, tu perds l'autorisation.
Cela dit, c'est généralement dans un environnement où on n'a pas trop la maîtrise des machines, sinon on préfère le 802.1x (filaire) qui est plus efficace et qui peut, lui aussi, être couplé à l'authentification sur le domaine dans un environnement MS.

Mais je crois en effet que vince cherchait à faire du SSH over HTTP, à la base.