Re: 10 years and no ubiquitous security
At 10:18 AM 3/18/2002 -0600, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], William Allen Simpson writes: The Purple Streak (Hilarie Orman) wrote: ... But Bill, I'm trying to understand what your point is. We can't force people to use security. IPsec is standard in most major business operating systems (Win2K, Solaris, *BSD, etc.) and available for for Linux. There are hardware solutions -- I have a small IPsec box with me in Minneapolis. But except for VPN scenarios, most people choose not to use it. I think there's a lesson there, but I fail to see how Steve Kent or any of the other players in the history of IPsec are at all at fault. At last call call several years ago I detailed my misgivings about the design. However since so many talented people had already put years of work into it I also wrote that the market must decide its fate. It seems to have decided, IPsec has settled into a fairly modest VPN market niche ($200M/yr revenues or so?). It is not turned on by (or not available on) at least 99% of the Internet hosts. I guess the $64 question is whither do we go now with IPsec? 1. Do we do significant surgery on it and muddle on? 2. Do we stop working on it and start over with a fresh design? (Besides VPN what other pressing problem needs a solution?) 3. Do we give up? (Or at least be satisfied with a VPN only solution.) I'm a little amazed that IPsec has had as much success as it has had to date. I've seen so many other secure IETF protocols die much more quickly; SNMPSEC, PEM, SHTTP, etc. - Alex -- Alex Alten [EMAIL PROTECTED]
Re: 10 years and no ubiquitous security
In message [EMAIL PROTECTED], William Allen Simpson writes: The Purple Streak (Hilarie Orman) wrote: Mild-mannered S. Kent is in reality SuperNoSecMan. He adds the essential anti-replay counter to IPsec protocols and, ... causes people to NOT adopt them? Actually, of course, Steve Kent did not add the counter. It was in swIPe, from the beginning. It was in my drafts, from the beginning. It was certain members of the WG who insisted we didn't need the counter. At least one has admitted he was wrong. Are you ever going to admit you were? Anyway, when we published the first set of RFCs, I carefully documented the need for a Replay Protection sequence number in 1995: Internet Security Transform Enhancements Right. The only copy I could find was from 1996, but I don't think that that difference is important. (http://www.watersprings.org/pub/id/draft-simpson-ipsec-enhancement-00.txt) The problem with it -- and the reason I had objected to sequence numbers -- is that it never justified *why* they were necessary, beyond rather minor DoS prevention. It simply said replay protection provides cryptographically secure at-most-once datagram delivery. But there was no analysis of why one would want that. The same is true of the swIPe paper and I-D -- there was no analysis beyond saying replay protection. When attacks on confidentiality were developed that exploited the lack of replay prevention, I changed my mind and strongly supported sequence numbers. The difference is that there was then a reason. For what it's worth, Kent applauded the restoration of the counter -- he knew it was necessary. But Bill, I'm trying to understand what your point is. We can't force people to use security. IPsec is standard in most major business operating systems (Win2K, Solaris, *BSD, etc.) and available for for Linux. There are hardware solutions -- I have a small IPsec box with me in Minneapolis. But except for VPN scenarios, most people choose not to use it. I think there's a lesson there, but I fail to see how Steve Kent or any of the other players in the history of IPsec are at all at fault. --Steve Bellovin, http://www.research.att.com/~smb Full text of Firewalls book now at http://www.wilyhacker.com
Re: 10 years and no ubiquitous security
At 03:49 PM 3/13/2002, William Allen Simpson wrote: 10 years ago tomorrow, Brian Lloyd and I had a rubber hose lunch meeting with Steve Kent, who as a member of the IAB had refused to allow the PPP WG to publish CHAP in our RFC as an official authentication protocol. (He had previously mandated that we remove all security protocol negotiation.) He backed down, but we had to change the name from cryptographic to challenge. Well, I am not sure it was a rubber hose lunch although I do remember being annoyed. As I recall Steve pointed out that CHAP was not strong by cryptographic authentication standards and he did not want to attach a seal-of-approval on that basis. As I recall, I argued that the alternative then in use was clear-text passwords and asked if he felt that CHAP was superior to that. He did and agreed to sign-off on CHAP on that basis. I understood that he wanted good cryptographic authentication but we finally agreed that anything better than passwords was a good thing to have. I am not entirely sure that I would blame the failure to adopt a coherent set of security standards entirely on Steve Kent. Brian Lloyd [EMAIL PROTECTED] +1.530.676.1113 - voice +1.360.838.9669 - fax
Re: 10 years and no ubiquitous security
On Saturday, March 16, 2002, at 08:01 , William Allen Simpson wrote: ... I didn't happen to be at that ad-hoc meeting in San Diego, so I wasn't influenced by it No, but you were at the meetings where swIPe was demonstrated -- ACTUALLY DEMONSTRATED -- and where the the packet headers were discussed. And you also acknowledge the proposed swIPe security protocol! So, it would seem your message is rather disingenuous. We had ESP up and running MUCH MUCH earlier than you seem to think. And the swIPe documents describe something with visible differences from the ESP that resulted in RFC-1827. Your atttempt to rewrite history is noted, but neither appreciated nor accurate. Ran [EMAIL PROTECTED]
Re: 10 years and no ubiquitous security
But Bill, I'm trying to understand what your point is. We can't force people to use security. IPsec is standard in most major business operating systems (Win2K, Solaris, *BSD, etc.) and available for for Linux. There are hardware solutions -- I have a small IPsec box with me in Minneapolis. But except for VPN scenarios, most people choose not to use it. I think there's a lesson there, but I fail to see how Steve Kent or any of the other players in the history of IPsec are at all at fault. --Steve Bellovin, http://www.research.att.com/~smb I would like to comment on the other issue in this paragraph, about why IPSEC deployment might lack vigour. I set up VPN over IPSEC on a national academic network with 40mbit backbone and 10/100 mbit site linkspeeds. the best end-to-end performance I could get was 2mbit rising to 3-4 burst, and I was flooded by fragmented IP. Stuff like pMTU end-to-end is absolutely vital to make non-aware clients and servers cope with encapsulated protocols. I have also played with the client side code, and found that UDP protocols like Windows SMB do not work well on noisy/long-delay links. THis repeats the experience of encapsulated LAT some of us ex-DECheads remember: you can't fix bad protocol experiences by wrapping them in better protocols if the end-to-end behaviour depends on the badness (eg timer dependencies) Please don't get me wrong: I use IPSEC, I like IPSEC, but I have to recognize that off the beaten track, or for some (very useful) contexts it turns out not to work as well as we'd like, for reasons probably not to do with IPSEC per se, but the general state of the network. When you factor in that most of the 'simple' things can be done equally well in SSH, or by less clued people using non-secured tunnels, it gets harder to do a sell on IPSEC. which is a shame, because I really like IP layer abstracted methods, and the idea of generic infrastructure rather than applications-level point solutions. cheers -George -- George Michaelson | APNIC Email: [EMAIL PROTECTED]| PO Box 2131 Milton QLD 4064 Phone: +61 7 3858 3100 | Australia Fax: +61 7 3858 3199 | http://www.apnic.net
Re: 10 years and no ubiquitous security
RJ Atkinson wrote: On Saturday, March 16, 2002, at 08:01 , William Allen Simpson wrote: ... I didn't happen to be at that ad-hoc meeting in San Diego, so I wasn't influenced by it No, but you were at the meetings where swIPe was demonstrated -- ACTUALLY DEMONSTRATED -- and where the the packet headers were discussed. We had ESP up and running MUCH MUCH earlier than you seem to think. Ran, you are listed in the proceedings of July 1992 as having attended the IPSec BOF. Did you have an SP3 implementation at that time? If so, why didn't you demonstrate it? And the swIPe documents describe something with visible differences from the ESP that resulted in RFC-1827. The ESP in RFC-1827 has one and only one field: +-+++-+ | Security Association Identifier (SPI), 32 bits | +=+++=+ (A field that *I* named, Security Parameters Index (SPI), which *you* mis-typed, for the record!) That, amazingly enough, bears no resemblence to what-so-ever to SP3, but is exactly what was implemented for the version of swIPe that I was using. And you also acknowledge the proposed swIPe security protocol! So, it would seem your message is rather disingenuous. Your atttempt to rewrite history is noted, but neither appreciated nor accurate. You cannot even keep your lies straight when the documents are readily available on-line. Your acknowlegments read: Many of the concepts here are derived from or were influenced by the US Government's SP3 security protocol specification, the ISO/IEC's NLSP specification, or from the proposed swIPe security protocol Ran, you are a disgrace to the profession. I refuse to comment further on your posts. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: 10 years and no ubiquitous security
Steven M. Bellovin wrote: In message [EMAIL PROTECTED], William Allen Simpson writes: Right. The only copy I could find was from 1996, but I don't think that that difference is important. (http://www.watersprings.org/pub/id/draft-simpson-ipsec-enhancement-00.txt) Remember, the WG chair objected to my drafts being draft-ietf-ipsec-, and so they were reissued in 1996 as draft-simpson-, restarting at -00. To the middle of your message, why is it a problem that we were so brilliant that we prevented a threat before somebody else documented the attack? We are engineers, not cryptanalysts. It seemed obvious. Anyway, _you_ had the integrity to admit you were wrong. Thanks! (I just wasn't sure I should mention your name in a negative context.) ... But except for VPN scenarios, most people choose not to use it. I think there's a lesson there, but I fail to see how Steve Kent or any of the other players in the history of IPsec are at all at fault. Because the so-called standard is hard to understand, hard to implement, hard to install, and hard to use -- and now verified to have security failures, some of which I documented at least 6 years ago. Other than that? As you may remember, Photuris was designed to start itself automatically, without significant user intervention. (Somebody else just noticed the ICMP Security Failures messages.) Another of the things I used to do: have an Operational Considerations section in my drafts. Anything with a lot of configuration and dependencies has too many points of failure. But I'm so disgusted with Ran denying that other people did any work, or that he knew about it, that I'm hoping the thread will end. Surely, the secretariate mistyped that string in 1992 (on page 363). Oh well, it's not the first time I've caught him in a lie The point was made: we've been delayed and obfuscated into oblivion. The WG has been spinning its wheels for a decade. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: 10 years and no ubiquitous security
I set up VPN over IPSEC on a national academic network with 40mbit backbone and 10/100 mbit site linkspeeds. the best end-to-end performance I could get was 2mbit rising to 3-4 burst, and I was flooded by fragmented IP. You should try (again?) a more modern implementation. Stuff like pMTU end-to-end is absolutely vital to make non-aware clients and servers cope with encapsulated protocols. Agreed. Many of us _do_ understand these issues. Dan
Re: 10 years and no ubiquitous security
William Allen Simpson [EMAIL PROTECTED] said: It was certain members of the WG who insisted we didn't need the counter. At least one has admitted he was wrong. Are you ever going to admit you were? I didn't realize that a call for admission had been previously issued. Sure, I was wrong. It was a surprise to me that protocols are not monotonic wrt non-security requirements when security is layered onto them. Hilarie
Re: 10 years and no ubiquitous security
The IETF falls into comicbook mode as April 1 approaches. Mild-mannered S. Kent is in reality SuperNoSecMan. He adds the essential anti-replay counter to IPsec protocols and, ... causes people to NOT adopt them? He is a superb document editor and reviewer, and this makes security worse? He has demonstrated years of dedication to the IETF security area, develops BGP security methods, and this is only fuel to fire of his evil? He has such power over time and space that he alone creates security vacuums, causing 30 years of computer and network security research and development to be abandoned (except for this one tiny corner he inexplicably missed in SSL). There's not a single other relevant factor in this whole story, only SuperNoSecMan and his long shadow. But for the fact that Bill Simpson fancies himself a piece of kryptonite, Kent would reign supreme. Next week: Kent reverses HMAC by causing the earth to rotate backwards. Hilarie
Re: 10 years and no ubiquitous security
RJ Atkinson wrote: On Wednesday, March 13, 2002, at 06:49 , William Allen Simpson wrote: 10 years ago on Tuesday, Phil Karn sprawled out across my hotel room bed and drew the packet header that became ESP. Actually, that packet header wasn't directly related to ESP, though there aren't but so many ways a security encapsulation can be framed. I don't know why you want to denigrate the efforts of long-time IETF participants such as Phil Karn, JI, Perry Metzger and myself, but I just took a bit of time to review the WG meeting minutes. ... The SP3 spec, published by NIST more than 10 years ago, was the direct predecessor to ESP. Paul Lambert (an early co-chair) was a big proponent of SP3. Even when we thought we had rough consensus, Paul would present SP3 yet again! We rejected it every time (at least 3 times). We finally put the matter to rest at Toronto, where the minutes record: The problems with SP3 include a difficult to read specification, unnecessary fields in the clear header (very minor problem), and closely tied to ISO TP (makes support of TCP and other Internet protocol [sic] slightly harder.) Few of these implementations interoperate (a feature?) You should understand, when the WG is making comments like failure to interoperate is a feature, that means wow, what a * protocol. (substitute your favorite explicative.) Even Rob Glenn of NIST wasn't advocating SP3! This was noted in RFC-1827, I believe. We don't usually quibble with your acknowledgments section, or what you felt influenced you. ... I didn't happen to be at that ad-hoc meeting in San Diego, so I wasn't influenced by it No, but you were at the meetings where swIPe was demonstrated -- ACTUALLY DEMONSTRATED -- and where the the packet headers were discussed. And you also acknowledge the proposed swIPe security protocol! So, it would seem your message is rather disingenuous. and I'm the one who wrote the ESP spec in the early 90s, initially inside the IPng WG as an individual contribution. I believe I have a copy of that early draft. It would be hard to tell whether it is based on SP3, as it is remarkably devoid of packet formats. But SP3 is not mentioned. Anyway, as recorded in the minutes, I'm the one who wrote the early requirements draft for the packet header (circa 1993), and I can testify SP3 **wasn't** an influence I'll note that Steve Deering's viewgraphs for Amsterdam (July 1993) specify that SIP Security will be based on recent IPSec work. Those same viewgraphs document that I already had an implementation, in a KA9Q base -- that would be with Karn's swIPe implementation. Were you there? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: 10 years and no ubiquitous security
The Purple Streak (Hilarie Orman) wrote: Mild-mannered S. Kent is in reality SuperNoSecMan. He adds the essential anti-replay counter to IPsec protocols and, ... causes people to NOT adopt them? Actually, of course, Steve Kent did not add the counter. It was in swIPe, from the beginning. It was in my drafts, from the beginning. It was certain members of the WG who insisted we didn't need the counter. At least one has admitted he was wrong. Are you ever going to admit you were? Anyway, when we published the first set of RFCs, I carefully documented the need for a Replay Protection sequence number in 1995: Internet Security Transform Enhancements This was in the old IETF tradition of posting minority positions when the main WG disagrees. Perhaps you missed reading it? -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: 10 years and no ubiquitous security
On Wednesday, March 13, 2002, at 06:49 , William Allen Simpson wrote: 10 years ago on Tuesday, Phil Karn sprawled out across my hotel room bed and drew the packet header that became ESP. Actually, that packet header wasn't directly related to ESP, though there aren't but so many ways a security encapsulation can be framed. The SP3 spec, published by NIST more than 10 years ago, was the direct predecessor to ESP. This was noted in RFC-1827, I believe. Credit is due to the (mostly DoD sponsored) group that came up with SP3 long ago. I didn't happen to be at that ad-hoc meeting in San Diego, so I wasn't influenced by it -- and I'm the one who wrote the ESP spec in the early 90s, initially inside the IPng WG as an individual contribution. I decline to comment on the other portions of your posting. Ran [EMAIL PROTECTED]
