[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comment on draft-ietf-radext-design-04.txt, Appendix A
There are a few cases where the text in Appendix A is not backed by
discussion in the rest of the document, and vice versa.
A.4
* Extending the RADIUS packet length limitation past 4096 octets.
A multi-packet sequence of Access-Request / Access-Challenge
SHOULD be used instead. If that is not possible, then a method
other than RADIUS SHOULD be used to transport the data.
[BA] Generally, the Design Guidelines in Appendix A are supported by text
elsewhere in the document. This one has no corresponding discussion, and
it seems to me that there are enough issues so that adding a section for
such a discussion could be beneficial. For example:
* Discussion of the length restriction. As far as I can tell, the length
restriction is mentioned only in RFC 2865 Section 3. However, there
is no normative language or even discussion on how receivers behave
on encountering larger packets. Based on this, one thing we can say is
that a sender cannot by default assume that a receiver will be able to
handle a RADIUS packet longer than 4096 octets. So my suggestion
would be to rephrase the first sentence to state that attribute designers
SHOULD NOT assume that receivers can handle packets larger than 4096
octets. In the discussion section, you can then talk about potential
alternatives for designers.
* Support for Access-Challenge. In looking back at the WG discussion on
attribute length, the most frequently discussed cases where large
attributes (and hence large packets) might be required are filter rules
(e.g. NAS-Filter-Rule). Unfortunately, Section 3 of RFC 4849 does not
permit this attribute to be placed in an Access-Challenge. There are
quite a few other attributes that also do not permit this usage (although
most are not large enough to be an issue). Even if this were to be
fixed, using a multi-packet sequence would imply that RADIUS attributes in
a subsequent packet would be concatenated to those in a new packet, as
opposed to replacing them. So it seems to me that the attribute would
need to be specially designed for fragmentation across multi-packet
sequences. I don't think we can see that even the Extended Attributes are
designed for such a use.
Also, as we discussed in the RADIUS location work, not all NASes are going
to be "Challenge capable" for a access mechanism. Does this imply wider
use of the Challenge-Capable Attribute than what is implied in the RADIUS
location draft?
Given all of this, it is not clear to me that the suggestion in the rest
of the paragraph will be workable in all situations.
My suggestion is to change A.4 to the following:
A.4. Changes to the RADIUS Protocol
Does the attribute specification change the RADIUS operational model?
If so, then another mmethod of achieving the design objectives SHOULD
be used. Potential problems include:
* Defining new commands in RADIUS using attributes.
The addition of new commands to RADIUS should be handled
via allocation of a new command Code, not by use of an attribute.
This includes new commands created by overloading attributes such
as the Service-Type attribute to define new values that modify
the functionality of Access-Request packets.
* Using RADIUS as a transport protocol for data unrelated to
authentication, authorization or accounting. Using RADIUS
to transport authentication methods such as EAP is explicitly
permited, even if those methods require the transport of
relatively large amounts of data. Transport of opaque
data relating to AAA is also permitted, as discussed in
Section 2.1.3. However, if the specification does not
relate to AAA, then RADIUS SHOULD NOT be used.
* Assuming support for packet lengths greater than 4096 octets.
Attribute designers cannot assume that RADIUS implementations
can successfully handle packets larger than 4096 octets.
If a specification could lead to a RADIUS packet larger than
4096 octets, then alternatives described in Section 3.3
SHOULD be considered.
* Stateless operation. The RADIUS protocol is stateless, and
documents which require stateful protocol behavior without use of
the State Attribute need to be redesigned.
* Provisioning of service in an Access-Reject. This is not
permitted. If limited access needs to be provided, then an
Access-Accept with appropriate authorizations can be used instead.
* Lack of user authentication or authorization restrictions.
In an authorization check, where there is no demonstration of a
live user, confidential data cannot be returned. Where there
is a link to a previous user authentication, the State attribute
needs to be present.
* Lack of per-packet integrity and authentication.
It is expected that documents will support per-packet
integrity and authentication.
* Modification of RADIUS packet sequences. In RADIUS,
each request is encapsulated in its own packet, and
elicits a single response, sent to the requester. Since
changes to this paradigm are likely to require major modifications
to RADIUS client and server implementations, they SHOULD be
avoided if possible.
For further details, see Section 3.3.
Also, change Section 3.3 to the following:
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;
* RADIUS is a Client/Server protocol;
* Packet length restriction.
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.
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.
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. A similar need exists when
dynamic authorization is used in as noted in [RFC5176] Section 3.3.
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 certain RADIUS packets. [RFC5080] Section
2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
including Access-Request packets performing authorization checks. It
is expected that specifications for new RADIUS authentication
mechanisms will continue this practice.
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 and port of the RADIUS Client that originated the Access-
Request. Similarly, a single Change-of-Authorization (CoA)-Request
packet [RFC5176] will solicit in response at most a single CoA-ACK or
CoA-NAK packet, sent to the IP address and port of the Dynamic
Authorization Client (DAC) that originated the 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 and
port of the Dynamic Authorization Client (DAC) that originated the
CoA-Request. Changes to this model are likely to require major
revisions to existing implementations and so this is NOT RECOMMENDED.
The Length field in the RADIUS packet header is defined in [RFC2865]
Section 3. It is noted there that the maximum length of a RADIUS
packet is 4096 octets. As a result, attribute designers SHOULD NOT
assume that a RADIUS implementation can successfully process
RADIUS packets larger than 4096 octets. If a situation is envisaged
where it may be necessary to carry authentication, authorization or
accounting data in a packet larger than 4096 octets, then one of
the following approaches is RECOMMENDED:
1. Utilization of a sequence of packets. In the case of RADIUS
accounting, this would include a sequence of Accounting-Request
packets. This is non-trivial since RADIUS accounting clients
would need to be modified to split the attribute stream across
multiple Accounting-Requests, and billing servers would need to be
modified to re-assemble and interpret the attribute stream.
For RADIUS authentication, a sequence of Access-Request/
Access-Challenge packets would be used; for this to be feasible,
attribute designers need to enable inclusion of
attributes that can consume considerable space within
Access-Challenge packets. To maintain compatibility with
existing NASes, either the use of Access-Challenge
packets needs to be permissible (as with RADIUS/EAP, defined in
[RFC3579]), or support for receipt of an Access-Challenge needs to
be indicated by the NAS (as in RADIUS Location [RADIUSLOC]). Also,
the specification needs to clearly describe how attribute
splitting is signalled and how attributes included within
the sequence are to be interpretted, without requiring
stateful operation. Unfortunately, previous specifications
have not always exhibited the required foresight. For example,
even though very large filter rules are conceivable, the NAS-Filter-Rule
Attribute defined in [RFC4849] is not permitted in an
Access-Challenge packet, nor is a mechanism specified to
allow a set of NAS-Filter-Rule attributes to be split across
an Access-Request/Access-Challenge sequence.
2. Utilization of names rather than values. Where an attribute
relates to a policy that could conceivably be pre-provisioned
on the NAS, then the name of the pre-provisioned policy can be
transmitted in an attribute, rather than the policy itself,
which could be quite large. An example of this is the Filter-Id
Attribute defined in [RFC2865] Section 5.11, which enables a set
of pre-provisioned filter rules to be referenced by name.
3. Utilization of Packetization Layer Path MTU Discovery
techniques, as specified in [RFC4821]. As a last resort, where
the above techniques cannot be made to work, it may be possible
to apply the techniques described in [RFC4821] to discovery of
of the maximum supported RADIUS packet size on the path between
a RADIUS client and a home server. While such an approach
can avoid the complexity of utilization of a sequence of
packets, dynamic discovery is likely to be time consuming
and cannot be guaranteed to work with existing RADIUS
implementations. As a result, this technique is not
generally applicable.
--
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/>