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

From: "Geoff Huang \(ghuang\)" <[email-masked]>
Date: Sun, 8 May 2005 09:44:35 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Yoav Nir
> Sent: Sunday, May 08, 2005 12:23 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt
> 
> The reason I'm asking is that I'm not sure what I'm doing 
> there is the best way.
> 
> What the draft says is for the Initiator to wait a certain 
> amount of time, and then tear down all the SAs and create new 
> ones via a completely new initial exchange.  This is much 
> more than is necessary.  
> A better solution would be to allow a new AUTH exchange (2 or 6
> messages) without an INITIAL exchange, and without any 
> piggybacked child SAs.

Or simply an informational exchange that contains an AUTH payload (or
AUTH + ID payloads).

> The reason I chose the inferior solutions is for simplicity:
>   - No need to create a new state machine for a standalone 
> AUTH exchange
>   - Easier to add support to existing IKEv2 implementations
>   - No need to find something to sign in the in AUTH payloads 
> (maybe the original INITIAL exchange packets? Would it be 
> secure to sign them
> again?)
> 
> Anyway, I can see valid reasons to do it either way, and that 
> is why I'm soliciting comments.

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?

-g

> 
> 
> On May 6, 2005, at 6:06 PM, <[email-masked]> wrote:
> >
> > Yes, I think many vendors will need something like this, and it
> > makes more sense to have one interoperable way, rather than each
> > vendor implementing their proprietary extension. And IMHO it
> > does not matter what exactly the details are, as long as we get
> > it published in a timely fashion.
> >
> > Given that the IANA actions for IKEv2 are already done, I think
> > you should ask Russ to appoint a "Designated Expert", and move
> > forward as individual submission for informational (so we don't
> > have to wait years for all IPsec folks to get full consensus
> > on the punctuation).
> 
> 
> _______________________________________________
> 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: Yoav Nir <[email-masked]>
Date: Mon, 9 May 2005 09:38:59 +0300

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