On Thu, Mar 06, 2008 at 04:45:33AM +0100, Roland Mainz wrote: > Nicolas Williams wrote: > > The files and NIS backends for publickey(4) only supports 192-bit keys, > > which are too weak, > > Which is (AFAIK) fixable (isn't there even a RFE for that already ?) ...
The AUTH_DH/mech_dh stuff is obsolete technology (not Obsolete in ARC speak though). I'd want to see significant improvements beyond addition of large key support for the files and NIS backends (also, NIS has the length(data) <= 1024 problem in the protocol, and length(key) + length(data) == 1024 from NDBM; 1024-bit keys still fit, provided you don't have too many keys hashing into the same NDBM bucket). Another protocol issue with AUTH_DH: E(password, exponent) is publically available, thus subject to passive off-line dictionary attacks. Kerberos V doesn't have this problem (because of pre-authentication) -- you have to be an eavesdropper in order to get material suitable for off-line dictionary attacks. This could be fixed, of course, but it greatly complicates the task of modernizing the protocol and deploying it. > > and without NIS/NIS+/LDAP then you get no non-local > > benefit from having any entries in /etc/publickey unless you manually > > maintain it. > > Right... but it's still easier to handle than setting-up Kerberos5 (and But it still gets you nothing. Also, the pam_krb5_migrate(5) approach could be used to create credentials for any network authentication scheme that supports the use of passwords, Kerberos, mech_dh, whatever. > > Network security requires the deployment of authentication > > infrastructure or ad-hoc, SSH publickey-like leap-of-faith > > authentication. The files backend of publickey(4) != either. > > > > Also, I'm not sure that any method of X11 display authentication other > > than cookies makes sense unless we want users to be able to share their > > displays with *other* users. > > The need to share displays is quite common at least on universities > and/or if you want to do something like a presentation or demo in such > an environment. From my experience the syntax of $ xhost +username@ # is > MUCH more user-friendly. I have never seen a need to share entire displays that couldn't be solved in some other way (vnc, xkibitz, whatever). > > Consider: if the only reason to forward krb5 creds to a remote server is > > so I can use them to open my local display then I've given that server > > the ability to impersonate me to all others just so I could access my > > display from that server -- how odd! I could just use cookies, and then > > I need not give that server anything too valuable. X11 cookies works > > *fine* for SSH. > > I disagree for the "fine" - it just works very poorly. The ssh port > forwarding+encryption+decryption needs giant amounts of CPU time and > adds lots of latency and even defeats all the fine-grained buffer > flushes in the X11 code by just copying the data without caring about > things like X11 packet boundaries. Just try a simple experiment and run > quake2 remotely, one time via normal X11 and one time via ssh > forwarding. The ssh forwarding makes such an application unuseable (or > the more real-world experiment would be X11 over a high-latency > (satellite) link - if you use ssh the applications will become > unuseable...). Is it the crypto that kills? Or the small channel windows? Or the latency from context switching? Or the matter of matching forwarded display channel I/O sizes to X11 message boundaries? Do any of the non-cookie approaches provide confidentiality and integrity protection options? For all the things I do cookies work fine. > (There are other issues like that last time I checked their code OpenSSH > doesn't use the SECRUITY extension to make new MIT-MAGIC-COOKIEs and > just shares the original one (which is a serious security issue, > something which ssh.com's version of ssh fixed long ago by trying to use > the SECURITY extension first) or that the obsolete cookies aren't > removes properly either) You haven't checked in a long time then. Nico --
