[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed Resolution to RFC 3576bis Issue 161: Authorize-Only Service-Type
The text of Issue 161 is enclosed below. The proposed resolution is as
follows:
Add Section 3.1:
"3.1. State
[RFC2865] Section 5.44 states:
An Access-Request MUST contain either a User-Password or a CHAP-
Password or State. An Access-Request MUST NOT contain both a
User-Password and a CHAP-Password. If future extensions allow
other kinds of authentication information to be conveyed, the
attribute for that can be used in an Access-Request instead of
User-Password or CHAP-Password.
In order to satisfy the requirements of [RFC2865] Section 5.44, an
Access-Request with Service-Type="Authorize-Only" MUST contain a
State attribute.
In order to provide a State attribute to the NAS, a server sending a
CoA-Request or Disconnect-Request with a Service-Type value of
"Authorize-Only" MUST include a State Attribute, and the NAS MUST
include the State Attribute unchanged in the Access-Request. A NAS
receiving a Disconnect or CoA-Request containing a Service-Type value
of "Authorize-Only" but lacking a State attribute MUST send a
Disconnect or CoA-NAK and SHOULD include an Error-Cause attribute
with value 402 (Missing Attribute)."
In Section 3.5, change Note 6 to the following:
" [Note 6] When included within a Disconnect-Request or CoA-Request, a
Service-Type Attribute with value "Authorize Only" indicates that the
Request only contains NAS and session identification attributes, and
that the NAS should attempt reauthorization by sending an Access-
Request with a Service-Type Attribute with value "Authorize Only".
This enables a usage model akin to that supported in Diameter, thus
easing translation between the two protocols. Support for the
Service-Type Attribute is optional within CoA-Request and Disconnect-
Request messages; where it is not included, the Request message may
contain both identification and authorization attributes. A NAS that
does not support the Service-Type Attribute with the value "Authorize
Only" within a Disconnect-Request MUST respond with a Disconnect-NAK
including no Service-Type Attribute; an Error-Cause Attribute with
value "Unsupported Service" MAY be included. A NAS that does not
support the Service-Type Attribute with the value "Authorize Only"
within a CoA-Request MUST respond with a CoA-NAK including no
Service-Type Attribute; an Error-Cause Attribute with value
"Unsupported Service" MAY be included.
A NAS supporting the "Authorize Only" Service-Type value within
Disconnect-Request or CoA-Request messages MUST respond with a
Disconnect-NAK or CoA-NAK respectively, containing a Service-Type
Attribute with value "Authorize Only", and an Error-Cause Attribute
with value "Request Initiated". The NAS then sends an Access-Request
to the RADIUS server with a Service-Type Attribute with value
"Authorize Only". This Access-Request SHOULD contain the NAS
attributes from the Disconnect or CoA-Request, as well as the session
attributes from the Request legal for inclusion in an Access-Request
as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As
noted in [RFC2869] Section 5.19, a Message-Authenticator attribute
SHOULD be included in an Access-Request that does not contain a User-
Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The
RADIUS server should send back an Access-Accept to (re-)authorize the
session or an Access-Reject to refuse to (re-)authorize it."
------------------------------------------------------------------------------------------------------------
Issue 161: Authorize-Only Service-Type
Submitter name: Joe Urbasik
Submitter email address: joe.urbasik@siemens.com
Date first submitted: January 12, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00030.html
Document: FIXES-01
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
I am looking at implementing a server for the protocol in RFC 3576, and I
have a few questions regarding the "Authorize-only" Service-type.
I have looked through the archives for this list, and have also browsed RFC
2865 and 4005, in trying to find answers.
RFC 3576 requires a conforming implementation to respond to a DM or CoA
request with Service-type Authoize-only with a NAK to the Initial Request,
followed by a RADIUS Access-request. I understand from the description in
RFC 3576 that this Access-request is meant to trigger a "reauthorization".
I am trying to understand this part of the protocol, in the case where the
Initial request is generated from a Radius server, as opposed to a
Radius/Diameter gateway.
I have these two general questions:
1a. What is the usage scenario for this feature, from a network management
perspective ?
I know the RFC says that "This enables a usage model akin to that supported
in Diameter, thus easing translation between the two protocols". but I am
not so familiar with Diameter, and I do not understand what the need is for
this feature - is this strictly for forward compatibility with Diameter ?
1b. What is the usage scenario, with radius servers ? (This may be the same
question from another perspective, but in case it isn't) :
From the point of view of someone wanting to enhance a radius server, what
is the need or attraction for implementing/issuing the "Authorize-only"
requests within this protocol ?
2. The RFC states that the Radius Access-request is to be sent by the
RFC3576 Server. Implicit in this is that the RFC3576 server will get a
response - is it expected to act on that response message ?
Can the sending of the Access Request be performed by a different server
process, or must the Request come from the same process (or port) that
received the initial Authorize-only request, and that issued the NAK ? In
other words, is the Radius Server maintaining some sort of state between the
two messages ?
I also have 2 specific technical questions
1. I have assumed that the values for the Attributes are to be taken from
RFC 2865, yet in that RFC, "Service-type" has defined the value
"Authenticate-only", not "Authorize-only"
2. Regarding permitted attributes, the paragraph at the top of page 13 says:
Where a Service-Type Attribute with value "Authorize Only" is
included within a CoA-Request or Disconnect-Request, attributes
representing an authorization change MUST NOT be included; only
identification attributes are permitted. If attributes other than
NAS or session identification attributes are included in such a CoA-
Request, implementations MUST send a CoA-NAK;
My interpretation of this statement is that only the (3) "NAS identification
attributes" and (12) "Session identification attributes", as listed at the
start of section 3, MAY be in the message. However that interpretation
excludes Service-type (trivial) and State (less trivial - see [Note 7] ).
Have I misinterpreted the paragraph, or are those actually the exceptions ?
[Bernard Aboba]
RFC 3576 Section 4 allocates the "Authorize-Only" Service-Type value.
My take is that a State attribute is permited in a CoA/Disconnect-Request
with Service-Type=Authorize-Only", and in fact RFC 2865 Section 4.1 suggests
that it is required:
An Access-Request MUST contain either a User-Password or a CHAP-
Password or a State.
The RFC 3576 "Authorize-Only" Service-Type was originally created for the
purpose of Diameter compatibility. However, Diameter compatibility issues
only arise with the CoA-Request, and never with the Disconnect-Request. This
is because a Disconnect-Request can always be handled as a single
request/response sequence either in Diameter or RADIUS so it should never be
necessary to include a Service-Type="Authorize-Only" within a
Disconnect-Request.
Since a Diameter disconnect request will always generate an immediate
response, and never another access request, including
Service-Type="Authorize-Only" in a RADIUS Disconnect-Request can cause
problems with Diameter compatibility, rather than enhancing it.
There are situations in which include a Service-Type="Authorize-Only"
attribute in a RADIUS CoA-Request makes sense. This can happen in situations
where it is necessary to change an attribute which could potentially be
interpretted as a session identification attribute. This is the "semantic
ambiguity" problem described in RFC 3576. There are also situations in which
this is needed for Diameter compatibility. For example, if there is a RADIUS
client/NAS interacting with a Diameter Server, then it is possible that a
Diameter change-of-authorization request will not be easily translatable to
a standard RADIUS CoA-Request without use of Service-Type="Authorize-Only".
A number of issues can arise with respect to processing of an
"Authorize-Only" Disconnect or CoA-Request:
a. Which RADIUS server to respond to. While the CoA-NAK needs to be sent to
the entity that sent the CoA-Request, it is not entirely clear who the
Access-Request is to be sent to. A RADIUS client is typically configured
with one or more RADIUS servers, but the CoA-Request might have been sent by
a different entity. As a result, it is possible that the Access-Request will
go to a different server than the one that sent the CoA-Request.
b. Security problems. The RFC 2865 Section 4.1 text suggests that RADIUS
requires Access-Request messages to contain either an authentication
attribute or a state attribute. Since "Authorize-Only" messages do not
contain an authentication attribute, the only alternative is to include a
State attribute, which presumably needs to be obtained from the CoA or
Disconnect-Request. This is why I believe that the State attribute needs to
be allowed; there may even by RADIUS servers that will reject the
Access-Request unless it is included.
However, since the State attribute typically can only be interpretted
locally, it may not be interprettable by a server other than the one that
originated the CoA or Disconnect-Request, so if the Access-Request goes to a
different server interoperability problems can result.
Therefore while there is no RFC 3576 requirement that the same process
generating the Disconnect or CoA-NAK also generate the Access-Request, this
might in fact be a good idea, since it could help guarantee that the
Access-Request goes back to the same entity that sent the
CoA/Disconnect-Request.
--
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/>