Subject: Do ipsec vendors care about privacy?

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 19 Mar 2003 05:34:43 +0200 (IST)

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 <[email-masked]>  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).

---

From: Antonio Forzieri <[email-masked]>
Date: Wed, 19 Mar 2003 12:40:40 +0100

[SNIP]
I think that vendors *care* about privacy... Or at least they should. :-).

The solutions you proposed solves the problem of protecting the 
iniziator ID from attive attck, however they let the responder ID opend 
to passive attack.

> wg), but others will know better.
I think that this is the simplest solution of the two. Initiator, when 
it is going to use "legacy autentication", does not have to send IDi to 
the responder. This is not a difficulty for the responder (I think). 
When Bob doesn't receive IDi and AUTH payload in message 3 will 
understand that Alice is going to use a legacy authentication method, 
and he send an EAP(Request, Identity) in message 4. Alice can send her 
IDi in EAP(Response, Identity) in message 5. This change in IKEv2 will 
make handshake 1RTT longer, however I think this isn't a great problem 
when we are interactin with a human.

      Initiator(Alice)                   Responder(Bob)
       -----------                        -----------
        HDR, SAi1, KEi, Ni         -->

                                   <--    HDR, SAr1, KEr, Nr, [CERTREQ]

        HDR, SK {[CERTREQ,] [IDr,]
                 SAi2, TSi, TSr}   -->

                                   <--    HDR, SK {IDr, [CERT,] AUTH,
                                                 EAP(Request, Identity)}
        HDR, SK {EAP(Reply, IDi)}  -->

				  <--    HDR, SK{EAP}
				
        HDR, SK {EAP, [AUTH] }     -->

                                   <--    HDR, SK {EAP, [AUTH],
                                                   SAr2, TSi, TSr }

Of course this proposal let IDr opened to polling attack. But which 
identity we have to protect? In a message from Radia Perlman:

"...However, when writing IKEv2, we decided that there was
more of a problem with a "polling attack", where someone
could find out who was listening at a particular IP address just
by initiating a connection to it. The WG, when faced with
the two styles, seemed to have consensus around avoiding the
polling attack. The reasoning was that IKE is a peer-to-peer protocol 
where either side can initiate, and the polling attack is way easier 
(just initiate a connection to an IP address) than impersonating the
responder's IP address and seeing who connects..."

So again: "How important is identity protection? and which ID we *MUST* 
protect?"

> (server/gateway) identity is of little (or no) importance.
This solution allow us to save the extra RTT, however it implies that 
Bob knows when the Alice is going to use EAP. (Your proposal is to 
change IKev2 *only* when using "legacy authentication", right?)

[SNIP]
> Hugo
  Am I missing something?

[SNIP]

-- 
------------------------------------------------
Antonio Forzieri
CEFRIEL - Politecnico di Milano
Tesista Area E-Service Tecnologies
Tel: 02-23954.334 - email: [email-masked]
ICQ# 177683894
------------------------------------------------

---

From: "Yoav Nir" <[email-masked]>
Date: Wed, 19 Mar 2003 14:34:45 +0200

That's way too many RTTs.  I think an extra RTT is a greater problem when
interacting with a human, because humans are more impatient than machines.
It has been generally accepted here that since we already know the
Initiator's ID at message 4, we can skip the EAP Identity and go directly to
the EAP challenge.

Even with Hugo's proposed change, we can send the challenge in message 4,
receive in message 5 both the IDi and the EAP response, and verify them
then.  That way we still have only 3 roundtrips altogether.

Yoav

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Antonio Forzieri
Sent: Wednesday, March 19, 2003 1:41 PM
To: IPsec WG
Subject: Re: Do ipsec vendors care about privacy?

[SNIP]

				  <--    HDR, SK{EAP}

[snip]

---

From: Antonio Forzieri <[email-masked]>
Date: Wed, 19 Mar 2003 14:55:08 +0100

> interacting with a human, because humans are more impatient than machines.
I disagree with you.

However if we can do it with less RTT, let's do with less RTT! :-)

If I've not misunderstood, Hugo's proposal should work like this (right?):

Initiator                          Responder
-----------                        -----------
HDR, SAi1, KEi, Ni         -->
                                            EAP }
HDR, SK {IDi, EAP, [AUTH]} -->

This sounds fine for me. In such a scenario (legacy authentication) we 
open IDr to passive attack, however I think that here we have to protect 
Initiator Identity rather than IDr...

In the previous message I wrote something incorrect.
When we are using EAP we open IKEv2 to passive attack on IDr, but this 
doesn't happen because of Hugo's proposals. Even in IKEv2-05 we have the 
same problem.
If Eve uses a spoofed IDi and doesn't put AUTH payload in message 3 (she 
wants to use legacy  authentication,) she can mount a polling attack. 
(because only in message 4 that she proves her Identity)

[SNIP]

---

From: "Jesse Alpert" <[email-masked]>
Date: Wed, 19 Mar 2003 16:07:18 +0200

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Hugo Krawczyk
Sent: Wednesday, March 19, 2003 5:35 AM
To: IPsec WG
Subject: Do ipsec vendors care about privacy?

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.

(in particular ipsec vendors) made here an informed decision on this
trade-off.

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

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.

of the

that
identity.