[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on "Hybrid Auth. mode for IKE"
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
>
>
Follow-Ups: