Xref: utzoo comp.protocols.tcp-ip:16585 alt.security:2684 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!ptavv.llnl.gov!oberman From: oberman@ptavv.llnl.gov Newsgroups: comp.protocols.tcp-ip,alt.security Subject: Re: Authentication & Internet Protocol Suite Message-ID: <1991Jun18.131044.1@ptavv.llnl.gov> Date: 18 Jun 91 20:10:44 GMT References: <6201.Jun1504.10.2091@kramden.acf.nyu.edu> <29102.Jun1800.35.2891@kramden.acf.nyu.edu> <1991Jun18.142936.5962@murdoch.acc.Virginia.EDU> Sender: usenet@lll-winken.LLNL.GOV Followup-To: comp.protocols.tcp-ip,alt.security Distribution: inet Lines: 46 Nntp-Posting-Host: ptavv.llnl.gov In article <1991Jun18.142936.5962@murdoch.acc.Virginia.EDU>, randall@Virginia.EDU (Randall Atkinson) writes: > I haven't read the new SNMP draft yet, but I have read the Kerberos > documentation. I think Kerberos does a good job, but I'd like to see > authentication supported by the basic protocols rather than relying > exclusively on Kerberos addons. Also, key distribution continues to > rear its ugly head (barring the arrival of inexpensive & easily > obtained RSA licenses and keys). First, Kerberos does not use RSA encryption. It is entirely based on DES. Since it is free and keys are private, there is no problem. The real problem is that Kerberos requires at least one trusted system to hold ALL keys (the KDC). This means that this system, if breached, can destroy everything. This system is normally not available from the net, so this is not as serious as it sounds, as long as you have a "local" KDC. The problem arises when you want to do Kerberos authentication across the Internet. Unless you are willing to turn all of your secrets over to a third party (and I'm not), you must build a table of trusted systems to exchange key information. While this is not a security problem since you don't ever actually exchange any of the secrets, it is a problem in that you must maintain a table containing the access information for every other realm you plan on dealing with. Also, the security between realms can only be trusted as much as you can trust the security of the remote KDCs and the information you use to allow their access to your realm. I would also question the idea of having protocols do their own authentication. A uniform system of authentication is one of the cornerstones on which Kerberos was built. What is needed is attention to providing authentication checking when protocols are designed. Things like NFS are NOT easy (possible?) to do this with. The MIT "Kerberized" NFS only does authentication at mount time since there is no practical way to do this for each access in such a stateless engine. The real answer is a public key based authentication system such as the Digital Equipment "Sphinx" system and the forthcoming DSSA system. The problem of cheap keys may be well on its way to resolution with the BB&N key meter, analogous with a posstage meter, for issuing keys. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything. Especially anything gnu.