Re: [RADIUS FIXES] Authorize Only / RADIUS layering

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Hi,

On Thu, Jul 28, 2005 at 11:38:37AM +0300, Pasi.Eronen@nokia.com wrote:

> David Nelson wrote:
> > 
> > So, let me take a moment to address RADIUS layering in a
> > pro-active fashion.
> > 
> > It is certainly appropriate to have layering of one
> > application upon the services provided by another.  We need to
> > address this general architectural concept within the
> > constraints of RADIUS as it exists, and the charter of the
> > RADEXT WG.
> > 
> > RADEXT is not chartered to make major or substantial
> > architectural changes to RADIUS.  For example, introducing
> > layering akin to the base / application layering in Diameter
> > is certainly out of scope.
> > 
> > It would, generally speaking, be appropriate for RADEXT to
> > consider standardization of new attributes for the
> > provisioning of existing, well-defined services that exist on
> > the NAS.  Traditionally, these attributes have used the data
> > types defined in RFC 2865 and have been transparent to the
> > RADIUS protocol engines, in both clients and servers.  The
> > vast majority of existing RADIUS attributes is acted upon by
> > application layer software outside the scope of the RADIUS
> > protocol engine, and its associated support and management
> > components. So layering does already exist, to this extent.
> 
> This is an interesting and pretty accurate observation. Current
> RADIUS documents are mostly concerned with how attributes are
> transported from one place to another (and how multiple
> attribute packed to a single message are separated). How the
> attributes are acted upon (what they mean, or what their
> semantics are) is largely unspecified in IETF RADIUS documents.

And I would say that that is a good thing. I'm not saying that the lack
of standardization of the application layer is a good thing, but I don't
think that each application should be standardized in IETF RADIUS
protocol documents.

> > The specific practice that I'm suggesting is undesirable is
> > the definition of new RADIUS attributes, and their basic
> > semantic descriptions, in RFCs defining the applications,
> > rather than in [companion] RADIUS extensions RFCs.  That does
> > not mean that the I-Ds for such RADIUS extensions need to be
> > work items for the RADEXT WG.  They could be work items for
> > other IETF WGs (or conceptually even other SDOs), with
> > concurrent review and WG Last Calls in RADEXT and the other
> > WG(s).  In any event, the collection of IETF standard
> > attributes (anything other than VSAs) should be treated as a
> > consistent body of work, and be considered as elements of the
> > RADIUS protocol.
> > 
> > RADIUS does not have a formal language that would allow the
> > independent publication of data objects, much as we have MIBs
> > for SNMP and PIBs for COPS.
> 
> This is where I disagree to some extent. I think the current
> practice of defining only the syntax of RADIUS attributes, but
> not the semantics, is very undesirable. One possible way to
> avoid this is to define the syntax and the semantics in the 
> same document...

Generally, if the functioning of a lower layer does not depend on the
functioning of an upper layer (eg. IP can work without TCP being
implemented), then the upper layer should not be documented in the lower
layer's standard, other than as an example.

I think that that this also often goes for the separation of syntax of
an attribute (32-bit unsigned, optional in access accepts), and the
semantics of each possible value.

> And IMHO we don't need a formal language, since all it could
> do is describing the syntactic parts (e.g., this attribute can
> be included only in Access-Accept messages, and contains a
> 32-bit integer). I don't currently see big problems in this 
> area; the problem is that documentation doesn't describe
> how the attributes are acted upon.

If an attribute is and will only useful in one situation, I would not
object to adding more detail about the attribute's possible contents in
the document that defines the attribute's existence.

However, if the attribute and the rules governing its existence are
useful in other situations as well, then I would strongly suggest to
leave any constraints on contents to application level documents.

> If we are concerned with interoperability of whole RADIUS
> clients and servers, rather than just "RADIUS protocol engines",
> the endpoints need to agree on those semantics, too. Currently
> that is pretty much left to implementation folklore (in the
> worst case) or documents by other SDOs (in the best case).
> 
> I think Avi's example of using "Authorize Only" for replenishing
> prepaid quota is a good example of this. The syntax of the
> attributes is defined in IETF specs, but actual interoperability
> requires some agreement of how the messages are acted upon that
> not's specified in any IETF document. (I'm not sure if it's
> specified in any document, in fact...)

I have often implemented prepaid schemes using only existing RADIUS
attributes (Session-Timeout, Acct-Session-Time, Acct-Terminate-Cause,
Idle-Timeout). This implementation requires only bog standard behaviour
from NASes, proxies, and the protocol engine on the server; only some
custom logic and database is required on top of the server. (And in
OpenRADIUS, that custom logic is purely a run time issue, not a code
thing).

Because prepaid is often an unilateral process as far as data on the
wire is concerned (it only affects logic and state at the service
provider), it may not even require IETF standardization. It's just an
issue of completeness, robustness and price between the logic/database
vendor and the service provider.

But because there are quite a number of subtleties involved in the use
of those standard attributes for this purpose, it would perhaps be a
good candidate for an informational application level RFC showing best
practice in the use of RADIUS and certain existing RADIUS attributes to
build a prepaid service.

And to address Authorize-Only: if replenishing of quota during a session
must be able extend the end of a session without any interruption of
service, then the required NAS behaviour and server logic at
reauthentication time can still be detailed in an application level
document, especially because the issue of fast reauthentications can
very well be solved above the RADIUS protocol level.

(A NAS can eg. perform reauthentication 5 seconds before the end of
the session, and/or use more lightweight credentials that securely refer
to the earlier authentication, and so on. See eg. TLS, and the EAP types
that use it in some way).

If Authorize-Only would be the only available flag to trigger the
applicable logic above the RADIUS protocol level, ie. the EAP type has
no way to determine whether an authentication is actually about an
existing session for caching purposes, then perhaps Authorize-Only is
needed. Otherwise, I see no point in it, and I'm a bit nervous about a
RADIUS server returning a users' authorization profile in response to a
request that does not contain that full redentials (or at least a secure
reference to an earlier authentication).

Let's keep in mind that an 'authentication' in RADIUS speak is only a
simple request/response transaction. A database lookup through a bit of
logic. If a lightweight subsequent RADIUS 'authentication' is done to
verify whether an existing session that's about to end may be continued,
then at the protocol level, that's a normal RADIUS authentication. Only
the database and an EAP type need be concerned. And those are
application level issues as far as I'm concerned.

RADIUS per se has no concept of sessions, only of authentications with
authorizations as responses. That the logic behind RADIUS may keep
session state by combining authentications with accounting or earlier
authentications in lots of funky ways is not a RADIUS issue, but a
RADIUS application issue.

Session state is not required in the core of a RADIUS server now, and it
should not be required later.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

--
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/>