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

From: Yoav Nir <[email-masked]>
Date: Thu, 5 May 2005 09:49:21 +0300

Hi.

I've just submitted version -02 of the repeated authentication draft. 
Not much is changed other than some typos and explanations. I thought 
that version -02 would include a reference to the IKEv2 RFC, but I 
guess not yet.

Is anyone else interested in this?

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Repeated Authentication in IKEv2
	Author(s)	: Y. Nir
	Filename	: draft-nir-ikev2-auth-lt-02.txt
	Pages		: 4
	Date		: 2005-5-4
	
With some IPsec peers, particularly in the remote access scenario, it
is desirable to repeat the mutual authentication periodically.
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.  This is not the
same as IKE SA rekeying, and need not be tied to it.  Repeated
authentication can be achieved by simply repeating the Initial
exchange by whichever side has a stricter policy.
However, in the remote access scenario it is usually up to a human
user to supply the authentication credentials, and often EAP is used
for authentication, which makes it unreasonable or impossible for the
remote access gateway to initiate the exchange.
This document describes how the original Responder can send a
notification to the Initiator with the number of seconds before the
authentication needs to be repeated.  The Initiator will repeat the
Initial exchange before that time is expired.  If the Initiator fails
to do so, the Responder may close all tunnels.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nir-ikev2-auth-lt-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-nir-ikev2-auth-lt-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <[email-masked]>

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: [email-masked]
Date: Tue, 10 May 2005 09:42:18 +0300

Existing AAA protocols (RADIUS and Diameter) have found it useful 
to have both Session-Timeout/Authorization-Lifetime AVPs, and the 
ability for the server to initiate reauthentication even if the 
previously given lifetime hasn't passed yet (Change-of-Authorization
and Re-Auth-Request messages).

Since many VPN gateways are likely to use some AAA protocol, I 
don't think we should remove the ability to send a new AUTH_LIFETIME 
in a separate Informational exchange (especially considering that it
doesn't complicate implementations very much).

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked]
> Sent: Monday, May 09, 2005 7:24 PM
> To: Geoffrey Huang; Bora Akyol (bora)
> Cc: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki); Yoav Nir
> Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt
> 
> 
> At 8:11 AM -0700 5/9/05, Geoffrey Huang wrote:
> >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, his 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: [email-masked]
Date: Thu, 12 May 2005 12:17:11 +0300

BTW, since this is your individual draft rather than a 
working group item, we don't have to get rough consensus 
on it.

Several people have expressed that they think it's useful
to have both "reauth in 3600 seconds" and "reauth now"
functionality. Many existing VPN products also have both.
We don't have to get everyone to agree that this is a
useful feature, because those who think it isn't can
just not implement it... 

Best regards,
Pasi

> From: [email-masked]
> Sent: Wednesday, May 11, 2005 9:59 PM
> To: Paul Hoffman
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); Tero Kivinen; ipsec; 
> Geoff Huang; Bora Akyol
> 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.
> 
> 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.