From: karthikbalaguru on
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
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
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
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
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.