Kerberos Password Sniffing

[Jeffrey Altman]

Frank:

Its not like we are trying to find the perfect solution.  But we 
are trying to find one that is manageable.  The vast majority of 
systems using Kerberos do not have IP-Sec.  Using SSH would be even 
worse since you then have another key laying around on an insecure 
file system.  TLS is a possibility but it too requires the distribution
of keys, certificates, ...

The use of TLS with ADH would halt the ability to passively sniff 
but still leave the man in the middle attack open.

Many of the suggested solutions do not work in environments such as 
Packet Cable.

The one solution that we know does work and that which seems most 
natural to the end user is the ZKI solution.  You want frustrating?
Talk to a bunch of lawyers over the question of whether or not the
SP-EKE patent covers SRP.  If it does not, we will implement SRP
tomorrow and get this over with since Stanford already gave the 
community the right to use SRP for this purpose.  However, if there
is any doubt what so ever we can't implement it without opening the
door to major patent infringement lawsuits for all involved.

 - Jeff



In article <3DEA003D.8050408 at brd.ie>, Frank O'Dwyer  <fod at brd.ie> wrote:
: 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.
: 


 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.