[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on "Hybrid Auth. mode for IKE"
Let's try to see how it will work with SecurID:
The user connects to his ISP and initiate an aggressive exchange (main
mode is not possible when using pre-shared secret). The GW ask an
imaginary new version of ACE server(*) for the current value shown on
the user screen. When it gets the answer it considers it as the
pre-shared secret and sends the response for the user.
The user types what he see on his token as his shared secret. If the
minute when the the types is not exactly what the ACE server thought
that it was (because of network delay, clock drifts or other problem)
the authentication will fail.
With challenge type tokens you have the problem of failed negotiation
when the server thinks that the challenge reached the user but it didn't
or vice versa.
(*) About that imaginary ACE server: You dismiss as trivial the problem
of the server disclosing a secret information. How would Entrust fills
about disclosing a one time password to a Fire Wall? why would SDTI
should think otherwise? Apart from loosing control of the security of
their system they also loose the ability to guarantee that each code can
be used only once.
Regards,
Moshe
Greg Carter wrote:
>
> SecurID uses time based, the card MUST be synchronized to the server or it
> doesn't work, each response is valid for 2 minutes (I think). So that is
> plenty of time to do a look up of the response on the Gateway side. DES
> cards do not require perfect synchronization. The Next Challenge
> calculation can be emulated (in most cases, I only know how a few of the
> cards do the calculation) in software without the knowledge of the DES key,
> only the last response is needed. So you can display the expected Challenge
> to the user without going to the backend server. If it doesn't match the
> one displayed on the card all the user has to do is enter the one displayed
> by your software, and they are back in sync. If your software and the
> backend server get out of sync then have the Gateway configured to allow the
> user limited access to a www page where they can go get back in sync. Does
> the user care that IKE is used for synchronization ? probably not. Also
> either you or the card vendor can write the software to 'look ahead' X
> number of responses for auto resync. Although when used this way it means
> you are returned X number of keys to try to authenticate HASH_I or HASH_R.
> As long as a central server with some sort of look ahead is used I don't see
> synchronization being that big a deal where it can't be done by some means
> out of band to IKE since it will be infrequent.
>
> Bye.
> ----
> Greg Carter, Entrust Technologies
> greg.carter@entrust.com
>
> > ----------
> > From: Moshe Litvin[SMTP:moshe@CheckPoint.COM]
> > Sent: Thursday, July 23, 1998 1:45 PM
> > To: Greg Carter
> > Cc: moshe@CheckPoint.COM; ipsec@tis.com; Pat Calhoun (E-mail)
> > Subject: Re: Comments on "Hybrid Auth. mode for IKE"
> >
> > Greg,
> >
> > You proposal require perfect state synchronization between the client
> > and the server (either what is the last challenge "sent" or the exact
> > time). It is impossible in practice especially since there are no means
> > to synchronize them.
> >
> > Also notice that in the hybrid mode no challenge and no reply are
> > passing in the clear.
> >
> > Regards,
> >
> > Moshe
> >
> >
> >
--
-----------------------------------------------------------------------
Moshe Litvin Check Point Software Technologies Ltd.
moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555)
Fax: +972-3-575-9256
-----------------------------------------------------------------------
References: