Subject: RE: [Gen-art] IETF LC review: draft-nir-ikev2-auth-lt-04.txt

From: [email-masked]
Date: Mon, 9 Jan 2006 11:30:40 -0500

> PS: I was going to ask what the IKEv2 working group thinks about the 
> problem / solution, but there does not appear to be an IKEv2 
> working group to provide such an opinion.

The ipsec mailing list is still active and is the appropriate forum
for this concern.

FYI,
--David

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Saturday, January 07, 2006 3:57 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Gen-art] IETF LC review: draft-nir-ikev2-auth-lt-04.txt
> 
> I was selected as General Area Review Team reviewer for this 
> specification
> (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> This document is close to ready for publication as an individual 
> informational RFC.
> 
> There are some issues.
> Firstly, this is creating a TLV and associated behavior with 
> significant 
> interoperability problems.  As defined, the server decides it 
> would like 
> periodic renewal of the SA.  It sends the noew information in the IKE 
> exchange.  It gets no indication as to whether the receiver 
> understood the 
> information.  Then, if the receiver does not initiate a 
> timely repeat of 
> the authentication (at the preferred refresh time, which is 
> presumably 
> noticeably shorter than the key lifetime or this would not be 
> needed), the 
> server disconnects the session.  This produces distinctly 
> unanticipated 
> results.
> Secondly, I had always understood that key lifetimes were the 
> tool for this 
> kind of thing, not extra timers.  The problem seems to be 
> related to the 
> need to reverse the direction. But this technique seems 
> awkward, and as 
> described just above prone to producing undesirable side-effects.
> If this is going to be published as is, it needs a stronger 
> and clearer 
> health warning about what happens if the server tries to use 
> this and the 
> client does not understand it.
> 
> I would guess from the clause prohibiting derivative works 
> that this is 
> actually a publication of Check Point's approach.  Such 
> publication is 
> fine, but needs to be clearly labelled as such.  
> Traditionally, we have 
> included the company name in the title of such publications.
> 
> The registry for identifying the information used in this is 
> described by 
> RFC 4306 as requiring expert review.  I don't see evidence in the 
> ID-Tracker of that review, unless Russ decided to provide 
> that himself.
> 
> minor: This document uses old boilerplate.
> 
> Yours,
> Joel M. Halpern
> 
> PS: I was going to ask what the IKEv2 working group thinks about the 
> problem / solution, but there does not appear to be an IKEv2 
> working group 
> to provide such an opinion.
> 
> At 06:15 PM 1/6/2006, Mary Barnes wrote:
> >---------------------------
> >Reviewer: Joel Halpern
> >- 'Repeated Authentication in IKEv2 '
> >    <draft-nir-ikev2-auth-lt-04.txt> as an Informational RFC
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/gen-art
> 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art