[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CRACK questions
Here is the difference - re-authentication with time-based tokens (SecureID)
requires prompting user each time re-keying/re-authentication occurs. Of course
- it is very secure.... but also could be very annoying if it is done too
frequently. Other non-time-based re-authentications could be silent (or skipped,
at the compromise of security) - but at least the local policy administrator has
this alternative for this network to be less secure, but less annoying.
Shawn Mamros wrote:
> At 08:57 AM 11/5/99 -0500, Slava Kavsan wrote:
> >In other words - you are saying that:
> >1) for SecureID-based authentication - CRACK prohibits Phase 1 re-keying
> >without re-prompting the User (while other proposed authentiication schemes
> >have an option to skip authentication when re-keying Phase 1)
> Do they really? That strikes me as being a really bad idea from a
> security standpoint. The word "re-keying" is somewhat of a misnomer,
> especially when applied to Phase 1. What you're really doing is
> reauthenticating (and generating new keying material in the bargain).
> You can't just blindly assume that someone proposing a new Phase 1
> SA from the same IP address and the same ID is, in fact, the same
> party with which you've authenticated before. Would you not require
> a new digital signature from someone for a new Phase 1 SA, if that's
> what they'd used before? Why should any other authentication method
> (even if done in a "phase 1.5" like XAUTH) be any different?
> >2) CRACK prohibits Gateways to initiate Phase 1 re-keying (while previous
> >standards are symmetrical in this respect)
> In a true peer-to-peer environment, I would be concerned. But this
> is a client-to-gateway (and typically user-to-gateway) scenario.
> Should the gateway be wasting its time trying to initiate to a user
> who's gone away? If I'm trying to support thousands of users, that's
> going to be a big concern. If the user wants to reconnect, let them
> reinitiate the connection, especially since they do have to reauthenticate
> anyways (see above). Seems like common sense to me.
> -Shawn Mamros
> E-mail to: firstname.lastname@example.org
IRE Secure Solutions, Inc.
100 Conifer Hill Drive Suite 513
Danvers, MA 01923