[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CRACK questions
Slava,
On Wed, 03 Nov 1999 05:20:25 EST you wrote
>
> I couldn't find any IKE SA re-keying considerations in the draft, and I
> have a couple questions on the subject:
>
> 1) How does re-keying scenario look like, esp. with the time-base
> SecureID authentication?
> I am sure we do not want to re-prompt user each time when re-keying
> takes place.
Then how does the gateway know its's still talking to the "user"? Part of
IKE SA re-keying is re-authenticating. You can't do a token card
authentication unless you get some input from the token card.
> 2) How does re-keying scenario look like when the roles of the Initiator
> and Responder are reversed (in other words - if the Gateway decides to
> re-key)?
The gateway doesn't initiate a phase 1 to re-key. The gateway can initiate
phase 2 rekeys because he has authenticated someone at that particular IP
address. But when the IKE SA, which provides that binding, goes away the
gateway has no knowledge that that someone is still at that IP address.
Client policy is promiscuous; it's me to anybody. You can't initiate a
phase 1 to "anybody" and just because someone used to be at a random IP
address does not mean he still is.
If you don't want to re-prompt the user to reauthenticate and expect a
gateway to initiate an IKE SA rekey then the gateway can end up initiating
to someone who has just got the lease on that IP address and not require
him to prove he is who it thinks he is. Any properly implemented security
gateway would not allow that to happen.
Dan.
Follow-Ups:
References: