randall@Virginia.EDU (Randall Atkinson) (06/18/91)
In article <STJOHNS.91Jun16205511@umd5.umd.edu>, Mike St. Johns <stjohns@umd5.umd.edu> writes: % The functionality of RFC931 was very limited and in any case has been % subsumed by two other very good protocols - KERBEROS and SNMP. In article <29102.Jun1800.35.2891@kramden.acf.nyu.edu>, Dan Bernstein <brnstnd@kramden.acf.nyu.edu> writes: > I have nothing against Kerberos. I think it's a good start; I even wrote > some code for Kerberos v5. But the current implementation simply cannot > be used to authenticate, e.g., mail between nyu.edu and umd.edu, at > least not without a lot of work. Surely you want some authentication > outside your local network? > > I just heard about SNMP's proposed security mechanism. I don't like it. > It's ridiculously vulnerable to known-plaintext, even chosen-plaintext > attacks, especially given the stylized format of SNMP output. And it > still won't help you outside your local network unless you've exchanged > a whole bunch of keys in advance. > > I agree that RFC 931 doesn't do a whole lot. It just provides usernames. > But that's enough to stop what is by far the most common type of mail > forgery. I think that the Internet Protocol Suite does need to have viable authentication mechanisms built in to the protocols (hopefully most people agree that the current lack of authentication is a problem). 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). I've cross-posted this to alt.security because it is clearly of interest there as well.
oberman@ptavv.llnl.gov (06/19/91)
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.
bcn@cs.washington.edu (Clifford Neuman) (06/19/91)
From: oberman@ptavv.llnl.gov Subject: Re: Authentication & Internet Protocol Suite Date: 18 Jun 91 20:10:44 GMT The real problem is that Kerberos requires at least one trusted system to hold ALL keys (the KDC). The trusted system need only hold the keys for local clients and servers (called a realm). If the server is compromised, this isolates the damage to the principals registered in that realm. The problem arises when you want to do Kerberos authentication across the Internet. [This] is a problem in that you must maintain a table containing the access information for every other realm you plan on dealing with. In version 5, realms can be organized hierarchically. Thus, you can often get by maintaining entries for only immediate ancestors and descendants in the tree. 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. But this is true for any system, even public key based systems. You are trusting the certification authority for the remote realm to accurately identify the principal you are communicating with. 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. The problems that you cite for Kerberos also exist for public-key based systems. If the key of the certification authority is compromised, an attacker can impersonate anyone in the "realm" of that authority. Some public key based systems take the certification authority offline in an attempt to make it more secure. Once taken offline, however, the credentials issued by the certification authority have to be very long lived. This presents a problem for revocation. Revocation is dealt with by maintaining revocation lists on online authentication servers, but these servers then become vulnerable to attack. ~ Cliff
erc@Apple.COM (Ed Carp) (06/25/91)
It seems that the whole issue revolves around the insupportability of secure channels for the exchange of keys. Typical problem: A wants to send B a secure message, and he wants to make sure that only B can read it. You have to have a secure channel to exchange secrets so that you can agree on keys for encryption. No such secure channel exists. Phil Karn's work with insecure login via packet radio has merit (time-slice), but I'd rather see something akin to public key crypto. I'd sure like a piece of that software...:) -- Ed Carp N7EKG/6 erc@khijol.UUCP ...uunet!khijol!erc Packet: N7EKG @ N6IIU.#NOCAL.CA.US UUWEST Consulting Alameda, CA 415/814-0550 Computers HAVE caused a revolution in how much information we can safely ignore! --robs@ux1.cso.uiuc.edu (Rob Schaeffer) -- Absolutely unabashed Gates McFadden groupie! --