RE: Do ipsec vendors care about privacy?

["William Dixon" <wdixon@windows.microsoft.com>]

Hugo, as an IPsec vendor (but not necessarily an implementer of IKEv2)
our customer input is that they are very concerned about exposing
identity to passive or active attack.  Thus we envision IPsec enabled
host responders that are:
A. public servers that can provide their credential first to an incoming
client (typical server auth)
B. private servers or your laptop that must not provide it's credential
first until the incoming client authenticates.

I regret I haven't reviewed the current IKEv2 draft with these two cases
in mind, or kept up with the discussion to see if these two scenarios
are adequately enabled, with or without legacy auth.  Thus I can't offer
comment about your proposed solution.  I just haven't been able to get
the time to review this stuff in detail, and likewise, I'm not in SF.
Nevertheless, I offer a strong yes "we care" for what it's worth.  We
see the above two scenarios as required for deployment of IPsec to
secure application connections host-to-host.

-----Original Message-----
From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] 
Sent: Tuesday, March 18, 2003 7:35 PM
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).