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

From: "Bora Akyol \(bora\)" <[email-masked]>
Date: Mon, 9 May 2005 07:52:23 -0700

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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yoav Nir
Sent: Sunday, May 08, 2005 11:39 PM
To: Geoff Huang (ghuang)
Cc: [email-masked]; [email-masked]
Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt

On May 8, 2005, at 7:44 PM, Geoff Huang ((ghuang)) wrote:

>
> Despite the fact that the re-authentication could be achieved with 
> fewer messages, I prefer your approach for the same reasons you 
> mention.  I do have one question however:
>
> - why give the option of sending the AUTH_LIFETIME notify in either a 
> separate informational exchange or at the end of the IKE_AUTH
exchange?
> Why not just include it in the IKE_AUTH exchange?  Is this a 
> compromise between the "re-auth immediately" vs. "re-auth in X 
> seconds" discussion we had on this list a few months ago?
>

Yes.  It allows you to do either. You can do it during the initial
exchange, or you can do it just before you want the peer to
re-authenticate.  My implementation will only send them as part of the
AUTH exchange, but I do want others to use it as well.

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

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

---

From: Geoffrey Huang <[email-masked]>
Date: Mon, 09 May 2005 08:11:49 -0700

> IMHO, better pick one and stick with it unless there is a good

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.

-g

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 May 2005 09:24:25 -0700

>this might not really buy you anything.

Right, it really doesn't. And, it makes implementation harder. I 
support "do it in one place", and I think in the initial exchange 
makes the most sense. "I just decided I want you to reauthenticate" 
doesn't seem nearly as likely as "I know what my reauthentication 
rules are at the beginning".

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 10 May 2005 13:28:53 +0300

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 10 May 2005 13:31:59 +0300

> rules are at the beginning".

Then the problem is that the reauthentication rules might be something
that cannot be expressed by simple time based system.

I.e. what happens after reauthentication. Do we start new timer after
that? What if the server requires reauthentication only if systems are
accessed after office hours (i.e. you can leave connections up when
you go home, but if you try to really use them (download files etc),
it requires reauthentication after 5pm etc.

That was the reason why we left out communcation of timers, lifetimes
etc in the IKEv2 in the first place. Why do we want to add it now?
-- 
[email-masked]

---

From: Geoffrey Huang <[email-masked]>
Date: Tue, 10 May 2005 07:18:42 -0700

That's right - I'd forgotten about this scenario.

Thanks,
-g

---

From: "D. K. Smetters" <[email-masked]>
Date: Tue, 10 May 2005 09:53:53 PDT

>>rules are at the beginning".
The most common place I've seen this in practice is on a policy change
on the server -- anything from new authentication requirements to
a new CRL -- essentially "I've just changed my mind about what I
need from you in order to trust you, and I need you to reauthenticate
NOW". This is not a common event, but it is an important one. And
as pointed out already, a forced reauth mechanism allows almost any
complex reauthentication policy to be specified on the server.

> etc in the IKEv2 in the first place. Why do we want to add it now?

The basic reauth-interval mechanism seems the thing that will be most 
commonly used in practice. It also makes it possible to write clients
that are easier to use (e.g. by scheduling an interactive authentication
when the user is most likely to be there). It's nice, and seems
worth including, but doesn't seem sufficient on its own.

--Diana Smetters
[email-masked]