Kerberos Password Sniffing

[Frank O'Dwyer]

Jeffrey,

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.

Cheers,
Frank

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.