> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org] > On Behalf Of Jonathan Billings > > The reason why I think that Brandon and I are really pushing this > concept is that this is pretty well-established crypto. It works > really well. It has its downsides -- and I think if I were arguing > for your position, I'd be familiar enough with the state of the art to > be able to voice a problem with using SPNEGO.
The whole point of the thread (and of cbcrypt) is to never expose passwords or encryption keys to servers, because hackers or bad employees sometimes get it and do bad stuff with it. Kerberos is good for the situations where it works, but because it requires passwords to be exposed to the KDC, it's not helpful or interesting in the development or design of cbcrypt. The whole tangent about "password was sent to KDC," versus "it was entered into the KDC some other way" is irrelevant. The situations that cbcrypt is intended to address are very common, typical situations: User opens a connection to some server (where they weren't pre-authenticated via Kerberos, SSO, etc, so they actually need to be presented with a login prompt, and hence SPNEGO (if applicable) is already concluded with the decision to authenticate via login prompt). They should be able to authenticate without exposing their password. BTW, this characteristic would be nice to add to Kerberos and OAuth, but that's not something I'm immediately looking into. _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
