RE: Do ipsec vendors care about privacy?

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

I think the others will tell you that it is too late in the day to add such
new things as EAPC.  Since this is an optional, perhaps you can write a
draft that introduces this new payload.  It could optionally be used to save
the extra RT for EAP challenge -> EAP failure with a suggestion of another
method.

You mentioned a lot of EAP methods, many of which are not documented.  Since
we are talking about interoperability here, I suggest that we best stick
with the methods that are in the EAP rfc, namely GTC, MD5 and OTP.  IMO the
only one that is really useful is GTC, because it delivers the password to
the gateway.  Once the gateway has the password it can participate in
whatever authentication scheme the authentication server supports.  If the
server wants the client to hash the password, (as in CHAP or its
derivatives), the gateway can do it instead.

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


Yoav Nir wrote:
> 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.
Agreed. We can use EAPC to make Bob possible send the right EAP message
in IKEv2 Message 4. So if the initiator sends EAPC(MD5), Bob will send
in message 4 a EAP(Request,MD5).

> 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.
It sounds fine for me... What do the others think about?

> 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?
The right question we have to ask to ourselves is:
*What authentication method we will use in IKEv2_EAP?*
*Which of these methods will require ID before sending an EAP message?*
I don't know all the methods EAP supports, however I know that OTP will
not work without knowing IDi. MD5 and SecureID should work without any
problem and GTC (which I don't know) should work. But what about
Defender Token (AXENT), Arcot Systems EAP, CRYPTOCard, DynamID,
Sentrinet and all the other methods supported in EAP?
Of course I think that we aren't going to support RSA PKA, or Smartcard,
we can use them directly in IKEv2, without using EAP!
[SNIP]

If the answer is that there are few authentication method that needs to
know IDi, than let's leave the things as they are, and for that methods
use 1RTT more. (EAP(Request,Identity) in message 4).
[SNIP]

> Yoav

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