RE: Do ipsec vendors care about privacy?

["Jesse Alpert" <jalpert@CheckPoint.com>]

Hi,

My vote is yes - we care.

Our current implementation of legacy authentication which is based on
hybrid-mode (draft-ietf-ipsec-isakmp-hybrid-auth (now expired)) + XAUTH
protects the user's identity against active attacks. It would be
a pity to lose this feature in IKEv2.

It can be argued that since the regular (non-legacy) IKEv2 initial exchange
does not protect the initiator's ID from active attacks, and since this is
the recommended (?) mode of authentication, we should not go to the effort
of protecting the legacy authentication exchange. But it seems that the
identity of a user that is using legacy authentication (e.g. user name and
password) may be easier to exploit than the identity of a user using
a public signature.

Jesse

-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hugo Krawczyk
Sent: Wednesday, March 19, 2003 5:35 AM
To: IPsec WG
Subject: Do ipsec vendors care about privacy?


The catchy subject is mainly to grab the attention of ipsec vendors in this
list (but it also reflects the contents of this note).

The question that I want to resurrect is whether leaving the user's identity
open to active disclosure attacks as done now in the "legacy authentication"
solution of IKEv2 (described in section 2.16 of ikev2-05) is a reasonable
decision given that protecting against such attacks can be done at a
moderate
price (see explicit specification below). This decision seems especially
dubious given that the roaming/remote user scenario is the only case in
which
identity protection clearly makes sense, and constitutes a natural
requirement
for ipsec solutions in the legacy authentication world.

I raised this question some time ago (beginning of Feb) and its resolution
was mainly based on the fact that protecting the user's identity is a bit
more complex than not doing it. I remain unconvinced, however, that the WG
(in particular ipsec vendors) made here an informed decision on this
trade-off.
I got the feeling that no one was really paying attention. (The only
people to express opinions on this on the list were: Charlie who was
"genuinely conflicted about this one", Derrell Piper and I that supported
protecting the user's identity, and Marcus Leech who was against.)

So before we close the ikev2 specification please take a look at what it
takes
to change the legacy authentication protocol in ikev2 to protect the user's
identity from active attacks. Here are the two main candidate solutions:

(1) Simply defer the sending of the user's identity IDi from message
3 to message 5 (that is, after message 4 in which the responder
authenticates
itself).  The difficuty here is that the responder does not have IDi to base
its choice of EAP method in message 4. I do not know how much of a practical
problem this is (it was never pointed as such in the case of PIC in the
ipsra
wg), but others will know better.

p
(2) Let the responder authenticate itself already  in message 2.  This can
be achieved by moving the AUTH and IDr payloads from message 4 to message 2.
If we do not require encrypting these fields then the change is simple.
Adding encryption is possible but requires applying SK{} from the middle of
message 2 which is more complex. I suggest doing it simple, i.e. without
encryptioni (also integrity protection is not needed here). This leaves
the identity of R in the plain but this is ONLY for
the legacy authentication scenario in which protecting the responder
(server/gateway) identity is of little (or no) importance.

Either change requires minimal change to the current specification,
and none has major implementation complexity. They do not change at all the
main protocol, and are relevant only to implementations that support legacy
authentication (where user's privacy is a real issue).
It seems to me that in this case the "complexity vs security trade-off"
is easily resolved in favor of the user's identity protection.

What others think?
(If this time no one cares then we can easily forget about this issue; at
least this will help to document that this was a conscious decision of the
WG.)

Hugo

PS: I'd have liked to raise this in the meeting in San Francisco but I
couldn't make it. Hopefully there may still be some discussion on this
there,
or in the list in the nexy week.


Lacking clear support for either way, Charlie
decided to go with the simplest solution that is now in 05. This is
certainly the right way to go if people do not really care about this
privacy issue. In this case, however, I think that this decision needs
to be documented in Radia's "rationale" draft (since this issue will be, I
bet, something critiques of ikev2 will like to highlight).
However, , before doing so I'd like to really sense if this is a thoughtful
decision, or something that no one really cares about
This note is intended to explicitl;y raise this issue before the closure
of ikev2 specification. If people still support the current solution (or
just shut up) then we will have a clear documentation that this decision
reflects the WG view (if not strong consensus).


On the other hand, I can bet
that the future
papers criticizing IKEv2 (there will be such papers no matter what we do)

of the
type written about IKEv1) will critically point
to this issue. After all, they will say, a protocol that provides identity
protection  with me IF

>
> Hugo Krawczyk <hugo@ee.technion.ac.il>  wrote:
> > The one thing that I definitely dislike in the appended proposal is
that
> > it opens IDi (sent in message 3) to active attacks.  If there is one
> > application where identity protection really makes sense is in hiding
> > identities and locations of mobile users, which will be among the main
> > users of SLA. I suggest to make IDi optional in message 3, and make it
> > clear that implementations should NOT assume that this IDi value is
> > available, certainly not in a way that compromises the user's
identity.
>
> I am genuinely conflicted about this one - like the donkey between the
> two bales of hay. I see equally good arguments on both sides, and I


This WG has a long tradition of making decisions that become controversial
later (see the paper by Kaufman and Perlman, ,Ferguson and Scneier, etc).