Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt

From: "Bora Akyol \(bora\)" <[email-masked]>
Date: Tue, 10 May 2005 07:14:37 -0700

Tero

This is all nice and sound in theory, but in practice we know that the
encrypting gateways rarely talk to the end application and neither does
the vpn software running on the end host.

So I suggest the KISS principle as being appropriate here.

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Tuesday, May 10, 2005 3:29 AM
To: Geoff Huang (ghuang)
Cc: Bora Akyol (bora); [email-masked]; [email-masked]; Yoav Nir
Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt

Geoffrey Huang writes:
> Bora Akyol (bora) wrote:
> > Why would we want to give the opportunity for diverged
functionality?
> > 
> > IMHO, better pick one and stick with it unless there is a good 
> > reason to do otherwise.
> 
> The reason is that sending a "re-auth now" message saves the initiator

> from ever having to keep a reauthentication timer.  I guess in 
> practice, this might not really buy you anything.

Or the reauthentication can be based on something else than time only.
I.e. on some system reauthentication might always be required before
doing monetary transaction over $10000 or after 1GB of transferred data
or before accessing certain systems etc.

If the only option is time based thing set when the SA is created it is
quite restrictive. If the server can use implementation depended code to
decide when to request reauthentication from client, that is much more
flexible. I would leave the time based thing away completely, i.e server
would always drive the reauthentication, but some people want it there
too.
--
[email-masked]

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 11 May 2005 13:40:04 +0300

> the vpn software running on the end host.

The whole world is not a VPNs. There is end to end IPsec things. 

> So I suggest the KISS principle as being appropriate here.

I agree, and the easiest is not to have any timers or so, simply a
notify from server saying "Reauthenticate now". That way
implementations can implement any logic they want to, even the time
based one...
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 May 2005 11:24:59 -0700

>implementations can implement any logic they want to, even the time

I'm fine with that as well. It also matches our thinking about 
getting rid of the rekeying timers in IKEv2.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 May 2005 11:32:36 +0300

Yoav Nir writes:
> And so much for a rough consensus. In practice, the only requirement 
> that I've ever seen was to repeat the authentication periodically.  
> Once you have a "period", you want to display it to the user like in a 
> countdown timer.  You also want to ask for credentials in plenty of 
> time, where "plenty" can have different meanings depending on whether 
> the authentication method is a certificate in the computer, a 
> certificate in a token, a token card, a scratch list or a remembered 
> password.  "Plenty" can also have different meanings for a 20-year-old 
> as opposed to a 70-year-old or people with disabilities. These are 
> clearly Initiator-side decisions, not something for the Responder to 
> decide.

As I have not used that kind of system, can you tell me what are the
estimated values for timers. I mean how often do they require
reauthentication. Every 5 minutes? Every 15 minutes? Every hour? Every
24 hours?

And can you also explain what is the reasoning behind this
reauthentication, i.e. what is the expected benefit from it.

It cannot be for revocation checking, as there is much easier ways to
do that (i.e. reload for example CRL every time new one comes, and
check that all current SAs are still authenticated).

It cannot be used for detecting users moving away from keyboard, as
the required time frame there would be way too small to be practical
(unless the authentication is based on the automatic token, but then
on the other hand it is easier for the client to remove the SAs when
token is removed).

So what is the reasoning behind this feature. It would make easier to
talk about this. The draft says "The purpose of this is to limit the
time that SAs can be used by a third party who has gained control of
the IPsec peer."

Can you give some concrete examples.

> That's why "reauthenticate now" is not good enough. "Reauthenticate 
> within 3 minutes" is better, although it doesn't allow for a countdown 
> timer, and again requires the Responder to decide what "plenty" is.

Actually if we use the third party checking argument giving any timer
is bad, as then attacker can see the timer, so he knows how much time
he has to finish the attack. If the reauthentication requests come in
random intervals, or every time the server suspects something (i.e. if
the access pattern changes) then it can make the time attacker can use
much shorter. 
-- 
[email-masked]