From: karthikbalaguru on 20 Dec 2009 00:43 Hi, ESP supports both 'encryption only' and 'authentication only' configurations. Interestingly, the the usage of encryption without authentication is strongly discouraged. So, why should ESP provide the support for 'encryption only' configuration ? Any specific reasons for that configuration ? Any ideas ? Thx in advans, Karthik Balaguru
From: Nico Kadel-Garcia on 20 Dec 2009 01:52 On Dec 20, 12:43 am, karthikbalaguru <karthikbalagur...(a)gmail.com> wrote: > Hi, > ESP supports both 'encryption only' and 'authentication only' > configurations. Interestingly, the the usage of encryption without > authentication is strongly discouraged. So, why should ESP > provide the support for 'encryption only' configuration ? Any > specific reasons for that configuration ? Any ideas ? > > Thx in advans, > Karthik Balaguru What's the point of encryption if someone else can play man in the middle, invent what are effectively your credentials, and tap your session without your knowledge?
From: David Schwartz on 20 Dec 2009 15:12 On Dec 19, 9:43 pm, karthikbalaguru <karthikbalagur...(a)gmail.com> wrote: > ESP supports both 'encryption only' and 'authentication only' > configurations. Interestingly, the the usage of encryption without > authentication is strongly discouraged. So, why should ESP > provide the support for 'encryption only' configuration ? Any > specific reasons for that configuration ? Any ideas ? The theory is that encryption only is better than nothing at all because it will prevent all passive attacks. In some cases, if you offer people the choice of either nothing or encryption without authentication, they'll choose encryption without authentication because in some circumstances, authentication is not considered worth the trouble. It is also a fairly effective protection against bulk interception. Right now, your ISP could sniff the vast majority of your traffic if they had a mind to. They are, however, very unlikely to use active attacks. DS
From: C. on 22 Dec 2009 07:22 On Dec 20, 6:52 am, Nico Kadel-Garcia <nka...(a)gmail.com> wrote: > On Dec 20, 12:43 am, karthikbalaguru <karthikbalagur...(a)gmail.com> > wrote: > > > Hi, > > ESP supports both 'encryption only' and 'authentication only' > > configurations. Interestingly, the the usage of encryption without > > authentication is strongly discouraged. So, why should ESP > > provide the support for 'encryption only' configuration ? Any > > specific reasons for that configuration ? Any ideas ? > > > Thx in advans, > > Karthik Balaguru > > What's the point of encryption if someone else can play man in the > middle, invent what are effectively your credentials, and tap your > session without your knowledge? What's the point of replying when you don't know what you are talking about. (The only context in which the original post would seem to make any sense is with reference to Encapsulated Security Payload - part of the IPSEC protocol. Assuming that is the case....) It does not follow that there is no implicit authentication just because ESP is set to encryption only - this is only the case with certain modes of key-exchange - and even then end-point authentication may not be a requirement of the application. And it's the only way to move data between nodes where there is address translation in between. C.
From: Nico Kadel-Garcia on 22 Dec 2009 18:18 On Dec 22, 7:22 am, "C." <colin.mckin...(a)gmail.com> wrote: > On Dec 20, 6:52 am, Nico Kadel-Garcia <nka...(a)gmail.com> wrote: > > > > > On Dec 20, 12:43 am, karthikbalaguru <karthikbalagur...(a)gmail.com> > > wrote: > > > > Hi, > > > ESP supports both 'encryption only' and 'authentication only' > > > configurations. Interestingly, the the usage of encryption without > > > authentication is strongly discouraged. So, why should ESP > > > provide the support for 'encryption only' configuration ? Any > > > specific reasons for that configuration ? Any ideas ? > > > > Thx in advans, > > > Karthik Balaguru > > > What's the point of encryption if someone else can play man in the > > middle, invent what are effectively your credentials, and tap your > > session without your knowledge? > > What's the point of replying when you don't know what you are talking > about. I was actually asking a question. > (The only context in which the original post would seem to make any > sense is with reference to Encapsulated Security Payload - part of the > IPSEC protocol. Assuming that is the case....) That's an interesting supposition, and seems quite reasonable. However, and this is a very important however in security terms, I've learned the very, very hard way: do not assume that a casual question without details is actually part of a sensibly built framework. For example, there are numerous circumstances where end-to-end encryption existence is enabled but the authentication is basically ignored. This is a constant issue of SSL keys in the modern world, where many people never bother to purchase signatures for their keys and thus, users have come to casually accept whatever key a site happens to publish as permanently accepted, and ignore warnings about expired keys. I've been seeing this for many years in the Linux world, for casually set up websites and especially for Subversion repositories where the managers cannot be bothered with the task of registering a key. The result is that any man-in-the-middle can intercept the traffic: *ALL* of it, and monitor that traffic on its way to the actual target. The data is, in fact, encrypted along most of its path. But the authentication is nonexistent. Similar issues occur with SSH servers: people are casual about accepting new public SSH server keys, or even publish the same keys across every server in an imaged OS deployment configuration, such as Xen or VMWare snapshots. Voila! You, as a client, cannot verify which server you are actually speaking to. This is also why it's helpful for newly installed secure services, such as SSH and HTTPS, to generate new keys the first time they're run. (This can actually cause boot problems if your source of randomness is insufficient, though.) > It does not follow that there is no implicit authentication just > because ESP is set to encryption only - this is only the case with > certain modes of key-exchange - and even then end-point authentication > may not be a requirement of the application. And it's the only way to > move data between nodes where there is address translation in between. > > C. And this is interesting, thank you. Can you now see that perhaps this is *not* what the original questioner asked about, and that we should find out? And a hint: if you're going to say someone doesn't know what they're talking about, you might check out their history first. My first network security work predates the Morris Worm. It doesn't mean I'm right, but it does mean I've seen some things you might not have thought of, as in the cases above.
|
Pages: 1 Prev: Virtual IP setup Problem Next: ip rule with fwmark not working in 2.6.31? |