RE: Do ipsec vendors care about privacy?

["Yoav Nir" <ynir@CheckPoint.com>]

I like the EAPC idea, although I am not sure that it will actually solve a
real problem.  Ususally Alice has only one means of authenticating herself
(she doesn't have a smart card, in addition to a token card and the password
that she remembers).  Still, if two implementations support a user-password
scheme, but one calls it MD5 while the other calls it GTC, it would be nice
to know at the end of the first message.

As for making the IDr in message 3 mandatory for SLA, I think that is a good
idea that solves our polling attack concern.  I think the draft should not
prohibit using an ID_IPV4_ADDR, but it should recommend (at the SHOULD
level) to use some sort of DN or if none exists, and FQDN.  Someone might
want to set up a gateway that anybody can connect to.

You mentioned that "... what seems to me harder to solve is that many EAP
methods require a valid Identity before sending the first EAP message".
What EAP methods are those?  MD5 just sends a random challenge.  It only
needs the identity to check the response.  GTC just expects the password.
It also doesn't need the identity until it's time to check the password.
RSA should not be used as legacy authentication.  I'm not sure about OTP.
It is possible that some authentication servers such as RADIUS need to know
the identity before they send out an MD5 challenge.

That is an implementation problem, which is why I'd rather use GTC for all
legacy authentication methods (RADIUS, LDAP, OS password, etc.)  That way,
the gateway receives the actual password and the ID after message 5.  It can
then do whatever authentication protocol it wishes with an authentication
server.

If somebody does plan to use MD5 with such a RADIUS server, then I guess
they will have to implement the full EAP protocol (including the Identity
messages) and prolong the negotiation to 4 RT.

Yoav

-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Antonio Forzieri
Sent: Monday, March 24, 2003 1:48 PM
To: ipsec@lists.tislabs.com
Subject: Re: Do ipsec vendors care about privacy?


Tero Kivinen wrote:
[SNIP]
>>(2) moving IDr, [CERT,] AUTH from msg 4 to msg 2.
>>    Namely, message 2 from R to I (in section 2.16) will look as:
>>                           <--  HDR, SAr1, KEr, Nr, IDr, [CERT,] AUTH
[SNIP]
> This will open the responders attack to polling attack.
Agreed. I think we *MUST NOT* expose responder ID to polling attack...
Or expose it as less as possible.

[SNIP]
> Some vendors refused to implement or use the aggressive mode of the
> IKEv1, just because of it required you to do expensive operations
> without ever knowing if there is anybody here. I would still guess,
> that most implementations would require the return routability check
> every time if this kind of protocol is used (at least I would in my
> implementation).
Agreed.
I was thinking about something like this to "solve" the problem.

      	Alice                                  Bob
        -------                                -----

HDR,SAi,KEi,Ni,EAPC          -->

                              <--    HDR,SAr,KEr,Nr,[CERTREQ],HLC

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

                              <--    HDR,SK{IDr,[CERT],AUTH, EAP}

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

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

EAPC is a new payload (EAP Capability) and it contains a list of all
authetication types supported by Alice: MD5,OTP,GTC,RSA... (for a
complete list look here: http://www.networksorcery.com/enp/protocol/eap.htm)

This payload let Bob know that Alice is going to use legacy
authentication in EAP. If Bob doesn't support any auth type in EAPC he
will send a notification message NO-VALID-EAP-SUPPORTED.

In message 2 I've introduced HLC HIP Like Cookie, its primary scope is
the same of return routability check plus a DoS protection. I think this
is a better mechanism than return routability check as made in current
ikev2 draft, in fact with HLC Alice *MUST solve* the quiz, while with
the actual mechanism Alice can simply sniff the cookie and respond. Of
course she has to be able of observe that traffic. The first scenario
that comes in my mind is that of Alice being on a LAN and using spoofed
IP address of the LAN she is on.
HLC mechanism is described in draft-ietf-moskowitz-hip-05.txt.

[COPY&PASTE BEGIN]
5.3.1. HIP Cookie Mechanism

    Responder    Generates 2 Random Numbers, I and J
                 Challenge = Ltrunc(SHA1(I|J),K)
                 Send I, K, and Challenge in HIP Cookie in R1
                 Saves I, K, and Challenge for Delta time

    Initiator    Do Until Challenge-response = Challenge
                 Challenge-response = Ltrunc(SHA1(I|Rand),K)
                 EndDo
                 Send I, Rand, and Challenge-response in HIP Cookie
                         in I2

    Responder    Match Response with Challenge based on I
                 Reject if Challenge-response = Challenge
                 Challenge-proof = Ltrunc(SHA1(I|Challenge-response),K)
                 Accept if Challenge-proof = Challenge
[COPY&PASTE END]

Alice MUST also specify a valid IDr, which can't be of type ID_IPV4_ADDR
                         or ID_IPV6_ADDR, in the case such an ID is
specified Bob will send Alice  an INVALID-RESPONTER-ID notification
message. This mechanism ensure a grade of protection on IDr.("You
Tarzan? Me wonder...")

IDi is in message 5, as Hugo proposed. However what seems to me harder
to solve is that many EAP methods require a valid Identity before
sending the first EAP message.
[SNIP]

>>It's all about tradeoffs and here I see privacy as the winner. Don't you?
Agreed.

What do the others think?

--
------------------------------------------------
Antonio Forzieri
CEFRIEL - Politecnico di Milano
Tesista Area E-Service Tecnologies
Tel: 02-23954.334 - email: forzieri@cefriel.it
ICQ# 177683894
------------------------------------------------