[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Review of draft-ietf-radext-design-03.txt
Section 1.1
Suggest chasnging:
" 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.
See [RFC5080] Section 2.1.1 for a more in-depth discussion of the use
of the State Attribute."
To:
" 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) require
greater expertise and deeper review, as do changes to the RADIUS
operational model, as described in Section 3.3. Such changes should
not be undertaken outside the IETF and when handled within the IETF
require "IETF Consensus" for adoption, as noted in "IANA Considerations
for RADIUS" [RFC3575] Section 2.1."
Add Section 3.3:
" 3.3 RADIUS Operational Model
The RADIUS operational model includes several assumptions:
* The RADIUS protocol is stateless;
* Provisioning of services is not possible within an Access-Reject;
* Distinction between authorization checks and user authentication;
* Authentication and integrity protection of RADIUS packets;
* The RADIUS protocol is a Request/Response protocol;
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. See "Common
RADIUS Implementation Issues and Suggested Fixes" [RFC5080]
Section 2.1.1 for a more in-depth discussion of the use
of the State Attribute.
As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
to deny access to the requested service. As a result, RADIUS does
not allow the provisioning of services within an Access-Reject.
As a result, documents which include provisioning of services
within an Access-Reject are inherently incompatible with RADIUS
and need to be redesigned.
As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request
may not contain user authentication attributes or a State
Attribute linking the Access-Request to an earlier user
authentication. Such an Access-Request, known as an
authorization check, provides no assurance that it
corresponds to a live user. RADIUS specifications
defining attributes containing confidential information
(such as Tunnel-Password) should be careful to prohibit
such attributes from being returned in response to an
authorization check. Also, [RFC5080] Section 2.1.1 notes that
authentication mechanisms need to tie a sequence of
Access-Request/Access-Challenge packets together into one
authentication session. The State Attribute is RECOMMENDED
for this purpose.
While [RFC2865] did not require authentication and integrity
protection of RADIUS Access-Request packets, subsequent
authentication mechanism specifications such as RADIUS/EAP
[RFC3579] and Digest Authentication [RFC5090] have mandated
authentication and integrity protection for all
RADIUS packets. It is expected that specifications for new
RADIUS authentication mechanisms will continue this practice.
As noted in [RFC5080] Section 2.1.1, integrity protection
should also be extended to Access-Request packets performing
authorization checks.
The RADIUS protocol as defined in [RFC2865] is a request-response
protocol spoken between RADIUS clients and servers. A single
RADIUS Access-Request packet will solicit in response at most a single
Access-Accept, Access-Reject or Access-Challenge packet, sent to the IP
address of the RADIUS Client that sent the original Access-Request.
Similarly, a single Change-of-Authorization (CoA)-Request packet
will solicit in response at most a single CoA-ACK or CoA-NAK packet,
sent to the IP address of the Dynamic Authorization Client (DAC)
that sent the original CoA-Request. A single Disconnect-Request packet
will solicit in response at most a single Disconnect-ACK or
Disconnect-NAK packet, sent to the IP address of the Dynamic
Authorization Client (DAC) that sent the original CoA-Request."
NITs:
Section 1
"such an "Expert Review"" -> "such as an "Expert Review""
Section 1.1
"In order enable" -> "In order to enable"
Prior to the first recommendation, insert:
"Encouraging SDOs to request review of RADIUS attribute specifications by
sending email to the AAA Doctors or equivalent mailing list;"
"Development of a program to encourage SDOs to make" -> "SDOs to make"
"proposed in this document;" -> "proposed in this document, with reviews
posted to the RADEXT WG or equivalent IETF mailing list;"
Section 2.1.1
"most significant octet first" -> "in network byte order"
"this usage is NOT RECOMMENDED" -> "this usage is NOT
RECOMMENDED."
Section 2.1.3
"complex structures" -> "complex structures;"
"well-known types" -> "well-known types;"
"implement a new attribute, as the" -> "implement a new attribute. The"
"to send a new attribute" -> "to send a new static attribute"
"dictionary and policy management" -> "dictionary"
"required in the RADIUS server's" -> "required in the policy management
code and in the RADIUS server's"
"error prone implmentations, and interoperability problems." ->
"error prone implementations, interoperability problems, and even
security vulnerabilities."
"most of the complex attributes" -> "most of the existing complex
attributes"
Section 2.1.4
"does not originate from, or is checked" -> "originates from the user
and is not validated"
"on an unauthenticated host." -> "on the user."
Section 2.1.5
"RADIUS also SHOULD NOT be extended to new commands via attributes." ->
"New attributes or new values of existing attributes SHOULD NOT be used
to define new RADIUS commands."
"Specifications SHOULD NOT" -> "Specifications also SHOULD NOT"
Section 3.1.1
"attribute ID" -> "attribute"
Section 3.1.3
"via IETF process" -> "via the IETF process"
"SDO specificiations" -> "SDO specifications."
--
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/>