[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on "Hybrid Auth. mode for IKE"
Note that for this scheme to work HASH_I must be sent before HASH_R
which limit the negotiation to the wrong direction for aggressive.
It may work in some revised form of pre-shared secret in main mode (one
that sends the ID's in the clear).
So we have a way that needs a new draft, specific to one token (and a
server for that token that is yet to be designed). How is it better than
the hybrid mode?
Moshe
Greg Carter wrote:
>
> Not that I want to design something for SecurID but its a very small
> modification to their existing technology. Literally adding a loop with
> some keyed hash calculations...
>
> In a regular SecurID authentication the server is presented with the "token"
> displayed on the card. The token is valid at X moment in time. The server
> validates the token at Y moment in time. The ACE server has a window of
> acceptable tokens for W-X-Y-Z moments in time. The ACE server checks its
> window of tokens and replies back to the Gateway with a yes or no.
>
> In the imaginary shared secret mode the token is used in the HASH_I and
> HASH_R validation. Assuming the client is the initiator (only works with
> client as initiator) the client will enter the token, the IKE engine uses
> that to calculate HASH_I and sends HASH_I to the responder for verification.
> Since you are already prepared to off load the Yes/NO decision to the ACE
> server all you need to do is send over HASH_I to the server with the other
> pieces of data, all of which are sent in the clear (Aggressive mode) so
> there isn't any greater security risk. The ACE server tries to validate
> HASH_I with the tokens it has in its window. When it finds one that
> validates it then calculates SKEYID and returns this to you. You can then
> perform the rest of IKE. This is no less secure than the typical SecurID
> exchange. They only have to ensure that the channel between the Gateway and
> the ACE server is protected, which they should be doing anyway. This does
> not expose the one time password, in fact in typical SecurID exchanges the
> "Token" travels in the CLEAR to the Gateway, so SecurID is already prepared
> to "give up" its one time passwords. In this mode it never leaves the users
> machine. Only HASH_I/HASH_R, which are protected from replay by the IKE
> nonce.
>
> Bye.
> ----
> Greg Carter, Entrust Technologies
> greg.carter@entrust.com
>
> > ----------
> > From: Moshe Litvin[SMTP:moshe@checkpoint.com]
> > Sent: Sunday, July 26, 1998 7:56 AM
> > To: Greg Carter
> > Cc: 'Moshe Litvin'; ipsec@tis.com
> > Subject: 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
> >
> >
--
-----------------------------------------------------------------------
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: