[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CRACK questions



Somes points to consider is

- Re-authentication of end-user typically occurs after a period of
inactivity.
This is different from time based rekeying. Should 'CRACK' take that into
account?

- In the case of client-gateway scenario should phase 1 rekeying
authenticate the
end-user or the device? CRACK seems to need that phase1 rekeying MUST
reauthenticate
the end-user always.

For example a design may want to

reauthencticate the end-user once per session (and after a
period of inactivity)
Reauthenticate of the device periodically during phase1 rekeying

-- Looks like such a design is not possible using CRACK alone.

Thanks,

-- sankar --

-----Original Message-----
From: Shawn Mamros [mailto:smamros@nortelnetworks.com]
Sent: Friday, November 05, 1999 6:58 AM
To: Slava Kavsan
Cc: ipsec; ipsra
Subject: Re: CRACK questions


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: smamros@nortelnetworks.com