[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Review of Design-01 Strawman
Section 2.1.3
This section makes a recommendation that complex data types SHOULD
be avoided, and then goes on to say that complex attributes are
acceptable for authentication mechanisms. These two recommendations
seem to be in conflict; my recommendation is that an exception for
authentication mechanisms be inserted into the first paragraph and
that the two paragraphs be placed closer together:
Given these limitations, the introduction of complex attributes can
require code changes on the RADIUS server which would be unnecessary
if basic data types had been used instead. In addition, attribute-
specific parsing means more complex software to develop and maintain.
More complexity can lead to more error prone implementations, and
interoperatibility problems. This issues can increase costs to
network administrators as well as reducing reliability and
introducing deployment barriers. As a result, the introduction of
new complex data types within RADIUS attribute specifications SHOULD
be avoided.
....
As can be seen in Appendix B, most of the complex attributes involve
authentication or security functionality. Supporting this
functionality requires code changes on both the RADIUS client and
server, regardless of the attribute format. As a result, in most
cases, the use of complex attributes to represent these methods is
acceptable, and does not create additional interoperability or
deployment issues.
Section 2.1.4
New specifications SHOULD avoid defining message formats for services
inside a RADIUS document. In addition, the service being provisioned
SHOULD NOT be defined in a RADIUS specification...
For new services using RADIUS, the service SHOULD be defined
elsewhere, and provisioned in RADIUS.
Could be rephrased to:
RADIUS specifications define how an existing service or protocol
can be provisioned using RADIUS. Therefore, it is expected that a RADIUS
attribute specification will reference documents defining the
protocol or service to be provisioned. Within the IETF, a RADIUS
attribute
specification SHOULD NOT be used to define the protocol or service being
provisioned. New services using RADIUS for provisioning SHOULD be
defined
elsewhere and referenced in the RADIUS specification.
Section 2.2
The high-order octet of the Vendor-Id field is 0 and the low-order 3
octets are the SMI Network Management Private Enterprise Code of the
Vendor in network byte order.
Actually, I believe that the SMI Enterprise code is 4 octets, no?
Other attribute formats are NOT RECOMMENDED. Examples of NOT
RECOMMENDED formats include Vendor types of more than 16 bits, Vendor
lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
Vendor-Specific contents that are not in Type-Length-Value format.
Is there a recommendation that RADIUS servers support the 16 bit vendor
type format?
Section 3.1.1
Vendors and SDOs are reminded that the standard RADIUS attribute ID
space, and the ennumerated
Recommend changing to:
Vendors and SDOs are reminded that the standard RADIUS attribute
space and the ennumerated
The following paragraphs are a bit awkward:
The VSA space is intended to enable self-allocation of RADIUS
extensions for use by one or more vendors within an industry segment
or within the global Internet community. As the use-cases for VSAs
vary considerably, it is important to make a distinction between use-
cases in terms of the expected level of design guideline adherence
and attention to interoperability considerations. The design and
specification of VSAs for multi-vendor usages, and/or by non-IETF
SDOs, SHOULD be undertaken with the same level of care as standard
RADIUS attributes. Specifically, the provisions of this document
that apply to Standard RADIUS attributes SHOULD apply to any such
VSAs.
In this regard, the term "Vendor-Specific Attribute" is perhaps
unfortunate. The term refers both to the encoding format, and to the
common use case where individual vendors allocate attributes not
suitable for general usage.
When used by an SDO, a VSA is intended to have a significant level of
interoperability, just like the standard RADIUS attributes. As such,
those SDO attributes are not specific to any single vendor, and the
term "Vendor-Specific" may be misleading. An alternate term which
better describes the SDO use-case is SDO-Specific Attribute (SSA).
For interoperability, the SSAs happen to use the same encoding format
as those VSAs that are defined by an individual vendor.
Recommend changing to:
[RFC2865] Section 5.26 uses the term "Vendor-Specific Attribute"
to refer to an encoding format which can be used by individual
vendors to define attributes not suitable for general usage.
However, since then VSAs have also become widely used by SDOs
defining attributes intended for multi-vendor interoperability. As such,
these attributes are not specific to any single vendor, and the
term "Vendor-Specific" may be misleading. An alternate term which
better describes this use case is SDO-Specific Attribute (SSA).
The design and specification of VSAs for multi-vendor usage
SHOULD be undertaken with the same level of care as standard
RADIUS attributes. Specifically, the provisions of this document
that apply to standard RADIUS attributes also apply to SSAs or
VSAs for multi-vendor usage.
Section 3.1.2
However, it is RECOMMENDED that Vendors follow the
guidelines outlined here, which are intended to enable maximum
interoperability with minimal changes to existing systems.
Recommend changing to:
However, it is RECOMMENDED that vendors follow the
guidelines outlined here, which are intended to enable maximum
interoperability with minimal changes to existing systems.
" Vendors are reminded that allocations of attributes or values for
attributes of enumerated type from the standard space MUST follow the
process described in [RFC3575] Section 2.1. If this is not possible,
they SHOULD self-allocate an attribute from their Vendor-Specific
space, and define an appropriate value for it.
If Vendors require multi-vendor interoperability for some RADIUS
specification, then the guidelines given below for SDO allocations
SHOULD be followed."
These paragraphs seem like they belong in Section 3.1.1. Is there a way
to integrate them there?
Section 3.1.3
This change control can be obtained by requesting a Private
Enterprise Number (PEN) from the Internet Assigned Number Authority
(IANA), for use as a Vendor-Id within a Vendor-Specific attribute.
The term PEN is used here, but earlier, the term SMI vendor code is used.
Can we make the usage consistent?
" This process means that SDOs do not have to rehost VSAs into the
standards space solely for the purpose of obtaining IETF review.
Rehosting puts pressure on the standards space, and may be harmful to
interoperability, since it can create two ways to configure the same
functionality. Rehosting may also require changes to the RADIUS data
model which will affect implementations that do not intend to support
the SDO specifications."
How about this?
" It should be understood that SDOs do not have to rehost VSAs into the
standards space solely for the purpose of obtaining IETF review.
Rehosting puts pressure on the standards space, and may be harmful to
interoperability, since it can create two ways to provision the same
service. Rehosting may also require changes to the RADIUS data
model which will affect implementations that do not intend to support
the SDO specifications."
Section 3.1.4
" SDOs are encouraged to seek review of VSA specifications by the IETF,
prior to finalization of a proposed specification. Once reviewed,
the specifications SHOULD be made publicly available, for maximum
interoperability. Where the full specifications cannot be made
public, the RADIUS attribute and value definitions SHOULD be
published instead as an Informational RFC, as with [RFC4679]. This
process SHOULD be followed instead of requesting IANA allocations
from within the standard RADIUS attribute space.
Similarly, vendors SHOULD make their specifications publicly
available, for maximum interoperability. Due to the large number of
vendors, it is not necessary for them to request publication of their
VSA specifications as Informational RFCs by the IETF.
All other specifications, including new authentication and/or
security methods SHOULD be allocated via the standard RADIUS space,
as noted in [RFC3575] Section 2.1."
How about this?
" SDOs are encouraged to seek early review of SSA specifications
by the IETF. This review may be initiated by sending mail to the
AAA Doctors list. Since the IETF is not a membership organization,
in order to enable the RADIUS SSA specification to be reviewed, it is
RECOMMENDED that it be made publicly available; this also
encourages interoperability. Where the RADIUS SSA specification is
embedded within a larger document which cannot be made public,
the RADIUS attribute and value definitions SHOULD be
published instead as an Informational RFC, as with [RFC4679]. This
process SHOULD be followed instead of requesting IANA allocations
from within the standard RADIUS attribute space.
Similarly, vendors are encouraged to make their specifications publicly
available, for maximum interoperability. However, it is not
necessary for them to request publication of their
VSA specifications as Informational RFCs by the IETF.
All other specifications, including new authentication and/or
security mechanisms SHOULD be allocated via the standard RADIUS space,
as noted in [RFC3575] Section 2.1."
Section 4
This document requires no action by IANA. [RFC4005].
What is the [RFC4005] reference for?
Section 5
Where new RADIUS attributes use cryptographic algorithms, algorithm
negotiation SHOULD be supported. Specification of a mandatory-to-
implement algorithm is REQUIRED, and it is RECOMMENDED that the
mandatory-to-implement algorithm be certifiable under FIPS 140.
Can we reference FIPS 140 here? There is currently a draft FIPS 140-3
document available from NIST.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>