Here is my review of the RADIUS Design Guidelines document:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt
Section 1.1 states:
" The advice in this document applies to attributes used to encode
service-provisioning or authentication data. RADIUS protocol
changes, or specification of attributes that can be used to, in
effect, provide new RADIUS commands (such as Service-Type) are out of
scope. Since protocol changes require greater expertise and deeper
review, such changes should not be undertaken outside the IETF and
when handled within the IETF require "IETF Consensus" for adoption,
as noted in [RFC3575] Section 2.1.
As with protocol changes, this document does not provide guidance to
document authors seeking to change the RADIUS operational model.
While RADIUS server implementations may keep state, the RADIUS
protocol is stateless, although information may be passed from one
protocol transaction to another via the State Attribute. As a
result, documents which require stateful protocol behavior without
use of the State Attribute are inherently incompatible with RADIUS as
defined in [RFC2865], and need to be redesigned. "
I am not sure that these paragraphs provide a sufficiently comprehensive description of what would constitute a change to the RADIUS operational model. For example, "Design Considerations for Protocol Extensions" (http://www.watersprings.org/pub/id/draft-carpenter-extension-recs-02.txt) provides a definition of a "major extension" in Section 3.3 that seems considerably broader than the considerations provided in the above paragraphs. My suggestion would be to expand this section to explicitly list some of the basic assumptions of the RADIUS protocol.
Section 5
Given the concern about SHA-1 collisions, is it worth recommending against use of this algorithm in new attributes?
I also something might be worth saying about the use of RADIUS without user authentication.
Other comments:
Section 1
Suggest changing:
" This document provides guidelines for the design of RADIUS attributes
both within the IETF as well as within other Standards Development
Organizations (SDOs). By articulating RADIUS design guidelines, it
is hoped that this document will encourage the development and
publication of high quality RADIUS attribute specifications. The
advice in this document will not be helpful unless it is put to use.
As with "Guidelines for Authors and Reviewers of MIB Documents"
[RFC4181], it is expected that this document will enable authors to
check their document against the guidelines prior to requesting a
review (such an "Expert Review" described in [RFC3575]). Similarly,
it is hoped that this document will be of use to reviewers (such as
WG participants or the AAA Doctors) in improving the consistency of
reviews.
"
To:
" This document provides guidelines for the design of RADIUS attributes
both within the IETF as well as within other Standards Development
Organizations (SDOs). By articulating RADIUS design guidelines, it
is hoped that this document will encourage the development and
publication of high quality RADIUS attribute specifications.
However, the advice in this document will not be helpful unless
it is put to use. As with "Guidelines for Authors and Reviewers
of MIB Documents [RFC4181], it is expected that this document will
be used by authors to check their document against the guidelines
prior to requesting review (such an "Expert Review" described
in [RFC3575]). Similarly, it is expected that this document will
used by reviewers (such as WG participants or the AAA Doctors),
resulting in an improvement in the consistency of reviews."
Section 5
Suggest changing
"The MD5 algorithm
has recently become a focus of scrutiny and concern in security
circles, and as a result, the use of this technique in new attributes
is NOT RECOMMENDED."
To:
"The MD5 and SHA-1 algorithms
have recently become a focus of scrutiny and concern in security
circles, and as a result, the use of these algorithms in new attributes
is NOT RECOMMENDED."
|