Security Area Advisory Group (SAAG) IETF 67, San Diego, California, USA Minutes compiled by David Johnston, Donald Eastlake, and Russ Housley Agenda WG Session Reports BOF Session Reports Invited Presentations - Embedding Security Knowledge in RFCs -- By Venkat Pothamsetty - Real Attacks and Threat Models -- By Steve Bellovin - How Not To Protect PC's From Power Analysis -- By Russ Housley on behalf of Adi Shamir Open Microphone ------------------------------------------------------------------------ WG and BOF Session Reports As usual, the SAAG session began with Working Group and BOF Reports. Each Working Group or BOF that had a meeting at IETF 67 gave a very brief summary of the session. Please see the minutes for each of these sessions for more details. The highlights are not repeated here. Reports were provited by these Working Groups (in the order that they met during the week): - EMU (Joe Salowey) - MSEC (Ran Canetii and Lakshminath Dondeti) - BTNS (Love Hornquist-Astrand) - DKIM (Stephen Farrell and Barry Leiba) - KRB-WG (Jeffrey Hutzelman) - KITTEN (Jeffrey Altman) - NEA (Steven Hanna and Susan Thomson) - HOKEY (Charles Clancy and Glen Zorn) - SASL (Tom Yu and Kurt Zeilenga) - PKIX (Steve Kent and Stefan Santesson) - S/MIME (Blake Ramsdell and Sean Turner) - ISMS (Juergen Schoenwaelder and Juergen Quittek) - LTANS (Tobias Gondrom and Carl Wallace) - TLS (Pasi Eronen and Eric Rescorla) Reports were provited by these BOFs (again, in the order that they met during the week): - SPKM (Jeff Hutzelman) - KEYPROV (Phillip Hallam-Baker and Susan Cannon) ------------------------------------------------------------------------ Embedding Security Knowledge in RFCs Venkat Pothamsetty http://www3.ietf.org/proceedings/06nov/slides/saag-1.ppt Implementations should come out robust even if their implementers blindly follow the RFC protocol specifications. We have not seen vulnerability types and attack types change much over the last 5+ years. Limits scope of the knowledge. Education on writing secure code important and, we should not leave this to be the weakest link. Security considerations in RFCs inconsistent. Looked at why do implementers make the same mistakes? Implementers followed the RFCs. Security considerations sections are not exhaustive. Educating implementers not scalable. Fixing RFCs is scalable, there are a lot more implementers than specification writers. Lists Meyers seven sins of specifiers. Q: I have been involved in text based protocols. Some have full ABNF formal specifications. But this seems to have been no help on buffer overflows and other implementation flaws. Some fields are inherently infinite except for implementation constraints. Security Considerations in RFCs are better than they have been in the past. So we are doing much of what you suggest, but it has been of little help. A: Some things like packet rate are not in Security Considerations so far. Q: First, the implication of what you say is that protocols written in ASN.1 should have no problems. But we do continue to see problems because the parsing problem is hard. Second, people are making mistakes in translating even perfect specifications into code. Should we write implementations in some new language that is closer to the specification language. A: I am not proposing a formal language. That was just one example. The current situation is like building a building without having a building code. I'm suggestion there should be a building code. Q: I didn't think you were talking about a formal language. As a result, I have no idea what you are talking about. You used RADIUS as an example in your presentation, and the RADIUS specification cannot be understood in one reading. After reading the specification 2 or 3 or 5 times, one will discover that it does fully specify packet content, length, and so on. It is possible to do correct implementations from the specification. So what is the problem again? A: Well, current specifications don't provide all that I am suggesting. Even a low packet rate can kill some IPsec implementations. Why not have the IPsec specification give a packet rate? Q: It's a good idea to have better specifications, but formal languages don't cut it. How much would it delay documents due to arguments over details required for a full formal language specification? I recommend against putting in packet rates. Correct rate limits depend too much on specific context. But it sure would be good to have better implementations. A: I wrote a separate Security Considerations document for a specification done outside IETF. Implementers seem to like it. Q: I don't think it makes any difference what language in which the specification is written. The issue is that you have to make mid-parse decisions in almost every protocol. If an RFC could be all ABNF, you could do a perfect implementation. In the real world, you always have to partially parse, and then make decisions before parsing further. Q: Changing the implementation language to be more like the specification language works to improve implementation reliability. Q: I support the use of formal specifications, but you have to do the right specification. There were bugs in the Berkeley FTP daemon because of subtle bugs in the original specification. Buffer overflow errors are not found early because specifications usually say things like "shall handle messages up to 4K bytes," but the specifications do not say "fail gracefully for anything over 4K." Q: ISCA laboratories has lots of real experience in testing products. (... Some examples of very bad implementations were given. ...) There are only so many steps we can take to improve things. More specifications should include state machines. They need more focus on proper handling of unexpected messages and unexpected conditions. ------------------------------------------------------------------------ Real Attacks and Threat Models Steve Bellovin http://www3.ietf.org/proceedings/06nov/slides/saag-3.pdf Those crazy scenarios the security guys come up with are real! They are out there in the wild. We need to take into account the elevated threat model today. The Computer Science Departmeent at Columbia University was informed that our FTP server was launching attacks. We disconnected it, and the reports continued! Someone was spoofing the IP and MAC address of the server. It was traced to a firewall in a different building on campus, which was communicating to a machine in Sweden every four minutes. We then disconnected that machine. When we brought up the FTP server, the attack started up again. Something local was monitoring, perhaps looking for gratuitous ARP. We found deliberately broken SYNs, which were probably being used for communication with another compromised local machine. We had gotten a couple of complaints about the FTP server, but when we tested our FTP server internally, it worked fine. Only outsiders, going through a higher level switch, got failures. Further, the local testing temporarily fixed the problem due to bridge learning. Investigation showed that machines had been compromised for months and had used hundreds of different legitimate MAC addresses. The attack was noticed in October, but logs show that it was already underway in May. We know that there are other compromised machines in the department, but we do not knnow which ones. When we turned it off, we had a few days of intermittent DOS attacks from spoofed MAC addresses inside our LAN, perhaps in retaliation. Conclusion: there are some very sophisticated bad guys out there. While talking about this to someone at the IETF, they told me they had experienced something very similar. So have been at least two cases of this in the wild. It only takes one sophisticated bad guy to enable many script-kiddies. Q: Were you using SEND (Secure Network Discovery)? A: SEND would have prevented the MAC spoofing. We were not using it. One needs SEND support on the switch, not just the host. C: People should come to the plenary tonight. Steve is talking about the tip of an ice berg. We will talk about the ice that is below the water line tonight. C: Switches can limit the number of MAC addresses on a port. Next time someone complains about your FTP server, I'll be happy to test from off campus. Q: Most people don't publicize anything about attacks. Thanks for giving us some more details. I was hoping that INCH would help. We need to spot patterns of attacks. A: The compromised box had a Linux 2.4 kernel. C: We hear about attacks but mostly about DDoS multi-box attacks. This was a single box attack. A while ago we heard reports of attacks on DNS servers. Initial reports blamed botnets. In fact, it turned out to be 10 UNIX servers that had been compromised and used DNSSEC as to amplify the traffic. C: Some working groups in IETF say that these crazy threats don't apply to their protocol. Well, they really do. ------------------------------------------------------------------------ How Not To Protect PC's From Power Analysis Yossi Oren and Adi Shamir (presented by Russ Housley) http://www3.ietf.org/proceedings/06nov/slides/saag-4.ppt The most dangerous part of a PC is the USB port! Many companies disable these ports to prevent data downloading. However, it is also an excellent way to do power analysis. We tried doing a simple power analysis over a few minutes without opening the cover of the computer. Few found lots of high frequency variation. We also found that you couldn't disable the port with OS or BIOS or USB security programs. Shorting pins finally stopped the power. But even with no power, high frequency signals were still there. Conclusion: Power analysis does not require power! Q: I've done implementations designed to fix the number of clock cycles for crypto operations. A: Constant time does not mean constant power. Q: Well, it is pretty close. (... This was disputed by many people in the room. It seems easier to do for symmetric operations thna asymmetric ones. ...) ------------------------------------------------------------------------ Open Microphone C: I'd like to commend all of the speakers for getting their slides to Russ and Sam in time for them to be posted before the session. The has not been the case at other recent SAAG meetings. C: I notice that two presentations had the same theme. You have to remember the layers below you, like spoofing MAC addresses and power analysis. Both are widely know and commonly forgotten. Need to open analysis to all layers of the protocol stack. Q: As an addition to the first presentation, to aid protocol testing we should provide not only a flow test general document, but also a torture test document. While you can't test everything, that sort of thing has found a lot of problems. Implementers understand test cases. C: I'd like to second the recommendation for documenting torture tests. A: SIP and S/MIME have documents that include test data for things that are supposed to work as well as things that are supposed to fail. C: Maybe the protocol specification people shouldn't do the tests. Hard enough to find people to do the protocol work. There are things like Google Summer of Programming which show that programming resources are available. Maybe grad students would be available to write attack tools and tests. C: Protocol designers have best idea of where weak points are. Implementors need to know too. Protocol designers should include warnings in their documents. C: There are companies that sell test suites.