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

Re: CRACK questions

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)

2) CRACK prohibits Gateways to initiate Phase 1 re-keying (while previous
standards are symmetrical in this respect)

Could anyone comment on this?

Dan Harkins wrote:

>   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.

--
Bronislav Kavsan
IRE Secure Solutions, Inc.
100 Conifer Hill Drive  Suite 513
Danvers, MA  01923
voice: 978-539-4816
http://www.ire.com
References: