[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 161: Authorize-Only Service-Type
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.
============================================================
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 ?
--
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/>