> 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 PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Joel M. Halpern > Sent: Saturday, January 07, 2006 3:57 PM > To: [email protected] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > 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 protected] > https://www1.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
