Subject: (radius) Implementation survey, part II

From: Carl Rigney <[email-masked]>
Date: Tue, 2 Feb 1999 17:13:43 -0800 (PST)

Please fill this out and return it to [email-masked] by February
8th, 5pm PST.

For RADIUS to advance to Proposed Standard, every feature must have at
least two independent implementations, or must be cut from the draft.
I'm putting together the document on that.  I already have the email
everyone sent me in November mentioning their implementations, and now
I'm ready for the feature lists.  Please read these directions
carefully and email your answers to me directly, not to the list.

I only need a reply to this if your implementation is INDEPENDENT, that
is, not based on Livingston's original RADIUS 1.3, 1.13 or 1.16
server.  If you started out once upon a time with our server and
eventually replaced all our code with fresh code, that counts as
independent.  If you did your implementation from scratch, better yet.

Please fill out the Organization, Product and Version fields following
their colons, and mark the features with a Y or N *before* the feature,
and keep the spelling and order exactly as they are here (so I can
automate processing the results). Lines starting with __ are headers
and should not be marked.

Y means you support that feature in your RADIUS server NOW, N means you
do not.  No fair saying you'll be adding it later, it has to be in your
implementation that's already done and being used somewhere, although
beta or experimental software counts as in use, as long as its actually
running.

Note that not all values of a given attribute need to be supported, if
your NAS only supports PPP but not SLIP, that still counts as supporting
Framed-Protocol.

If you make both a server and a NAS, please send in two submissions
(as two seperate email messages), one for each.  If you make different
flavors of NAS but they have the same RADIUS client, you only need to
send me an entry for one flavor of NAS.

Note that Accounting is informational so its attributes are not
listed here, but the Accounting packet codes *are* included in the
RADIUS RFC, so they are listed here.

Company name:
Product Name:
Product Version:

__ Proxy supported:
Server can forward an access-request to another RADIUS server
Server can receive an access-accept, reject, or challenge and forward to a RADIUS client
Server copies all Proxy-States from request to response when replying to request
Server strips its own Proxy-State from response before forwarding to client

__Packet Types supported:
Access-Request
Access-Accept
Access-Reject
Access-Challenge
Accounting-Request
Accounting-Response

__ Attributes supported:
User-Name
User-Password up to 16 characters long
User-Password up to 128 characters long (encrypted as described in RFC 2138)
CHAP-Password
NAS-IP-Address
NAS-Port
Service-Type
Framed-Protocol
Framed-IP-Address
Framed-IP-Netmask
Framed-Routing
Filter-Id
Framed-MTU
Framed-Compression
Login-IP-Host
Login-Service
Login-TCP-Port
Reply-Message
Callback-Number
Callback-Id
Framed-Route
Framed-IPX-Network
State
Class (for a Client this means it sends Class from access-accepts in its accounting-requests
Vendor-Specific
Session-Timeout
Idle-Timeout
Termination-Action
Called-Station-Id
Calling-Station-Id
NAS-Identifier
Proxy-State
Login-LAT-Service
Login-LAT-Node
Login-LAT-Group
Framed-AppleTalk-Link
Framed-AppleTalk-Network
Framed-AppleTalk-Zone
CHAP-Challenge
NAS-Port-Type
Port-Limit
Login-LAT-Port

__ Features supported:
Identifier (in packet header)
Request Authenticator
Response Authenticator
Challenge Response
Supports PAP
Supports CHAP

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.