Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!umich!ox.com!yale.edu!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.protocols.tcp-ip Subject: Re: RFC 931, PEM, and SNMP Security Message-ID: <21769.Jun2122.27.1091@kramden.acf.nyu.edu> Date: 21 Jun 91 22:27:10 GMT References: <9106201757.AA15689@TIS.COM> Organization: IR Lines: 149 In article <9106201757.AA15689@TIS.COM> James M Galvin writes: > First, RFC 931 is not a security panacea. Let me say that again more > strongly. RFC 931 does not, can not, and will not solve the security > problems of the Internet. Agreed. It just establishes a minimum standard for security above the TCP level. Mail forgers, news forgers, and Internet system crackers all rely heavily on the anonymity of a TCP connection from a mainframe with many accounts. RFC 931 strips away that anonymity. Surely you agree that this is a worthwhile minimum standard? > The problem is you have no reason to believe anything a 931 server tells > you in the general case. I've never understood the logic in that argument. I think people are forgetting that RFC 931 usernames must be interpreted *in the context of the machine generating the usernames*. Let me explain. With RFC 931, you get addresses like shmoe@tis.com instead of @tis.com. It is patently obvious that you can trust ``shmoe'' only if you trust tis.com and the communications links between yourself and tis.com. Similarly, if you get an address like shmoe@mac37.opennet.tis.com, you can trust ``shmoe'' only if you trust mac37.opennet.tis.com, tis.com's name server, and the communications links. Trust, of course, is only as strong as its weakest link. So what? One important application of RFC 931 is to trace network attacks. If you record an address like shmoe@tis.com, you can talk to TIS later, and if they take responsibility for tis.com then shmoe@tis.com is in trouble. If you record an address like shmoe@mac37.opennet.tis.com, and TIS tells you later that mac37 is owned by Sally Smuthers, then Sally is going to have some explaining to do. In other words, you identify the first place where trust was violated, and find out who was responsible for that place. It is *absolutely*, *totally* irrelevant whether the information received *past* that place is accurate or can be trusted. In this case, it is *absolutely*, *totally* irrelevant whether you get shmoe@mac37 or sally@mac37 or nobody@mac37. Yes, James, Sally can forge any username she wants on mac37, because it's her machine. But because she has responsibility for it, there is absolutely no need to trace attacks further than the machine itself. You say that it's a problem that usernames can't be trusted unless the machine can. I don't believe you. Why is it a problem? Let me guess at your answer. It is a problem if you trust a username *independently* of the host reporting the username---if, for instance, you say that any user named ``root'' on any machine on the Internet can log in to yours, provided that RFC 931 reports root. But that's a really stupid thing to do. RFC 931 presumes that usernames are taken in the context of the system reporting the username. So, James, why is RFC 931 a problem? It *does* increase security in the case of a mainframe---shmoe@tis.com can no longer hide behind anonymous TCP connections. This is a definite improvement, one that will help CERT tremendously, and I don't see why you're so opposed to it. > However, the Internet does not have a secure architecture. To suggest > that 931 supports TCP authentication in the absence of a secure > architecture is ludicrous. But it does stop all attacks above TCP. In fact, it makes some below-TCP attacks much more difficult, because (in Steve Bellovin's words) it uses a second TCP connection not under control of the attacker. I'd love to see you try a source routing attack against an RFC 931-cognizant host. > The bottom line is RFC 931 does not stop all username forgeries above > the TCP level in the general case. And, to suggest that to break RFC > 931 requires breaking TCP security makes no sense. Uh, wait a minute. I don't understand either of those statements. RFC 931 *does* stop all username forgeries above the TCP level. That's practically the definition of the protocol. What did you mean to say? Breaking RFC 931 *does* require breaking TCP security---you cannot forge a username unless you can forge TCP packets. (This is, of course, vacuously true when you have complete control over the machine.) Let me put this differently. If someone comes up with a secure version of TCP---say, TCP with good encryption---and plugs in RFC 931, SMTP and NNTP and TELNET and other user-level TCP protocols will be completely secure. No ifs, ands, or buts. > Kerberos is better than RFC 931, in the Internet today. I agree that Kerberos is a far more secure protocol, since it addresses security both above and below TCP, and only allows half a dozen major attacks as outlined by Bellovin. If you can convince all vendors to support Kerberos v5 in systems they release tomorrow, and if you can make it work across wide-area nets without an n^2 exchange of passwords at the top level, and if you can convince the U.S. government to export it to Europe, and if you can get rid of all the bugs, then it will be quite usable in practice. Or have you forgotten that Europe is part of the Internet? Same comments about PEM---though of course PEM is useless for tracing Internet attackers. In fact, Kerberos is too, unless you throw out all the old telnetds which people need for wide-area logins. > With RFC 931, secure > applications must be built on it, as opposed to with it, i.e., the > access control policy must be rebuilt for each application (or at least > repeated for it). What do you mean by this? > Finally, as for SNMP security being ridiculously vulnerable to > known-plaintext, even chosen-plaintext attacks, I must disagree. Okay, I should have explained this better. In practice, it's quite obvious from the most basic traffic analysis exactly what information machines are asking from each other. Let's assume you can only figure out 1% of the SNMP queries; that's more than enough for cryptanalysis. The responses are not only in an extremely structured format, but contain essentially public information. If host A gives SNMP information to hosts X and Y, and host X can intercept even a fraction of the encrypted traffic to host Y, then it can ask for the same information itself and have completely known plaintext for a whole bunch of packets. That's what I was calling ridiculous. Even if host X can't get any of the information, it can guess pretty well---SNMP-reported userids come in order, each network connection is specified by 12 bytes carrying only a few bytes worth of information, etc. > I do not see how the protocols are subject to chosen-plaintext attacks. > This kind of attack assumes I can submit a plaintext message and receive > a ciphertext message in return. Yep. In practice you can ask host Y something that will make it send a known SNMP query to host A. (Simple example, derived from one of the proposed uses of SNMP: Ask Y's mailer to verify an address at A.) There are dozens of ways to do this. > I must also disagree with the comment that the SNMP security protocols > require the exchange of a whole bunch of keys in advance. A careful > reading of the specifications will tell you that a management station > and an agent need only share That's the problem, right there. If you have N trusted hosts that exchange SNMP information, you need N^2 keys. That's unusable. Do you still disagree? ---Dan