Subject: [Gen-art] A *new* batch of IETF LC reviews - Jan 6th, 2006

From: "Mary Barnes" <[email-masked]>
Date: Fri, 6 Jan 2006 17:15:53 -0600

Here's the latest round of LC assignments:

http://www.alvestrand.no/ietf/gen/art/gen-art.html
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html

I realize the 1st LC date is already past, so consider this an early
warning.  

Thanks,
Mary.

--------------------------- 
Reviewer: David Black

- 'Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94 and GOST R 
   34.10-2001 algorithms with the Cryptographic Message Syntax (CMS) '
   <draft-ietf-smime-gost-06.txt> as a Proposed Standard

IETF LC ends on 2006-01-04.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-gost-06.txt

--------------------------- 
Reviewer: Harald Alvestrand

- 'Definition of Managed Objects for SCSI Entities '
   <draft-ietf-ips-scsi-mib-08.txt> as a Proposed Standard

IETF LC ends on 2006-01-16.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-08.txt

--------------------------- 
Reviewer: Joel Halpern

- 'Repeated Authentication in IKEv2 '
   <draft-nir-ikev2-auth-lt-04.txt> as an Informational RFC

IETF LC ends on 2006-01-18.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-04.txt

--------------------------- 
Reviewer: John Loughney

- 'RTP Payload Format for MIDI '
   <draft-ietf-avt-rtp-midi-format-14.txt> as a Proposed Standard
- 'An Implementation Guide for RTP MIDI '
   <draft-ietf-avt-rtp-midi-guidelines-14.txt> as an Informational RFC

IETF LC ends on 2006-01-20.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-format-14.tx
t
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-guidelines-1
4.txt

--------------------------- 
Reviewer: Scott Brim

- 'Lightweight Directory Access Protocol (LDAP): Technical Specification
Road 
   Map '
   <draft-ietf-ldapbis-roadmap-08.txt> as a Proposed Standard

IETF LC ends on 2006-01-20.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-roadmap-08.txt

--------------------------- 
Reviewer: Spencer Dawkins

- 'LDAP: Authentication Methods and Security Mechanisms '
   <draft-ietf-ldapbis-authmeth-18.txt> as a Proposed Standard

IETF LC ends on 2006-01-20.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-authmeth-18.txt

--------------------------- 

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 07 Jan 2006 15:57:10 -0500

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.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 18 Jan 2006 15:00:16 +0000

I was just clearing up my mailbox and came across stuff about this draft.
I just reviewed the mobike protocol (draft-ietf-mobike-protocol-07.txt) 
which has some related aims... I suspect (but haven't thought very hard 
about it) that mobike and this are closely related in terms of 
revalidation.  Maybe the mobike wg might be a good place to get some 
thoughts on this proposal and possibly avoid multiple conflicting 
mechanisms..

Regards,
Elwyn

Joel M. Halpern wrote:

> 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 
> problem / solution, but there does not appear to be an IKEv2 working 
> group to provide such an opinion.
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 19 Jan 2006 10:18:26 -0500

I agree.  MOBIKE is trying to solve a different problem.  It is 
handling the impacts of mobility (or roaming).

Russ

At 08:45 AM 1/19/2006, Yoav Nir wrote:
>I have also reviewed the MOBIKE protocol, and as far as I can tell, there
>aims are not the same.
>
>MOBIKE aims to allow peers to continue to use existing SAs even if routing
>tables or IP addresses change. They seek to prevent the need for repeating
>the initial exchange.
>
>My draft aims to allow responders to enforce their policy about repeating
>the exchange of credentials either periodically or upon request. It forces a
>repeat of the initial exchange.
>
>I don't think these two are related.
>
>Regards,
>
>Yoav
>
> > -----Original Message-----
> > From: Elwyn Davies [mailto:[email-masked]]
> > Sent: Wednesday, January 18, 2006 5:00 PM
> > To: Joel M. Halpern
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: [Gen-art] IETF LC review: draft-nir-ikev2-auth-lt-04.txt
> >

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 19 Jan 2006 15:27:07 +0000

The sugestion was that the people doing mobike might be good people to 
review this proposal even if they are solving somewhat different problems.

regards,
elwyn

---

From: "Yoav Nir" <[email-masked]>
Date: Thu, 19 Jan 2006 15:45:57 +0200

Regards,

Yoav