[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues & Fixes document
David B. Nelson wrote:
> I think that's right. Would you like to reprise the final proposed
> resolution text, i.e. the changes to the current draft? I think I've lost
> track...
The I-D tools page will show the "diff" graphically, but here it is
from local version control. It's a bit long, so it might be an awkward
read as-is.
Alan DeKok.
-----
@@ -152,30 +152,102 @@ Some RADIUS client implementations do no
Some RADIUS client implementations do not properly use the State
attribute in order to distinguish a restarted EAP authentication
process from the continuation of an ongoing process (by the same user
-on the same NAS and port).
-
-Where an EAP-Message attribute is included in an Access-Challenge or
-Access-Accept attribute, RADIUS servers SHOULD also include a State
-attribute. See Section 2.1.3 on Request ID supplementation for
-additional benefits to using the State attribute in this fashion.
-
+on the same NAS and port). Where an EAP-Message attribute is included
+in an Access-Challenge or Access-Accept attribute, RADIUS servers
+SHOULD also include a State attribute. See Section 2.1.2 on Request
+ID supplementation for additional benefits to using the State
+attribute in this fashion.
+
+As defined in [RFC2865] Table 5.44, Access-Request packets may contain
+a State attribute. The table does not qualify this statement, while
+the text in Section 5.24 quoted above adds other requirements not
+specified in that table.
+
+We extend the requirements of [RFC2865] to say that Access-Requests
+which are part of an ongoing Access-Request / Access-Challenge
+authentication process SHOULD contain a State attribute. It is the
+responsibility of the server to send a State attribute in an
+Access-Challenge packet, if that server needs a State attribute in a
+subsequent Access-Request to tie multiple Access-Requests togther into
+one authentication session. As defined in [RFC2865] Section 5.24, the
+State MUST be sent unmodified from the client to the server in the new
+Access-Request reply to that challenge, if any.
+
+While most server implementations require the presence of a State
+attribute in an Access-Challenge packet, some challenge-response
+systems can distinguish the initial request from the response to the
+challenge without using a State attribute to track an authentication
+session. The Access-Challenge and subsequent Access-Request packets
+for those systems do not need to contain a State attribute.
+
+Other authentication mechanisms need to tie a sequence of
+Access-Request / Access-Challenge packets together into one ongoing
+authentication session. Servers implementing those authentication
+mechanisms SHOULD include a State attribute in Access-Challenge
+packets.
+
+In general, if the authentication process involves one or more
+Access-Request / Access-Challenge sequences, the State attribute
+SHOULD be sent by the server in the Access-Challenge packets. Using
+the State attribute to create a multi-packet session is the simplest
+method available in RADIUS today. While other methods of creating
+multi-packet sessions are possible (e.g. [RFC3579] Section 2.6.1),
+those methods are NOT RECOMMENDED.
+
+The only permissible values for a State attribute are values provided
+in an Access-Accept, Access-Challenge, CoA-Request or
+Disconnect-Request packet. A RADIUS client MUST use only those values
+for the State attribute that it has previously received from a server.
An Access-Request sent as a result of a new or restarted
-authentication run MUST NOT include the State attribute, even if the
+authentication run MUST NOT include the State attribute, even if a
State attribute has previously been received in an Access-Challenge
for the same user and port.
-Since a State attribute is always initially provided by the server in
-an Access-Accept, Access-Challenge, CoA-Request or Disconnect-Request,
-a RADIUS client MUST NOT insert a State attribute that it has not
-previously received from the server.
-
-As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
-contain a State attribute. We extend that definition here, to say
-that Access-Request packets that contain an authentication attribute
-or a Service-Type attribute with the value Call Check (10) MAY contain
-a State attribute. Access-Request packets not matching the above
-description MUST contain a State attribute.
-
+In contrast, Access-Requests which are intended to perform
+authorization checks MUST contain a State attribute in order to tie
+the authorization check to a previous authentication session. This
+last requirement often means that an Access-Accept needs to contain a
+State attribute, which is then used in a later Access-Request that
+performs authorization checks.
+
+Access-Request packets that contain a Service-Type attribute with
+value Authorize Only (17) MUST contain a State attribute.
+Access-Request packets that contain a Service-Type attribute with
+value Call Check (10) SHOULD NOT contain a State attribute. Any other
+Access-Request packet that performs authorization checks MUST contain
+a State attribute.
+
+The standard use case for Call-Check is pre-screening authentication
+based solely on the end-point identifier information, such as phone
+number or MAC address in Calling-Station-ID and optionally
+Called-Station-ID. In that use case there is no source of the State
+attribute in the NAS. Other, non-standard, uses of Call-Check may
+require or permit the use of a State Attribute, but are beyond the
+scope of this document.
+
+Implementing Call Check functionality via requests where the User-Name
+and User-Password contain the same information (e.g. MAC address) is
+NOT RECOMMENDED. This practice gives an attacker both the clear-text
+and cipher-text of the User-Password field, which permits many
+additional attacks on the security of the RADIUS protocol. For
+example, if the Request Authenticator does not satisfy the [RFC2865]
+requirements on global and temporal uniqueness, the practice described
+above may lead to the compromise of the User-Password attribute in
+other Access-Requests for unrelated users. Access to the cipher-text
+also greatly simplifies offline dictionary attacks, potentially
+exposing the shared secret, and compromising the entire RADIUS
+protocol.
+
+Any Access-Request packet that performs authorization checks,
+including Call Check, MUST contain a Message-Authenticator attribute.
+Any response to an Access-Request performing an authorization check
+MUST NOT contain confidential information about any user (such as
+Tunnel-Password), unless that Access-Request contains a State
+attribute. The use of State here permits the authorization check to
+be tied to an earlier user authentication. In that case, the server
+MAY respond to the NAS with confidential information about that user.
+The server MUST NOT respond to that authorization check with
+confidential information about any other user.
.in -0.3i
.NH 3
.R
@@ -275,13 +347,20 @@ implementations to implement complex ret
implementations to implement complex retransmission algorithms,
implementations SHOULD support congestive backoff within the limits
suggested by [RFC2865] Section 2.4.
-
+.PP
+.in +0.3i
RADIUS retransmission timers are based on the model used in DHCPv6
[RFC3315]. Variables used here are also borrowed from this
specification. RADIUS is a request/response-based protocol. The
message exchange terminates when the requester successfully receives
the answer or the message exchange is considered to have failed
-according to the retransmission mechanism described below.
+according to the RECOMMENDED retransmission mechanism described below.
+Other retransmission mechanisms are possible, so long as they satisfy
+the requirements on jitter and congestive backoff.
+
+The following algorithms apply to any client that originates RADIUS
+packets, including but not limited to Access-Request,
+Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576].
The retransmission behavior is controlled and described by the
following variables:
@@ -341,6 +420,13 @@ message. If MRC is non-zero, the messag
message. If MRC is non-zero, the message exchange fails when the
either the sender has transmitted the message MRC times, or when MRD
seconds have elapsed since the client first transmitted the message.
+
+For Accounting-Request packets, the default values for MRC, MRD, and
+MRT SHOULD be zero. These settings will enable a RADIUS client to
+continue sending accounting requests to a RADIUS server until the
+request is acknowledged. If any of MRC, MRD, or MRT are non-zero,
+then the accounting information could potentially be discarded without
+being recorded.
.in -0.3i
.NH 3
.R
@@ -732,24 +818,27 @@ 5.26 states:
.fi
It is possible for either a standard attribute or VSA to represent a
-request for an unavailable service. However, where the Type or
-Vendor-ID is unknown, a RADIUS client will not know whether the
-attribute defines a service or not.
-
-In general, it is best for RADIUS clients to err on the side of
+request for an unavailable service. However, where the Type,
+Vendor-ID, or Vendor-Type is unknown, a RADIUS client will not know
+whether the attribute defines a service or not.
+
+In general, it is best for a RADIUS clients to err on the side of
caution. On receiving an Access-Accept including an attribute of
-unknown Type, a RADIUS client SHOULD assume that it is a potential
-service definition, and treat it as an Access-Reject. Unknown VSAs
-SHOULD be ignored by RADIUS clients.
-
-As there may be interoperability issues with the above suggestion,
-client implementations SHOULD make the suggested behavior
-configurable. A configuration flag such as "treat unknown attributes
-as reject" can be exposed to the system administrator. If the flag is
+known Type for an unimplemented service, a RADIUS client MUST treat it
+as an Access-Reject, as directed in [RFC2865] Section 1.1. On
+receiving an Access-Accept including an attribute of unknown Type, a
+RADIUS client SHOULD assume that it is a potential service definition,
+and treat it as an Access-Reject. Unknown VSAs SHOULD be ignored by
+RADIUS clients.
+
+In order to avoid introducing changes in default behavior, existing
+implementations that do not obey this recommendation should make the
+behavior configurable, with the legacy behavior being enabled by
+default. A configuration flag such as "treat unknown attributes as
+reject" can be exposed to the system administrator. If the flag is
set to true, then Access-Accepts containing unknown attributes are
treated as Access-Rejects. If the flag is set to false, then unknown
-attributes in Access-Accepts are be silently ignored. The default
-value for the flag SHOULD be set to true.
+attributes in Access-Accepts are be silently ignored.
On receiving a packet including an attribute of unknown type, RADIUS
authentication server implementations SHOULD ignore such attributes.
@@ -1163,7 +1252,8 @@ forged by an attacker. Cache entries ca
forged by an attacker. Cache entries can then be forcibly expired,
negating the utility of the cache. This attack can be mitigated by
following the suggestions in [RFC3579] Section 4, or by requiring the
-presence of Message-Authenticator, as described in Section 2.2.2.
+presence of Message-Authenticator, as described in Sections 2.1.1 and
+2.2.2.
Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in a wide variety of
@@ -1211,6 +1301,10 @@ Droms, R., Bound, J., Volz, B., Lemon, T
Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315,
July 2003.
+.IP [RFC3576]
+Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,
+"Dynamic Authorization Extensions to Remote Authentication
+Dial In User Service (RADIUS)", RFC 3576, July 2003.
.IP [RFC3579]
Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication
Protocol (EAP)", RFC 3579, September 2003.
--
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/>