Subject: RE: Do ipsec vendors care about privacy?

From: Gregory Lebovitz <[email-masked]>
Date: Wed, 19 Mar 2003 22:58:55 -0800

First, yes, we do care.

> The only question is operational: can the responder (server) send the
> first EAP message before getting IDi? If this is the case (as it was in
> PIC and seems tobe agreed in some responses to my message) then we are
> done at no cost at all (solution 1). If not, we may need to go to 
> solution 2 (in which the responder authenticates in message 2). Here the
> main operational issue, pointed out by Antonio, is that you need to have
> a
> way for the initiator to signal that he is requiring legacy
> authentication.
>Hugo

I think I may be missing something, and would appreciate some clarification.
Operationally, how can Bob know that he needs to send AUTH if he does not
receive IDi from Alice, from which to do an SPD lookup, to know that AUTH is
required for this particular connection? Bob will likely be a device doing
both EAP'd IKE connections, and non-EAP IKE connections. Doesn't he need IDi
to know when AUTH is to be used?

Gregory
NetScreen

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 20 Mar 2003 23:46:17 +0200 (IST)

A couple of messages in this thread remind us that the WG decided
that protecting the responder's identity from active attacks is preferable
to protecting I's identity from such attacks.  That's true, and I do NOT
suggest to change that decision in the general case. 

However, since ikev2 has already gone to the effort of creating a variant
of the protocol SPECIFIC for the remote access scenario then it makes
sense to take advantage of this (as long as it does not incur in a
significant cost or delay to the ikev2 document) to provide user's privacy
via a strong protection of IDi. As opposed to the general case, in which
what identity (I or R) is more important to protect is debatable (and many
of the participants in this WG have changed their minds on this at least
one time), in the remote access scenario it is OBVIOUS that hiding I's
(the user's) identity from attackers in the network is far more important
(than protecting the publicly known identity of the usually fixed-address
gateway.

If we decide not to provide user's id protection (from active attacks)
in the EAP-based remote access protocol, the rationale for that decision
must be documented (maybe in Radia's draft). This will not avoid later
complaints by vendors and researchers but at least will show that it was a
conscious decision rather than a simple overlook.

Hugo

---

From: Antonio Forzieri <[email-masked]>
Date: Fri, 21 Mar 2003 12:12:23 +0100

> suggest to change that decision in the general case. 
One issue, I think, we have to consider is that when we are using EAP 
authentication we are no longer protecting IDr. Even if in a previous 
message I state that it is not so crucial, i think that we can do 
something to ensure a grade of protection on IDr at no cost.

What I was thinking about is:

Supposing that the responder can send EAP(Request,MD5) (for exaple) 
without knowing IDi. In that case to ensure a grade of protection on IDr 
we can force the use of IDr in message 3. If the iniziator doesn't know 
one of the IDr she cannot procede, and the responder will not expose his ID:

Initiator                          Responder
-----------                        -----------
HDR, SAi1, KEi, Ni         -->
                            <--    HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {[CERTREQ,] IDr,
          SAi2, TSi, TSr}   -->
                            <--    HDR, SK {IDr, [CERT,] AUTH,
                                            EAP }
                            ...
                            ...
As you can see Alice *MUST* use IDr, otherwise Bob will send her a Type 
7 NOTIFY MESSAGES (INVALID-SYNTAX).

What do the others think about?

-- 
------------------------------------------------
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: Sun, 23 Mar 2003 10:48:55 +0200

I like that.

If the client contacts the server and is able to produce a full
ID_DER_ASN1_DN then we know it is not just a polling attack.  But what if
the client presents a ID_IPV4_ADDR?  The IDr payload in message 3 was not
intended to be used as a security measure.  It was intended as a hint to the
gateway as to which identity it should authenticate.

I think that if we accept this idea, we need to be able to limit what IDr is
acceptable to the gateway in message 3.  This would require a new
notification type, something like the following:

        INVALID-RESPONTER-ID                     37
            Indicates that the initiator has sent an unacceptable
            responder ID as part of the initial negotiation.  This
            only causes an error if the initiator has not sent its
            own ID.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Antonio Forzieri
Sent: Friday, March 21, 2003 1:12 PM
To: [email-masked]
Subject: Re: Do ipsec vendors care about privacy?

[SNIP]

Initiator                          Responder
-----------                        -----------
HDR, SAi1, KEi, Ni         -->

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 20 Mar 2003 23:46:17 +0200 (IST)

Hugo

---

From: Antonio Forzieri <[email-masked]>
Date: Mon, 24 Mar 2003 11:13:20 +0100

Yoav Nir wrote:
[SNIP]

> gateway as to which identity it should authenticate.
Agreed.

I think that if Bob doesn't receive IDi and AUTH payloads in message 2 
then he understand that EAP authentication is going to be used.
Alice *MUST* send Bob a *valid IDr*. Valid IDs are all defined in 
draft-ietf-ipsec-ikev2-05.txt except ID_IPV4_ADDR and ID_IPV6_ADDR.
In tha case Bob receives such an IDr (invalid) he *MUST* send the 
notification message Yoav defined below.

What do the other think?

[SNIP]