[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Ruby Radius Dictionary

Felix Windt

10/27/2007 12:08:00 PM

> -----Original Message-----
> From: list-bounce@example.com
> [mailto:list-bounce@example.com] On Behalf Of Aby azid Abu bakar
> Sent: Friday, October 26, 2007 7:31 PM
> To: ruby-talk ML
> Subject: Re: Ruby Radius Dictionary
>
> I'm still new with radius protocol. Does the dictionary in
> radius client
> have to be the same as dictionary in Radius Server?. I
> checked packet.rb
> and found comment that the coding is referring to RFC 2138. The
> dictionary in the Radius server is following the RFC 2865.
> Could this be
> the problem?
>
> Thanks
>
> --
> Posted via http://www.ruby-....

This is how dictionaries work:

A RADIUS packet is made up of a header and a payload. The header has the
following structure:
[ Code - 1 Octet ][ Identifier - 1 Octet ][ Length - 2 Octets ][
Authenticator - 16 Octets ]

Where the code is one of 1 - Access-Request, 2 - Access-Accept, 3 -
Access-Reject, 4 - Accounting-Request, 5 - Accounting-Reponse, 11
Access-Challenge and distinguishes the type of RADIUS packet.
The Identifier is used to perform threading and link initial requests and
subsequest replies.
The Length is the sum of all fields in the packet (much be between 20 and
4096 octets. According to spec, longer messages get trimmed at 4096, shorter
ones are thrown away.
The Authenticator region is used differently depending on whether the type
is a request or a responose and contains either completely random data, or
calculated using MD5 hashes on the value of the code, identifier, length and
request-authenticator random payload, followed by packet payload and shared
secret.

The header is followed by the payload, where each attribute and value are
transmitted as such:
[ Number - 1 Octet ][ Length - > 3 ][ Value - dependent on attribute number
]

The Number is between 1 and 255 and is what gets translated by the
dictionary. For example, Attribute-Number 39 is translated to
"Framed-AppleTalk-Zone" in the standard dictionaries, so that you can refer
to it as such instead of using the number.
The Length is the length of the attribute-value pair, and must be larger
than 3 (1 octet for the Number, 1 octet for the Length, 1 octet for the
value)
The Value is dependent on the attribute name in that the dictionary also
specifies the type of value. An abbribute number is mapped to one of:
Integer (INT) (4 Octets, 32-bit unsigned)
Enumerated (ENUM) (4 Octets, 32-bit unsigned)
IP Address (IPADDR) (4 Octets, 32 bit)
Character String (STRING) (1-253 Octets, variable)
Date (DATE) (4 Octets, 32-bit unsigned)
Binary (BINARY) (1 bit)

So a dictionary entry such as
1 User-Name STRING

Signifies that Attribute Number 1 can be referred to as 'User-Name' and
carries as a value a string between 1 and 253 octets in length.

Since that means there can only be 255 higher order RADIUS attributes, there
is also the special case of vvendor-specific attributes (VSAs). They have
the Attribute-Number 26 and a payload consisting of:
[ ID - 4 octets ][ Number - 1 Octet ][ Length > 7 ][ Value - dependent on
attribute number ]

Which essentially behaves much like an attribute/value pair wrapped in an
attribute/value pair, adding a field for the Vendor ID. The vendor ID is
coded using NMPECs in network byte ordering and is unique to the vendor, and
again described by an entry in a dictionary.



So therefore, client and server _strictly_ speaking do not need to implement
identical dictionaries, in that they can be free to change values in the
second column of format ("Attribute-Number", "Human-Readable String", "Value
Kind") so that the client can refer to Attribute-Number 1 as 'User-Name'
while the server refers to it as 'Username'. They do, however, usually need
to have dictionary entries to be able to refer to the fields in some way. If
your server is sending packets with AV-pairs that your client does not have
dictionaries for, you'd have to go to a very low level to interpret them on
byte level instead of being able to use the Ruby interface, which deals with
the pairs once they're translated from the dictionary.

Hope that helps,

Felix