galvin@TIS.COM (James M Galvin) (06/21/91)
There have been a few message about RFC 931 and authenticated SMTP and I would like to add a few words that have not been stated and correct a few things that have been stated. This is a long message, but it covers RFC 931, Kerberos, PEM, and SNMP security, respectively. 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. Mike St. Johns, the author of RFC 931 has said this. Let me quote from the RFC itself: Unfortunately, the trustworthiness of the various host systems that might implement an authentication server will vary quite a bit. It is up to the various applications that will use the server to determine the amount of trust they will place in the returned information. It may be appropriate in some cases to restrict the use of the server to within a locally controlled subnet. The problem is you have no reason to believe anything a 931 server tells you in the general case. If I know nothing about the relative security or insecurity of your host -- which has a high probability of being true when receiving "arbitrary" ftp, smtp, and telnet connections -- why should I "trust" anything you tell me about the source of your connection request. Dan Bernstein has said a 931 server "provides enough additional security to stop those pesky undergraduates from forging mail (at least without a network machine of their own)". Insofar as he is speaking about an environment which is "a locally controlled subnet", he is absolutely right. After all, if they are your machines you know how secure or insecure they are and whether or not to believe anything they tell you. 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. I may choose to define my configuration as a secure architecture, but I can not impose that on other autonomous Internet subscribers. The Internet is a collection of cooperating autonomous domains, not a tightly-coupled collection of autonomous domains, which I believe would be true if a secure architecture existed. 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. Last time I checked TCP was as insecure as almost every other Internet protocol. Kerberos is better than RFC 931, in the Internet today. The reason is because it supports a complete infrastructure, a secure architecture, with which "secure" applications can be built. 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). PEM is also better than RFC 931, and contrary to recent press here there will be an openly available implementation this year. The implementation is being provided by Trusted Information Systems (my employer), BBN, and RSA Data Security, Incorporated. We are currently beta testing an operational system now. Like Kerberos, it supports a complete infrastructure. By the way, it is provides end-to-end security, so as long as your user agent is RFC 822 compliant, it is independent of the transport used, e.g., SMTP or UUCP. Thus, no patches to Sendmail are necessary to support PEM. PEM will work on BSD derived UNIX machines, which covers a good portion of the Internet. Unfortunately, every little compile/install step is not automated, but then there is no comparison between its complexity and that of any RFC 931 implementation. Finally, as for SNMP security being ridiculously vulnerable to known-plaintext, even chosen-plaintext attacks, I must disagree. The SNMP security protocols may have limited vulnerability to known-plaintext attacks. If privacy is used, this assumes you know the query that was sent. If not, the response is meaningless. While it is true an attacker has a high probability of knowing certain bytes in a query -- because ASN.1 encoding is used -- this is a small part of the overall message and it is not obvious to me how this is helpful enough to suggest the vulnerability is ridiculous. 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. This is not possible in the security protocols as defined. You only get what you send, so if you send plaintext that is what you get back. If you send ciphertext you get back ciphertext. 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 6 party identifiers initially, 3 for the agent and 3 for the management station. All further key exchanges and creation of parties can be completely automatic and transparent to the user. Six is hardly "a whole bunch". Jim
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/22/91)
In article <9106201757.AA15689@TIS.COM> James M Galvin <galvin@TIS.COM> 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 <anonymous>@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