From: Paul Hoffman <paul.hoffman@vpnc.org>
To: secdir@mit.edu
CC: mchiba@cisco.com, gdommety@cisco.com, meklund@cisco.com,
dmitton@circularnetworks.com, bernarda@microsoft.com,
radext-chairs@tools.ietf.org, radext-ads@tools.ietf.org, iesg@ietf.org
Subject: Review of draft-ietf-radext-rfc3576bis-09.txt
Date: Mon, 17 Sep 2007 10:19:50 -0700
I am reviewing this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments. Feel free to forward to any appropriate
forum.
This document is a revision of RFC 3576, an Informational RFC describing a
protocol to allow unsolicited messages sent from a RADIUS server to a
Network Access Server.
The protocol is Informational because there were existing implementations
before RFC 3576 was published that would not work with the published spec.
This new document inherits that status, although I question the need to do
that four years later, particularly because some of the changes made in the
earlier RFC and in this revision are for better security. I do not know
whether or not this was discussed in the WG.
This revision consists mostly of terminology changes and clarifications,
all of which seemed fine. The few protocol changes all seem to enhance
security or at least be security-neutral. The changes to the Security
Considerations section (Section 6) are good. One note is that Section 6.3
gives SHOULD-level recommendations to IKEv1 but doesn't mention IKEv2.
Section 6.4, on replay protection, is significantly expanded.
On a stylistic note, Section 6 contains many MUSTs and SHOULDs. Doing this
in the Security Considerations section instead of the body of the protocol
makes it seem like these are "only for security", not really for the
protocol. It would be nice if protocols would put security-related MUSTs
and SHOULDs in the body of the protocol to give them equal footing in the
mind of developers.
--Paul Hoffman, Director
--VPN Consortium