Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!ucbvax!TIS.COM!galvin From: galvin@TIS.COM (James M Galvin) Newsgroups: comp.protocols.tcp-ip Subject: RFC 931, PEM, and SNMP Security Message-ID: <9106201757.AA15689@TIS.COM> Date: 20 Jun 91 17:57:07 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: James M Galvin Organization: The Internet Lines: 93 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