Security Area Advisory Group (SAAG) IETF66, Montreal, Quebec, Canada Minutes compiled by Pasi Eronen, Donald Eastlake, and Russ Housley Agenda WG Session Reports BOF Session Reports Invited Presentations - Why BGP and IPsec do not play well together (Brian Weis) - Expectations for Security Sections and Review (Dan Romascanu) Open Microphone ------------------------------------------------------------------------ WG and BOF Session Reports As usual, the SAAG session began with Working Group and BFF Reports. Each Working Group or BOF that had a meeting at IETF 66 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. Three Working Groups (KRB-WG, KITTEN, and SASL) performed an experiment this week. There were two extra wireless microphones to move around for discussions, and a second projector for the Jabber Log. There were some remote participants, and these worked well for them. Sam and Russ asked the chairs of these Working Groups to post their opinions on what worked well so other working groups can learn from their experiences. Reports were provited by these Working Groups (in the order that they met during the week): - KRB-WG - Kitten - LTANS - SASL - PKIX - BTNS - TLS - DKIM - OpenPGP - MSEC - EMU - INCH - ISMS - S/MIME Reports were provited by these BOFs (again, in the order that they met during the week): - NEA - HOAKEY After the HOAKEY BOF report, the following question was asked: Nico Williams: If HAOKEY goes for a pseudo-EAP method do you need a new Working Group or would this work be done in EMU? Sam Hartman: EMU has a very strict charter and will NOT add any new items until it has at lease completed all of its current milestones. ------------------------------------------------------------------------ Why BGP and IPsec don't play well together in real networks Brian Weis http://www3.ietf.org/proceedings/06jul/slides/saag-2.pdf (Slide 1..2) Brian: There has been talk on transport security for BGP, and the question that comes up, very reasonably, is why not use IPsec. Based on a little investigation within my company (Cisco), some other routing vendors, and our customer base, segmented out things that are really implementation issues, and this is what is left, things to think about why operators don't want to use IPsec to protect their BGP sessions. There are operational problems related to rekeying and Denial of Service. (Slides 3..6) Brian: Routers want to use the FE-FE fast path as much as possible. They are frequently implemented with ASICs, although some use software at a high interrupt level. They must handle many OC-192 (10Ghz) ports. Control traffic is forwarded to a Control Element (CE). CEs may have hardware assist to processing queuing and to help against Denial of Service. A BGP router typically has ~1000 peers. Each peer is probably a unique administrative entity, sometimes a competitor. Steve Kent: Your example has 1000 peers, under what circumstances do you have this many peers? Internet exchanges? Brian: Yes. Steve: I don't know any Internet Exchange that would have a thousand members. Ron Bonica: More likely an ISP peering with its customers. Steve: So it is one ISP router peering with a thousand customers, each running BGP? Are there any concrete examples you could point to? Ron: Some. Michael Richardson: I was involved in one Internet Exchange, and more than half of the peers used I-BGP. Usually large Internet Exchanges have route servers that will connect to every box and other route servers, so I'm not sure if I believe a thousand, but I could believe hundreds. Steve: It would be nice to get clarification. I assume your focus here is security mechanisms for E-BGP, not I-BGP. Brian: There is another use case which looks similar but has a slightly different model. In MPLS, a router at a provider could talk to a thousand customer routers. That is a slightly different trust model, because there is a service provider who is arguably in charge. (Slide 8) Brian: Service providers see a lot of problem with rekeying. Rekeying is important. Sometimes people say that you do not need to rekey for BGP, but that is only if you have ingress filtering and pairwise trusted links to all peers, which is not usually the case. You need to rekey periodically, for security and also whenever there is staff turnover, to decrease insider risk. Rekeying is important for both session keys and authentication keys. Eric Rescorla: It is not important to rekey session keys, modern algorithms can support nearly an infinite amount of traffic with a single session key. It is crypto lore from 1975 that you can't support large amounts of traffic. Even with DES we are talking 2^32 blocks, with AES 2^64. For a MAC algorithm there is no problem at all, at least for HMAC, and for CMAC we are talking about 2^40 octets. Ridiculous amounts of data. The only rationale seems to be rekeying for staff turnover. (unknown): I've been running a router with 100 peers in an exchange; 50-60 of those peers use TCP-MD5. In two years I have yet to receive any requests to change keys. Michael: I agree with Eric on session rekeying, unless you go over 2^32 packets with ESP and have to rekey for replay protection. We have traditionally rekeyed every 8 hours or so, but we could make it much longer if this would be a real issue. The staff change argument, I hope they change their login passwords faster than they bother with this stuff, and I suspect that's as big as job as anything else. I guess your talking about changing the long-term authentication when staff changes. I'm skeptical that they would really ever do it in practice, even when they say so in their security policy. I am skeptical that is the real reason. Phillip Hallam-Baker: I am having difficulty in figuring what the threat model is here? There are trading boards where you can buy router passwords, and there are several thousands of them being traded. So, it seems to me that the dominant attack here is the password to the router, and if that goes out, rekeying does not matter. My skepticism to IPsec more fundamental, it is not that IPsec cannot be made to work, it just is completely inappropriate security model. You are thinking about asset protection. So, you want to think about accountability. Sam: Out of scope for this presentation. We are talking about how to solve transport security for BGP. Whether this is a problem we want to solve, can be discussed in open microphone part of the agenda. (Slide 9) Eric: This is just wrong. The piece of information you need is not the public key itself, but the validity of it. Store a digest of the public key (or the certificate); it consumes about the same amount of space as a password. Since you do not need pairwise keys, you store your own private/public key pair and the hashes of the peers' keys. When you exchange with them, they send you their certificate, you hash it and check. Brian: You are proposing that everyone is their own CA and ignores everything in the certificate except the public key and checking the fingerprint. Is that right? Eric: This is how SSH works. (...more about raw public keys...) Steve Bellovin: I agree with Eric, the need for PKI is vastly overstated. If I am giving you the key, you need to authenticate me. I do not need a PKI with capital letters; I just need to know this is the key that I gave you. There are lot of very simple ways to do the validation that don ot need a high priest in the robes certifying the root key at a key issuing ceremony. Brian: Yes, to avoid a PKI is one reason to use raw keys. Brian/Steve: (...more about raw public keys...) Brian: I am not sure if we currently have application support for those things, but it could be written, of course. Eric: The implementation consists of IKE implementation plus a table of hashes; this is not exactly crypto rocket science. And, here users are only handling hashes which are not sensitive. As a result, when someone leaves, you do not necessarily have to rekey your router. Paul Hoffman: Assuming a single common PKI is not realistic, but assuming 10-20 PKIs might be. These are peers that you are talking to anyway, so a big ISP could just issue certificates to others. Brian: None of the ISPs or router vendors see themselves in the business of being CA. Michael: Those 10-20 probably do not change much, so they could be in the firmware. In Internet Exchange, you have an organization that could do that work, authenticate the Internet Exchange members, and issue certificates. I have been in a number of IPsec bakeoffs and done interop testing with routers that do IPsec. I have not yet seen a large router vendor that made IPsec easy to use, except in Windows road warrior situations. Almost everything on this slide is not a protocol issue; it is not being able to ship the code to do these things right. That code was in the interops, but did not show up in releases. (...more about router implementations...) That is why you are getting frustration from your customers; you have made IPsec too hard to use. We had this discussion in the EasyCert BOF a couple of IETF meetings ago. (See http://www3.ietf.org/proceedings/04nov/) Nico Williams: You are not going to rekey your long-term RSA key anyway. People are not writing RSA private keys on PostIt notes, and they could be stored in a token. So, you really need to worry about changing router passwords, but not necessarily the keys used between the routers. Phillip: I thought I should speak in favor of a strong PKI. The whole point of key ceremonies is simplifying systems, because instead of bilateral relationships and N^2 connections, you have N connections. Yesterday we (VeriSign) announced we will host the PKI for WiMAX routers, so if these $50 WiMAX routers can have a full-fledged PKI in them, I am skeptical that you cannot afford to do this for $50,000 or $500,000 BGP routers, especially since there already are organizations, like Internet Exchanges, that could handle the PKI administration. Brian: My point was not that PKI cannot be made to work, it is that the business model does not work. (Slides 10..15) Brian: Pre-shared secret keys need some synchronization when you rekey. BGP Rekey requires coordination between two operational staffs, each with different schedules. There may be a period of days between key installation at each end. You cannot bring down a BGP session while the installed keys are inconsistent. This could violate one or more Service Level Agreements. In some cases, the service provider must report to regulators, and for a high bandwidth connection, down time represents a substantial waste of resources. So rekeying must be reliable. Today, we fo not have a way to rollover secret keys. Several drafts exist on this topic, but none apply to IPsec. Brian: By their position, BGP routers are available to Denial of Service attack. The fewer control plane protocols available to attack the better. IKE is another point of attack. BGP routers protect against receive queue saturation, bus or backplane saturation, and CPU saturation. This is primarily done by filters. IPsec ESP encapsulation defeats that. Sam: Thanks. I understand that there a lot of people who disagree with some of the technical points made. However, there are a couple of things to consider here. Brian is reporting his research to us, and I think all of us believe he is accurately reporting what he is hearing. If the technical points are not right, just speaking at the microphone here is not enough, it does not get us to a solution. We are not interested in technically correct security; at least in this situation, we are interested in security that gets deployed. That means you have to actually solve the operational issues, either by working with people and convincing them there are no operational issues, or by dealing with those operational issues. We can discuss more about the technical issues with Brian and on the SAAG mailing list to get agreement on what the actual technical reality, but then we have to work with people to actually deploy that reality. If we are not interested in engaging in that discussion, we will not get a deployable solution. Eric: I have talked with a lot of people in IETF and heard the same story, explained them that is wrong, and now I am hearing it again. With regard to one technical issue, filtering on the SPI, the issue seems to be what the actual current hardware can do, correct? Brian: It is certainly true it cannot filter on SPI today, but there is also a perception that it is not good enough. Eric: Why not? Brian: We should take that offline. Sam: Offline, but to the list, since all of us want to know the answer. The other thing to consider is that Brian has explicitly excluded many things that are implementation issues. That is good for this presentation, but when looking at the larger picture, we also need to think about implementation issues. (unknown): Speaking as an operator, I do not feel qualified to comment every technical detail claimed to be wrong, but I can tell you that trying to do IPsec on BGP router is way too complex, and the results are too unpredictable. Considering that we have TCP-MD5 which works pretty well, what would be better approach? To stick with TCP-MD5 and address its problems? Or fix the issues, either perceived or real, that exist with using IPsec? Brian: It is a common complaint that IPsec is too difficult to configure. I intentionally left that out as part of the implementation issues that could get fixed. The unreliability is interesting, I would like to hear more later on what you mean by that. As far as alternatives, I think we should not talk about those now. Michael: Is there some organization, conference, meeting, or test lab where I can contribute my energy to solving this problem? Where do I go? Who do I talk to? Do you have the contacts we could talk with and understand better issue? (...more about a trials...) Regarding configuration issues, maybe there just is not a good HOWTO document, and that is the problem. I for one would be happy to work on this. We could also talk about technical issues, maybe we could use IKE to key TCP-MD5 as an interim measure, then the ASIC can do rate-filtering at that level, then we can deal with how hard is it to configure IKE. Maybe BTNS is part of the solution too. Brian: Thanks for your interest, let's get together afterwards with some of the routing folks. Phillip: I really want to see a threat model here. If we do not have one, we end up with deploying cryptography, not security. What I have seen in this presentation is that we can stop someone from splicing a fiber-optic line and putting a device in the middle. That is not the thing that worries me most in the BGP routing area. What I am really worried about is professional Internet criminals who have control over those routers. (...making control decisions at router, or at another machine...) Unless we start by looking at what it takes to secure the routing layer, we are not going to end up with anything that has any value. It is not acceptable to just throw cryptography and IPsec at BGP because we have it on the table. Sam: The SIDR WG is chartered to work on securing routing updates. PCE and FORCES are examples of WGs looking at splitting up the functionality off-chassis. Brian: The RPSEC WG has done some of these analyses you want. Charlie Kaufman: It is clear that keying can be a performance problem, and a real pain in a number of ways. I am trying to understand what you are looking as alternative: manually keyed IPsec SAs, or TCP-MD5? Brian: The existing alternative is TCP-MD5 with manual keys. Some individual drafts discussed in the SIDR WG earlier this week propose a way forward. I was not comparing IPsec with those drafts. Rather, I am stating where we seem to be with IPsec today, as an explanation why people are looking at those other things. Charlie/Brian: (...about rekeying and key roll-over...) Charlie: Manual keying has to be more trouble-prone than anything automated. Paul Hoffman: Comment for Sam, when you said we cannot be looking at implementation issues right now... Sam: What I meant was that I understand why Brian did not cover implementation issues in this presentation. I think we must look at them when looking at this whole problem space. Paul: Correct, that is what I was about to say. For IPsec, the implementation issues are huge, and IPsec with X.509 certificates they are even bigger. Brian is reporting what he heard from the field, and some of the misinformation we heard was based on people trying things for a couple of days and failing completely and throwing their hands up. When they do that, they do not usually say "I could npt figure out the administrative interface", they pick some other aspect that is not necessarily true, like having to rekey too often. The administrative interfaces are so bad and inconsistent across routers that it is a non-starter for people use them in reliable fashion. Which does not mean it cannot be done at all, just that we can apply elbow grease in that location. Brian: I agree. I tried to leave out things that could be fixed by various vendors. Nico: I hate to beat the horse of rekeying again. (...more about rekeying...) So you do not want to be doing manual keying at all. Use public keys, store private keys in tokens, and automate as much as you can. ------------------------------------------------------------------------ The need for better security considerations guidance Dan Romascanu http://www3.ietf.org/proceedings/06jul/slides/saag-1.ppt (Slides 1..3) Dan: About 35% of DISCUSS positions in the IESG are security related. Many seem to be pretty fundamental, reflecting a gap in understanding of security requirements between protocol designers and security experts. They come late in the process. Also, there is lack of consistency among security advisors, especially when it comes to applying the latest standards which may be work in progress. The result is frustrating last-minute delays, lack of determinism, and the perception that security is Black Magic. Documents are either "secure and late" or "insecure." (Slide 4) Dan: What is the applicability of BCP 61 (RFC 3365)? Problem is that it is too high level. (Slide 5) Dan: What's wrong with BCP 72 (RFC 3552)? It provides guidelines for writing RFC text on security consideration. Many references are out of date in this RFC 3552. It has an over-emphasis on communications security. This is traditional, but misleading for most IETF protocols. For example RFC 4072 (Diameter EAP Application) mostly deals with threats arising from authenticated users, not communications threats. The part on writing security considerations parts is very thin. Not everything on security fits into a security considerations section. (Last Slide) Dan: Ideas for Improvement. Update RFC 3552, maybe a living web version. Try to catch things earlier, enforce mandatory security reviews prior to IESG Evaluation for new protocol documents. Increase determinism by better documenting security requirements, perhaps someting similar to RFC 4181 for MIB reviewers. Adapt security requirements to the scope of the protocol. Better educational materials. How and when do strong security considerations apply? Provide guidance on how to design security into protocols. Russ: The Security Directorate has been making improvements in early review. In particular, SecDir getting someone to look at every document during IETF Last Call. Granted, it is later than Dan is advocating, but it is much better than waiting for IESG evaluation. We are having the same reviewer make sure the issues raised during IETF Last Call have been resolved by the time the document reaches IESG Evaluation. We are getting better. We still have lots of room for improvement. We have a pool of about 40 people doing those reviews right now. Eric: Two comments. First, having early review is an important idea and I have been ranting about this for years. I am concerned about the direction I see you going, and I have seen the Security Area starting to go, and I am a contributor to that so I can say this... The notion that if we just produced enough reference materials, then the people designing the protocols would "get it" and design secure protocols... That is wrong. For starters, there's already quite a lot of reference material, and people do not read it. I routinely come across people who did not read RFC 3552 and do not know the things that are in it, simple stuff, not complicated. I have a long document about authentication mechanisms that I know people are not reading either. Number two, even people who have been designing security protocols for ten years still make mistakes. It is incredibly hard to design protocols that do not have security problems. The hope that you can spend two hours in classroom or read a 50 page document and then be able to design a protocol that is reasonably secure is not realistic. (...more about experts and requirements...) Security requires a way of thinking, not memorizing facts about security. I do not think any amount of education can produce a result where there is no need to for security guys to come in and complain that your new protocol is insecure. Sam: I completely agree with Eric, although training and education is important and useful. And, I'd like to put in a plea for "Use TLS." I think one thing we have learned is that for each of our security frameworks and mechanisms, we need a document describe how to use it properly. When you want to use TLS, IPsec, EAP, SASL, GSS-API, or whatever in your protocol, there are things that you need to specify in your protocol to make it work. We need to document the things that the protocol author needs to think about. I think we have concluded those documents are useful, even if they are not a panacea. Steve Bellovin: I am a former Security AD. We are trying. I owe Russ one of the guidelines document. I have commissioned some of them. We are trying. These documents are still much better we had before. If they are not sufficient, we need to hear it and improve them. That said, to some extent Eric is right. Security is partly a way of thinking that does not come naturally to normal human beings, as opposed to people in the "security mafia." We think that people are out to get us. (laughter) Right, they are, I know... One of the most frustrating things I have to deal with when doing security architecture, I say "what if Bob does this to Alice", the reaction is "why would Bob do that?" I think many people in this room have had the same experience. It is a way of thought, not a cookbook. There are things that are almost off-the- shelf: a finished "Use TLS" or "Use IPsec" document will say what things need to be included to use the securty protocol correctly, and also state the situations when the security protocol cannot be used correctly. But it is not always obvious, even people in this room, there are disagreements, so do not expect it to be perfect. Phillip Hallam-Baker: I think you can go a bit further to train people. If you look at the way the insurance industry teaches people to think about these things, or programmers look at requirements analysis, there are ways of structuring a document that makes it easier for a reviewer to see what is missing. When I look at a protocol, I want to see what are the resources that might have value to the attacker, and is that list complete; I can check that fairly easily. Second, what are the risks that are involved in those resources, what are the attacks that might manifest those risks, what are the controls that prevent the risks from being realized, and what is the residual that is not being analyzed. I recently put out a statement of work for analyzing a proposed protocol, and the statement of work that the consultant gave back essentially had those elements in. I think we could have a statement of that form that would not require people to change their thinking to read it and start providing information in a form that's useful. Sam: I bet you probably do not have time to put together something like that yourself, but... Phillip: I do not, but I have already put it together. I could pull it out from the archives. Russ: Please post it. Steve Kent: You used MIBs as an example where we have been able to provide appropriate guidance, I do not think that is an appropriate comparison. Just look at how much money is spent around the world each year on security consulting as opposed to MIB consulting. I think that is an indication of the relative perceived importance and complexity of the problem. However, your observation about that we need to deal with more than attacks against bits on the wire is very true, but that is largely going to be something that the writers of the protocols have to be able to articulate better, what is going on, for anyone to be able to do a meaningful analysis. For example, I would like to see for new protocols, and I have seen this happening, a document that articulates the perceived threat model for the environment where the standard is to be used. If you cannot tell me that, we have no idea what we should be protecting against. Then, I would like to see a security analysis, which is not a bottom-up thing. Do not simpley list all the things that can go wrong, because that always leaves me thinking what are all the other things that can go wrong that are not on the list. I want you to describe what you expect to be going right, for every aspect of the protocol. Then we can work out what you are relying on for this condition to be satisfied. And that is a basis for doing a more comprehensive security analysis, and hopefully providing appropriate countermeasures that go beyond protecting bits on the wire via IPsec or TLS. However, that mostly has to come from the people developing the protocols, because if they do not write documents like that, you are asking people who are security experts to become at least as knowledgeable about the protocols authors, and that is an unrealistic expectation. Dan: I used MIB guidelines as an example because it is very handy for me; it comes from my area of expertise. I acknowledge that security work is much more complex. There is one thing that is in common, the security expert needs to be explained what the technology is about, the threat model, what can go wrong and right, a similar thing happens to MIB or management reviewer who needs to understand the technology being managed. (...more about having dialogue in earlier phases...) Jeff Hutzelman: I agree with Eric. However, RFC 3552 does have some outdated parts and incompleteness. There certainly could be more work done. But, the main point is what I am hearing from Eric and Steve: security is not something where we can just throw a book at someone and say "follows these instructions", experts need to be involved. One other thing I heard Dan mention, which I have not heard much discussion about yet, is a need for us to give consistent advice, advice that is consistent with what the reviewers will say at the end of the process. (...more about consistency...) Even if a document like RFC 3552 is of limited use to people outside the Security Area, something along those lines is essential to people within the Security Area who are trying to help other people get it right. Eric: Steve already said what I wanted to say, but I will tell a story anyway. I spend an hour yesterday in a meeting with a bunch of SIP guys trying to figure out how to unscrew SIPS, which is SIP over TLS. I know a bit about TLS, and I have spent a lot of time with the SIP guys who understand SIP, and we still screwed it. And now we are trying to figure out how to unscrew it. We screwed it because they did not understand TLS well enough, and I did not understand SIP well enough. SIP is an extreme case, but I would like to plea protocol authors to write their documents so that they are a bit clearer to people who are trying to help them, then it would be a lot easier for us to help them. Wes Hardaker: We have a few issues about interrelationships within IETF. We are really good in arguing amongst ourselves and dragging arguments around the IETF. What has worried me about security lately is that we have been recommending something which is hard to use, and does not meet the operational needs of the user group. And they look at it, and say, "That does not marry well with what we are trying to do." Or the other possibility we have frequently used, we offer something to them which hacks into something we have done previously. We try to hack something into their protocol and environment which does not fit the architecture. That does not seem to bode well for simplicity; we keep loosing that battle. At the same time, others will often come up with suggestions like: "We can just run over IPsec or TLS," and then we have to explain to them why that does not quite work from a security standpoint. Could you use "this" instead, which is something they really do not want from some operational point of view. In the end, I do not think we are helping. I am not saying I have a solution to this situation, but we do have to think carefully about how others are going to make use of what we offer. Most of the time when they say they do not want IPsec or want TLS, it is because they have actually thought about it from operational point of view, just not from a security point of view. We need to do a better job of thinking about it from their point of view as well. In summary, to put it bluntly, I do not think we are helpful, I think what the rest of the Areas think of us as coming at the last minute, doing security review, and then they drag a whole bunch of security guys to the room and tie up their agenda with our arguments. You end up with all these people lining up behind the microphone to argue about security, and meanwhile they are still trying to work on their protocol issues, and we eat half of their time. I do not have the solution, but I keep thinking we are not making progress, and I am not really sure if we have all the tools we need. Russ: I have seen the design team approach be a little more successful. When you can get few people together, like Eric just described his one hour meeting. It is usually more productive to have these guys report to the Working Group what they learned, rather than having the discussion in a very large meeting. Wes: You are absolutely right. Getting security geeks involved with their stuff early, and getting the management folks involved early, and transport stuff early, really helps. Sam: I have one closing point. It is very easy to listen to these conversations, sort of arrogant response that only we can do security, we are going to tell you what is wrong with your protocol, and we cannot teach you. I agree that only security people can do security, but there is a way new security people get created, and that is by doing security. We cannot teach you with a book or class, we can start there, but ultimately you learn the security mindset by doing it. And we have actually seen a lot of it. For example, the SIP community is a great example where they are starting to get enough security clue to design their own security solutions. Obviously we are involved too, but there is a lot of very positive feedback. And you are starting to see that in certain other areas as well. That is how we are going to solve this problem. ----------------------------------------------------------------- Open Microphone There was no time left for open microphone discussion.