Kerberos Password Sniffing
fod at brd.ie
Sun Dec 1 07:27:57 EST 2002
Thanks for the informative response. I am just a bit frustrated because
(a) even a point solution would be better than nothing, and (b) people
are highly misinformed about this.
For example, the ability to run the login exchange with confidentiality
for high privilege accounts would be a good start. As you point out,
this could be achieved in some circumstances using TLS. For particular
access points and implementations (notably W2K) it could be done today
using IPSEC (or perhaps SSH), albeit in an admittedly kludgy setup,
however without changing the kerberos standard. Meanwhile password
quality controls remain very important.
Additionally, I don't see any of this properly highlighted in the krb
FAQ. Maybe it's there and I missed it. Offline attacks are mentioned,
but the message is that it's solved by preauth.
I appreciate that it's much more difficult to create a standard than an
implementation fix. However in this instance trying to get it
gold-plated is a bit like failing to get out of the way of a large
oncoming truck because running would mess up your hair.
Jeffrey Altman wrote:
> There are a large number of factors:
> . do not want to require the use of PKINIT solutions since the whole
> point of Kerberos is that Kerberos is the trust third party and
> we do not want to need to worry about all of the problems surrounding
> PK management
> . do not want to require the use of TLS over which the Kerberos
> exchange could take place; both because of the added crypto
> overhead and because most Kerberos implementations do not yet
> support non-UDP exchanges
> . do not want to require the use of Zero Knowledge Inference solutions
> such as EKE, SPEKE, and SRP because of all the intellectual property
> issues surrounding the various patent claims.
> Once you go through that list what are we left with?
> The working group has been talking about a variety of solutions that could
> be standardized. Perhaps SRP for open source deployments and SPEKE for
> commerical ones. Some people might want the TLS solution. In any case,
> the IETF has had a hard enough time just coming to consensus on the
> Kerberos 5 Clarifications document let alone addressing all of the many
> other needs which may be dependent on Kerberos 5 Revisions.
> Kerberos 5 Clarifications plus the Crypto updates and AES support
> should go the IESG within the next month. Then we will start to work
> on PKINIT, PKCROSS, Set/Change Password, and the Revisions document.
> Rapid progress should be acheivable from this point forward.
> In article <3DE9EB4B.1080504 at brd.ie>, Frank O'Dwyer <fod at brd.ie> wrote:
> : Can you elaborate on the solutions that are being considered and what
> : the timetable is?
> : Also at the risk of sounding curmudgeonly, what's the hold up? I and
> : others have been banging on about this vulnerability for years now. Why
> : does it take the announcement of a tool to light a fire under people,
> : when the possibility of such a tool has been obvious and well documented
> : in the literature for over 10 years, as have the various possible fixes?
> : There is also some breakdown in communication going on, since there are
> : 1000s of admins out there who have somehow got the message that Kerberos
> : is "unsniffable". Which is true in theory (PKINIT etc), yet in practical
> : terms is far from the truth.
> : I suppose we're lucky that this guy hasn't put a nice GUI on the tool.
> : Yet.
> : Cheers,
> : Frank.
> : Sam Hartman wrote:
> : > You should note that fixing offline dictionary attacks is a current
> : > work item of the Kerberos working group of the IETF; solutions are
> : > basically understood but need to be written up and implemented.
> : >
> : > ________________________________________________
> : > Kerberos mailing list Kerberos at mit.edu
> : > http://mailman.mit.edu/mailman/listinfo/kerberos
> : >
> Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!!
> The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP
> http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and
> kermit-support at columbia.edu OpenSSL.
More information about the Kerberos