Re: Potential work items

["Mike Bean" <bean@lucent.com>]

We have code in our RADIUS server that parses many structured RADIUS
attribute types, some RFC, most VSA.  Usually this parsing is done so that
we can make a decision based on the data contained in the sub-fields or so
that internals of the value type can be read easily in logs or output files.
Unless an attribute is protected by some security association between two
RADIUS servers, the values can be marked as string in the RADIUS dictionary
and be passed through a RADIUS proxy server as "opaque" values.  If the
attribute is encrypted based on the shared secret between a RADIUS client
and server, then hopefully the attribute is encrypted using the method used
for tunnel-password so proxy servers can re-encrypt.  The assumption is most
RADIUS servers can mark an attribute as type tunnel-password in their
dictionary.  We had to add special support to proxy Cisco-AVPairs containing
session keys because of a non-standard encryption scheme.

I understand that this group does not want to add new attribute types to the
RADIUS standard; however, since 3GPP2 standards have been adopted and
require RADIUS support for sub-type values, it may be helpful to write an
informational RFC that describes the use of sub-types in a RADIUS attribute.
Sure most of these attributes are for accounting and only a billing server
needs to understand them; however, they are still carried in RADIUS packets.
Perhaps IS-835 and IS-878 can be changed to flatten these sub-type
attributes into separate attributes.  My concern is it may be too late and
providing additional information on how sub-type attributes are used can
only help developers.  I suspect most vendors supporting 3GPP2 in their
RADIUS server have already written code to support at least the display of
sub-type attributes.  My two cents.

Here an example of a sub-type definition from our XML based dictionary:

<attribute name="3GPP2-PrePaid-Acct-Quota" vendor="3GPP2" code="90"
type="cdma-group">
  <subattribute name="Quota-ID" code="1" type="integer" />
  <subattribute name="Volume-Quota" code="2" type="integer" />
  <subattribute name="Volume-Quota-Overflow" code="3" type="short" />
  <subattribute name="Volume-Threshold" code="4" type="integer" />
  <subattribute name="Volume-Threshold-Overflow" code="5" type="short" />
  <subattribute name="Duration-Quota" code="6" type="integer" />
  <subattribute name="Duration-Quota-Overflow" code="7" type="short" />
  <subattribute name="Update-Reason" code="8" type="short-enumeration">
    <value name="Pre-initialization" code="1" />
    <value name="Initial-Request" code="2" />
    <value name="Threshold-Reached" code="3" />
    <value name="Quota-Reached" code="4" />
    <value name="Remote-Forced-Disconnect" code="5" />
    <value name="Client-Service-Termination" code="6" />
    <value name="Main-Service-Instance-Released" code="7" />
    <value name="Service-Instance-Not-Established" code="8" />
  </subattribute>
  <subattribute name="Volume-Used-ATS" code="9" type="integer" />
  <subattribute name="Volume-Used-ATS-Overflow" code="10" type="short" />
  <subattribute name="Tariff-Switch-Interval" code="11" type="integer" />
  <subattribute name="PrePaid-Server-Address" code="12" type="ip-address" />
</attribute>

Mike Bean
NavisRadius Product Group
Lucent Technologies

----- Original Message ----- 
From: "Nelson, David" <dnelson@enterasys.com>
To: "Avi Lior" <avi@bridgewatersystems.com>; <radiusext@ops.ietf.org>
Sent: Thursday, January 08, 2004 11:09 AM
Subject: RE: Potential work items


Avi Lior writes...

> Great!!! I was saying that all along.  Prepaid is exactly that so is
the
> Sterman draft.
> Both of these are add on applications.  They both need specialized
code in
> the RADIUS server to perform their Authentication/Authorization.

My ears prick up when you say "code in the RADIUS server".  If you mean
a separate application (or service) running on the same host as the
RADIUS Server application, and communicating tot eh RADIUS Server via
some API, then fine.

If you mean that the code is integral to the RADIUS Server application
and the parser code that understands RADIUS attributes also needs to
understand the "opaque" messages, then maybe not so fine.

If the "opaque" message format is not documented as part of, or an
extension to, RADIUS or Diameter, then it follows the EAP precedent.

-- Dave




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


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