And so I reply to myself but got curious and wanted evidence. I found first references of AH/ESP and NULL in 1996 June IPsec archives. http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html
And while some interesting tidbits, the joggle for my memory banks was that there was a bunch of discussion on where AH would be used with ESP and whether ESP only would also be relevant. And while I couldn't find exact reference to the March 1998 interop testing in North Carolina that showed issues with AH not traversing NATs I am fairly certain that was the case and why in practice people starting using ESP-Null. (it wasn't in the notes for the follow-up IETF IPsec meeting). Someone else from that time may also be able to chime in. - merike On Dec 8, 2013, at 8:19 PM, Merike Kaeo <[email protected]> wrote: > Apologies in advance for top-posting. I keep meaning to get caught up on > this mailing list but never quite manage it. However, the IPsec NULL is > something that I see so misrepresented everywhere that I wanted to chime in. > It was to the best of my recollection developed after the 1998 bake-off in > Cary North Carolina (I was there) to enable integrity protection thru NAT's. > AH had issues transversing NAT devices which if some others of you were > around will remember was a technology that was just taking off at that time. > It was felt that using the NULL encryption gave you at least integrity > protection for the data even though it did not protect the IP addresses (or > anything else that was part of the IP header that wasn't morphed in transit). > However, for anyone who is very well versed with IPsec, you will note that > if a SPD requires IP src and dst address as well as SPI, then the IP > addresses are implicitly protected. Note that the NAT traversal protocol had > its beginnings from that 1998 event as well. > > Also please remember that at the time IPsec was being developed there were > still global import/export restrictions relating to cryptographic protection. > Not just in the US mind you….I have a table in a book I wrote in 1999 that > actually listed a bunch of countries and the restrictions at that time. > There typically wasn't a restriction on key length for cryptographically > protected integrity protocols but there was one for cryptographically > protected confidentiality (i.e. encryption) protocols. In the US it was 40 > bit restriction on encryption. I believe for some *limited* subset of > countries this is still true for US export controls on cryptography today. > > Anyhow…just to get some of the history straight. And I speak as someone who > was at cisco at the time and did a lot of performance and interoperability > testing….and sat in the back of the room at *all* of the IPsec meetings since > the original BoF back in 1993/4 and discussed issues in background (I don't > write code….but can find bugs :)). And as someone who spent well over a > decade trying to get vendors and users to understand issues of IPsec > implementations and usability in a v6 world [while an independent > consultant]. I gave up 4 years ago. > > And FWIW, for IPsec the primary deployment issues are in implementation > terminology and interoperable defaults. I will gladly argue that point over > beers anytime. > > - merike > > > On Dec 8, 2013, at 5:52 PM, Phillip Hallam-Baker <[email protected]> wrote: > >> On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig >> <[email protected]> wrote: >> Hi Stephen, Hi Nicholas, >> >> it would be interesting (as a history lesson) if someone could tell us why >> the group at that time decided to develop a NULL encryption mechanism. >> Stephen Kent (co-author of RFC 2410) might remember. I have no heard >> >> It was for testing and it all happened long before any of the evidence of >> the NSA peddling bongoed crypto suggests that it was going on. I think it >> highly unlikely that anything of the sort was going on before 9/11 and my >> sources claim that the change came much later, if it happened at all. >> >> I really don't think that any of the people involved in IETF process have >> had a hand in knowingly peddling bongoed crypto either. But as I have been >> making plain in another forum, the slides openly bragging about such an >> operation have had a serious cost in terms of erosion of trust. >> >> I think any interference would have been 'action at a distance'. Rather than >> come here and make the case for protecting some hole that was going to be >> used to propagate Flame, I would expect the NSA people running the DoD CA >> would call up their contacts in IETF space and make up some story about >> their operational difficulties caused by still running the old Netscape CA >> that hasn't been maintained for a decade now or some such hokum. >> >> I can't see how that sort of cover story would work for peddling a NULL >> cipher. There are some vulnerabilities I think can be laid at their door but >> not that one. We did that one to ourselves. >> >> >> IPSEC is sufficiently complicated that interop is a non trivial problem. Or >> at least the people who implemented it found it to be so. Some people tried >> to make the same suggestion for S/MIME (and people might remember my >> reaction). Having a NULL cipher for interop testing was not an unfounded >> proposal but it was certainly never one I supported. >> >> Remember that IPSEC has always supported an 'authentication only' mode. So >> turning on encryption with a null cipher was not an obvious difference. In >> fact it would probably have made sense to have killed the integrity only >> option at the start and just had a null cipher. >> >> >> Perhaps we should write a draft and move it to HISTORIC, just to avoid any >> confusion. >> >> >> In context of our discussion on this list the answer will give us a lot of >> guidance for the future. Even 2 years ago I had lots of people arguing in >> the OAuth working group that authentication and integrity protection is >> sufficient and that we do not need confidentiality protection. So, I >> wouldn't be surprised if the same argument showed up 10 years earlier. >> >> That is a different argument and maybe there is a case to be made for >> relying on HTTPS. I don't like that approach, in fact I super-encrypt within >> HTTPS quite often and always super-authenticate end to end in my Web >> Services. >> >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
