additional documentation

7 files changed, 17493 insertions, 0 deletions

diff --git a/doc/rfc2138.txt b/doc/rfc2138.txt
new file mode 100644
index 0000000..9f4a86d
--- /dev/null
+++ b/doc/rfc2138.txt
@@ -0,0 +1,3643 @@
+
+
+
+
+
+
+Network Working Group                                          C. Rigney
+Request for Comments: 2138                                    Livingston
+Obsoletes: 2058                                                A. Rubens
+Category: Standards Track                                          Merit
+                                                              W. Simpson
+                                                              Daydreamer
+                                                              S. Willens
+                                                              Livingston
+                                                              April 1997
+
+
+          Remote Authentication Dial In User Service (RADIUS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes a protocol for carrying authentication,
+   authorization, and configuration information between a Network Access
+   Server which desires to authenticate its links and a shared
+   Authentication Server.
+
+Implementation Note
+
+   This memo documents the RADIUS protocol.  There has been some
+   confusion in the assignment of port numbers for this protocol.  The
+   early deployment of RADIUS was done using the erroneously chosen port
+   number 1645, which conflicts with the "datametrics" service.  The
+   officially assigned port number for RADIUS is 1812.
+
+Table of Contents
+
+   1.     Introduction ..........................................    3
+      1.1       Specification of Requirements ...................    4
+      1.2       Terminology .....................................    5
+   2.     Operation .............................................    5
+      2.1       Challenge/Response ..............................    7
+      2.2       Interoperation with PAP and CHAP ................    7
+      2.3       Why UDP? ........................................    8
+   3.     Packet Format .........................................   10
+   4.     Packet Types ..........................................   13
+      4.1       Access-Request ..................................   13
+
+
+
+Rigney, et. al.             Standards Track                     [Page 1]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      4.2       Access-Accept ...................................   14
+      4.3       Access-Reject ...................................   15
+      4.4       Access-Challenge ................................   17
+   5.     Attributes ............................................   18
+      5.1       User-Name .......................................   21
+      5.2       User-Password ...................................   22
+      5.3       CHAP-Password ...................................   23
+      5.4       NAS-IP-Address ..................................   24
+      5.5       NAS-Port ........................................   25
+      5.6       Service-Type ....................................   26
+      5.7       Framed-Protocol .................................   28
+      5.8       Framed-IP-Address ...............................   29
+      5.9       Framed-IP-Netmask ...............................   29
+      5.10      Framed-Routing ..................................   30
+      5.11      Filter-Id .......................................   31
+      5.12      Framed-MTU ......................................   32
+      5.13      Framed-Compression ..............................   33
+      5.14      Login-IP-Host ...................................   33
+      5.15      Login-Service ...................................   34
+      5.16      Login-TCP-Port ..................................   35
+      5.17      (unassigned) ....................................   36
+      5.18      Reply-Message ...................................   36
+      5.19      Callback-Number .................................   37
+      5.20      Callback-Id .....................................   38
+      5.21      (unassigned) ....................................   38
+      5.22      Framed-Route ....................................   39
+      5.23      Framed-IPX-Network ..............................   40
+      5.24      State ...........................................   40
+      5.25      Class ...........................................   41
+      5.26      Vendor-Specific .................................   42
+      5.27      Session-Timeout .................................   44
+      5.28      Idle-Timeout ....................................   44
+      5.29      Termination-Action ..............................   45
+      5.30      Called-Station-Id ...............................   46
+      5.31      Calling-Station-Id ..............................   47
+      5.32      NAS-Identifier ..................................   48
+      5.33      Proxy-State .....................................   48
+      5.34      Login-LAT-Service ...............................   49
+      5.35      Login-LAT-Node ..................................   50
+      5.36      Login-LAT-Group .................................   51
+      5.37      Framed-AppleTalk-Link ...........................   52
+      5.38      Framed-AppleTalk-Network ........................   53
+      5.39      Framed-AppleTalk-Zone ...........................   54
+      5.40      CHAP-Challenge ..................................   55
+      5.41      NAS-Port-Type ...................................   55
+      5.42      Port-Limit ......................................   56
+      5.43      Login-LAT-Port ..................................   57
+      5.44      Table of Attributes .............................   58
+
+
+
+Rigney, et. al.             Standards Track                     [Page 2]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   6.     Examples ..............................................   59
+      6.1       User Telnet to Specified Host ...................   60
+      6.2       Framed User Authenticating with CHAP ............   60
+      6.3       User with Challenge-Response card ...............   61
+   Security Considerations ......................................   63
+   References ...................................................   64
+   Acknowledgements .............................................   64
+   Chair's Address ..............................................   65
+   Author's Addresses ...........................................   65
+
+1.  Introduction
+
+   Managing dispersed serial line and modem pools for large numbers of
+   users can create the need for significant administrative support.
+   Since modem pools are by definition a link to the outside world, they
+   require careful attention to security, authorization and accounting.
+   This can be best achieved by managing a single "database" of users,
+   which allows for authentication (verifying user name and password) as
+   well as configuration information detailing the type of service to
+   deliver to the user (for example, SLIP, PPP, telnet, rlogin).
+
+   Key features of RADIUS are:
+
+   Client/Server Model
+
+      A Network Access Server (NAS) operates as a client of RADIUS.  The
+      client is responsible for passing user information to designated
+      RADIUS servers, and then acting on the response which is returned.
+
+      RADIUS servers are responsible for receiving user connection
+      requests, authenticating the user, and then returning all
+      configuration information necessary for the client to deliver
+      service to the user.
+
+      A RADIUS server can act as a proxy client to other RADIUS servers
+      or other kinds of authentication servers.
+
+   Network Security
+
+      Transactions between the client and RADIUS server are
+      authenticated through the use of a shared secret, which is never
+      sent over the network.  In addition, any user passwords are sent
+      encrypted between the client and RADIUS server, to eliminate the
+      possibility that someone snooping on an unsecure network could
+      determine a user's password.
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                     [Page 3]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   Flexible Authentication Mechanisms
+
+      The RADIUS server can support a variety of methods to authenticate
+      a user.  When it is provided with the user name and original
+      password given by the user, it can support PPP PAP or CHAP, UNIX
+      login, and other authentication mechanisms.
+
+   Extensible Protocol
+
+      All transactions are comprised of variable length Attribute-
+      Length-Value 3-tuples.  New attribute values can be added without
+      disturbing existing implementations of the protocol.
+
+1.1.  Specification of Requirements
+
+   In this document, several words are used to signify the requirements
+   of the specification.  These words are often capitalized.
+
+   MUST      This word, or the adjective "required", means that the
+             definition is an absolute requirement of the specification.
+
+   MUST NOT  This phrase means that the definition is an absolute
+             prohibition of the specification.
+
+   SHOULD    This word, or the adjective "recommended", means that there
+             may exist valid reasons in particular circumstances to
+             ignore this item, but the full implications must be
+             understood and carefully weighed before choosing a
+             different course.
+
+   MAY       This word, or the adjective "optional", means that this
+             item is one of an allowed set of alternatives.  An
+             implementation which does not include this option MUST be
+             prepared to interoperate with another implementation which
+             does include the option.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                     [Page 4]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+1.2.  Terminology
+
+   This document frequently uses the following terms:
+
+   service   The NAS provides a service to the dial-in user, such as PPP
+             or Telnet.
+
+   session   Each service provided by the NAS to a dial-in user
+             constitutes a session, with the beginning of the session
+             defined as the point where service is first provided and
+             the end of the session defined as the point where service
+             is ended.  A user may have multiple sessions in parallel or
+             series if the NAS supports that.
+
+   silently discard
+             This means the implementation discards the packet without
+             further processing.  The implementation SHOULD provide the
+             capability of logging the error, including the contents of
+             the silently discarded packet, and SHOULD record the event
+             in a statistics counter.
+
+2.  Operation
+
+   When a client is configured to use RADIUS, any user of the client
+   presents authentication information to the client.  This might be
+   with a customizable login prompt, where the user is expected to enter
+   their username and password.  Alternatively, the user might use a
+   link framing protocol such as the Point-to-Point Protocol (PPP),
+   which has authentication packets which carry this information.
+
+   Once the client has obtained such information, it may choose to
+   authenticate using RADIUS.  To do so, the client creates an "Access-
+   Request" containing such Attributes as the user's name, the user's
+   password, the ID of the client and the Port ID which the user is
+   accessing.  When a password is present, it is hidden using a method
+   based on the RSA Message Digest Algorithm MD5 [1].
+
+   The Access-Request is submitted to the RADIUS server via the network.
+   If no response is returned within a length of time, the request is
+   re-sent a number of times.  The client can also forward requests to
+   an alternate server or servers in the event that the primary server
+   is down or unreachable.  An alternate server can be used either after
+   a number of tries to the primary server fail, or in a round-robin
+   fashion.  Retry and fallback algorithms are the topic of current
+   research and are not specified in detail in this document.
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                     [Page 5]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   Once the RADIUS server receives the request, it validates the sending
+   client.  A request from a client for which the RADIUS server does not
+   have a shared secret should be silently discarded.  If the client is
+   valid, the RADIUS server consults a database of users to find the
+   user whose name matches the request.  The user entry in the database
+   contains a list of requirements which must be met to allow access for
+   the user.  This always includes verification of the password, but can
+   also specify the client(s) or port(s) to which the user is allowed
+   access.
+
+   The RADIUS server MAY make requests of other servers in order to
+   satisfy the request, in which case it acts as a client.
+
+   If any condition is not met, the RADIUS server sends an "Access-
+   Reject" response indicating that this user request is invalid.  If
+   desired, the server MAY include a text message in the Access-Reject
+   which MAY be displayed by the client to the user.  No other
+   Attributes are permitted in an Access-Reject.
+
+   If all conditions are met and the RADIUS server wishes to issue a
+   challenge to which the user must respond, the RADIUS server sends an
+   "Access-Challenge" response.  It MAY include a text message to be
+   displayed by the client to the user prompting for a response to the
+   challenge, and MAY include a State attribute.  If the client receives
+   an Access-Challenge and supports challenge/response it MAY display
+   the text message, if any, to the user, and then prompt the user for a
+   response.  The client then re-submits its original Access-Request
+   with a new request ID, with the User-Password Attribute replaced by
+   the response (encrypted), and including the State Attribute from the
+   Access-Challenge, if any.  Only 0 or 1 instances of the State
+   Attributes should be present in a request.  The server can respond to
+   this new Access-Request with either an Access-Accept, an Access-
+   Reject, or another Access-Challenge.
+
+   If all conditions are met, the list of configuration values for the
+   user are placed into an "Access-Accept" response.  These values
+   include the type of service (for example: SLIP, PPP, Login User) and
+   all necessary values to deliver the desired service.  For SLIP and
+   PPP, this may include values such as IP address, subnet mask, MTU,
+   desired compression, and desired packet filter identifiers.  For
+   character mode users, this may include values such as desired
+   protocol and host.
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                     [Page 6]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+2.1.  Challenge/Response
+
+   In challenge/response authentication, the user is given an
+   unpredictable number and challenged to encrypt it and give back the
+   result. Authorized users are equipped with special devices such as
+   smart cards or software that facilitate calculation of the correct
+   response with ease. Unauthorized users, lacking the appropriate
+   device or software and lacking knowledge of the secret key necessary
+   to emulate such a device or software, can only guess at the response.
+
+   The Access-Challenge packet typically contains a Reply-Message
+   including a challenge to be displayed to the user, such as a numeric
+   value unlikely ever to be repeated. Typically this is obtained from
+   an external server that knows what type of authenticator should be in
+   the possession of the authorized user and can therefore choose a
+   random or non-repeating pseudorandom number of an appropriate radix
+   and length.
+
+   The user then enters the challenge into his device (or software) and
+   it calculates a response, which the user enters into the client which
+   forwards it to the RADIUS server via a second Access-Request.  If the
+   response matches the expected response the RADIUS server replies with
+   an Access-Accept, otherwise an Access-Reject.
+
+   Example: The NAS sends an Access-Request packet to the RADIUS Server
+   with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
+   just be a fixed string like "challenge" or ignored).  The server
+   sends back an Access-Challenge packet with State and a Reply-Message
+   along the lines of "Challenge 12345678, enter your response at the
+   prompt" which the NAS displays.  The NAS prompts for the response and
+   sends a NEW Access-Request to the server (with a new ID) with NAS-
+   Identifier, NAS-Port, User-Name, User-Password (the response just
+   entered by the user, encrypted), and the same State Attribute that
+   came with the Access-Challenge.  The server then sends back either an
+   Access-Accept or Access-Reject based on whether the response matches
+   what it should be, or it can even send another Access-Challenge.
+
+2.2.  Interoperation with PAP and CHAP
+
+   For PAP, the NAS takes the PAP ID and password and sends them in an
+   Access-Request packet as the User-Name and User-Password. The NAS MAY
+   include the Attributes Service-Type = Framed-User and Framed-Protocol
+   = PPP as a hint to the RADIUS server that PPP service is expected.
+
+   For CHAP, the NAS generates a random challenge (preferably 16 octets)
+   and sends it to the user, who returns a CHAP response along with a
+   CHAP ID and CHAP username.  The NAS then sends an Access-Request
+   packet to the RADIUS server with the CHAP username as the User-Name
+
+
+
+Rigney, et. al.             Standards Track                     [Page 7]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   and with the CHAP ID and CHAP response as the CHAP-Password
+   (Attribute 3).  The random challenge can either be included in the
+   CHAP-Challenge attribute or, if it is 16 octets long, it can be
+   placed in the Request Authenticator field of the Access-Request
+   packet.  The NAS MAY include the Attributes Service-Type = Framed-
+   User and Framed-Protocol = PPP as a hint to the RADIUS server that
+   PPP service is expected.
+
+   The RADIUS server looks up a password based on the User-Name,
+   encrypts the challenge using MD5 on the CHAP ID octet, that password,
+   and the CHAP challenge (from the CHAP-Challenge attribute if present,
+   otherwise from the Request Authenticator), and compares that result
+   to the CHAP-Password.  If they match, the server sends back an
+   Access-Accept, otherwise it sends back an Access-Reject.
+
+   If the RADIUS server is unable to perform the requested
+   authentication it should return an Access-Reject.  For example, CHAP
+   requires that the user's password be available in cleartext to the
+   server so that it can encrypt the CHAP challenge and compare that to
+   the CHAP response.  If the password is not available in cleartext to
+   the RADIUS server then the server MUST send an Access-Reject to the
+   client.
+
+2.3.  Why UDP?
+
+   A frequently asked question is why RADIUS uses UDP instead of TCP as
+   a transport protocol.  UDP was chosen for strictly technical reasons.
+
+   There are a number of issues which must be understood.  RADIUS is a
+   transaction based protocol which has several interesting
+   characteristics:
+
+   1.   If the request to a primary Authentication server fails, a
+        secondary server must be queried.
+
+         To meet this requirement, a copy of the request must be kept
+         above the transport layer to allow for alternate transmission.
+         This means that retransmission timers are still required.
+
+   2.   The timing requirements of this particular protocol are
+        significantly different than TCP provides.
+
+         At one extreme, RADIUS does not require a "responsive"
+         detection of lost data.  The user is willing to wait several
+         seconds for the authentication to complete.  The generally
+         aggressive TCP retransmission (based on average round trip
+         time) is not required, nor is the acknowledgement overhead of
+         TCP.
+
+
+
+Rigney, et. al.             Standards Track                     [Page 8]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+         At the other extreme, the user is not willing to wait several
+         minutes for authentication.  Therefore the reliable delivery of
+         TCP data two minutes later is not useful.  The faster use of an
+         alternate server allows the user to gain access before giving
+         up.
+
+   3.   The stateless nature of this protocol simplifies the use of UDP.
+
+         Clients and servers come and go.  Systems are rebooted, or are
+         power cycled independently.  Generally this does not cause a
+         problem and with creative timeouts and detection of lost TCP
+         connections, code can be written to handle anomalous events.
+         UDP however completely eliminates any of this special handling.
+         Each client and server can open their UDP transport just once
+         and leave it open through all types of failure events on the
+         network.
+
+   4.   UDP simplifies the server implementation.
+
+         In the earliest implementations of RADIUS, the server was
+         single threaded.  This means that a single request was
+         received, processed, and returned.  This was found to be
+         unmanageable in environments where the back-end security
+         mechanism took real time (1 or more seconds).  The server
+         request queue would fill and in environments where hundreds of
+         people were being authenticated every minute, the request
+         turn-around time increased to longer that users were willing to
+         wait (this was especially severe when a specific lookup in a
+         database or over DNS took 30 or more seconds).  The obvious
+         solution was to make the server multi-threaded.  Achieving this
+         was simple with UDP.  Separate processes were spawned to serve
+         each request and these processes could respond directly to the
+         client NAS with a simple UDP packet to the original transport
+         of the client.
+
+         It's not all a panacea.  As noted, using UDP requires one thing
+         which is built into TCP: with UDP we must artificially manage
+         retransmission timers to the same server, although they don't
+         require the same attention to timing provided by TCP.  This one
+         penalty is a small price to pay for the advantages of UDP in
+         this protocol.
+
+         Without TCP we would still probably be using tin cans connected
+         by string.  But for this particular protocol, UDP is a better
+         choice.
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                     [Page 9]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+3.  Packet Format
+
+   Exactly one RADIUS packet is encapsulated in the UDP Data field [2],
+   where the UDP Destination Port field indicates 1812 (decimal).
+
+   When a reply is generated, the source and destination ports are
+   reversed.
+
+   This memo documents the RADIUS protocol.  There has been some
+   confusion in the assignment of port numbers for this protocol.  The
+   early deployment of RADIUS was done using the erroneously chosen port
+   number 1645, which conflicts with the "datametrics" service.  The
+   officially assigned port number for RADIUS is 1812.
+
+   A summary of the RADIUS data format is shown below.  The fields are
+   transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                         Authenticator                         |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+Code
+
+   The Code field is one octet, and identifies the type of RADIUS
+   packet.  When a packet is received with an invalid Code field, it is
+   silently discarded.
+
+   RADIUS Codes (decimal) are assigned as follows:
+
+        1       Access-Request
+        2       Access-Accept
+        3       Access-Reject
+        4       Accounting-Request
+        5       Accounting-Response
+       11       Access-Challenge
+       12       Status-Server (experimental)
+       13       Status-Client (experimental)
+      255       Reserved
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 10]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   Codes 4 and 5 are covered in the RADIUS Accounting document [9], and
+   are not further mentioned here.  Codes 12 and 13 are reserved for
+   possible use, but are not further mentioned here.
+
+Identifier
+
+   The Identifier field is one octet, and aids in matching requests and
+   replies.
+
+Length
+
+   The Length field is two octets.  It indicates the length of the
+   packet including the Code, Identifier, Length, Authenticator and
+   Attribute fields.  Octets outside the range of the Length field
+   should be treated as padding and should be ignored on reception.  If
+   the packet is shorter than the Length field indicates, it should be
+   silently discarded.  The minimum length is 20 and maximum length is
+   4096.
+
+Authenticator
+
+   The Authenticator field is sixteen (16) octets.  The most significant
+   octet is transmitted first.  This value is used to authenticate the
+   reply from the RADIUS server, and is used in the password hiding
+   algorithm.
+
+Request Authenticator
+
+      In Access-Request Packets, the Authenticator value is a 16 octet
+      random number, called the Request Authenticator.  The value SHOULD
+      be unpredictable and unique over the lifetime of a secret (the
+      password shared between the client and the RADIUS server), since
+      repetition of a request value in conjunction with the same secret
+      would permit an attacker to reply with a previously intercepted
+      response.  Since it is expected that the same secret MAY be used
+      to authenticate with servers in disparate geographic regions, the
+      Request Authenticator field SHOULD exhibit global and temporal
+      uniqueness.
+
+      The Request Authenticator value in an Access-Request packet SHOULD
+      also be unpredictable, lest an attacker trick a server into
+      responding to a predicted future request, and then use the
+      response to masquerade as that server to a future Access-Request.
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 11]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      Although protocols such as RADIUS are incapable of protecting
+      against theft of an authenticated session via realtime active
+      wiretapping attacks, generation of unique unpredictable requests
+      can protect against a wide range of active attacks against
+      authentication.
+
+      The NAS and RADIUS server share a secret.  That shared secret
+      followed by the Request Authenticator is put through a one-way MD5
+      hash to create a 16 octet digest value which is xored with the
+      password entered by the user, and the xored result placed in the
+      User-Password attribute in the Access-Request packet.  See the
+      entry for User-Password in the section on Attributes for a more
+      detailed description.
+
+   Response Authenticator
+
+      The value of the Authenticator field in Access-Accept, Access-
+      Reject, and Access-Challenge packets is called the Response
+      Authenticator, and contains a one-way MD5 hash calculated over a
+      stream of octets consisting of: the RADIUS packet, beginning with
+      the Code field, including the Identifier, the Length, the Request
+      Authenticator field from the Access-Request packet, and the
+      response Attributes, followed by the shared secret.  That is,
+      ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
+      where + denotes concatenation.
+
+Administrative Note
+
+   The secret (password shared between the client and the RADIUS server)
+   SHOULD be at least as large and unguessable as a well-chosen
+   password.  It is preferred that the secret be at least 16 octets.
+   This is to ensure a sufficiently large range for the secret to
+   provide protection against exhaustive search attacks.  A RADIUS
+   server SHOULD use the source IP address of the RADIUS UDP packet to
+   decide which shared secret to use, so that RADIUS requests can be
+   proxied.
+
+   When using a forwarding proxy, the proxy must be able to alter the
+   packet as it passes through in each direction - when the proxy
+   forwards the request, the proxy can add a Proxy-State Attribute, and
+   when the proxy forwards a response, it removes the Proxy-State
+   Attribute. Since Access-Accept and Access-Reject replies are
+   authenticated on the entire packet contents, the stripping of the
+   Proxy-State attribute would invalidate the signature in the packet -
+   so the proxy has to re-sign it.
+
+   Further details of RADIUS proxy implementation are outside the scope
+   of this document.
+
+
+
+Rigney, et. al.             Standards Track                    [Page 12]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+Attributes
+
+   Many Attributes may have multiple instances, in such a case the order
+   of Attributes of the same Type SHOULD be preserved.  The order of
+   Attributes of different Types is not required to be preserved.
+
+   In the section below on "Attributes" where the text refers to which
+   packets an attribute is allowed in, only packets with Codes 1, 2, 3
+   and 11 and attributes defined in this document are covered in this
+   document.  A summary table is provided at the end of the "Attributes"
+   section.  To determine which Attributes are allowed in packets with
+   codes 4 and 5 refer to the RADIUS Accounting document [9].
+
+4.  Packet Types
+
+   The RADIUS Packet type is determined by the Code field in the first
+   octet of the Packet.
+
+4.1.  Access-Request
+
+   Description
+
+      Access-Request packets are sent to a RADIUS server, and convey
+      information used to determine whether a user is allowed access to
+      a specific NAS, and any special services requested for that user.
+      An implementation wishing to authenticate a user MUST transmit a
+      RADIUS packet with the Code field set to 1 (Access-Request).
+
+      Upon receipt of an Access-Request from a valid client, an
+      appropriate reply MUST be transmitted.
+
+      An Access-Request MUST contain a User-Name attribute.  It SHOULD
+      contain either a NAS-IP-Address attribute or NAS-Identifier
+      attribute (or both, although that is not recommended).  It MUST
+      contain either a User-Password attribute or CHAP-Password
+      attribute.  It SHOULD contain a NAS-Port or NAS-Port-Type
+      attribute or both unless the type of access being requested does
+      not involve a port or the NAS does not distinguish among its
+      ports.
+
+      An Access-Request MAY contain additional attributes as a hint to
+      the server, but the server is not required to honor the hint.
+
+      When a User-Password is present, it is hidden using a method based
+      on the RSA Message Digest Algorithm MD5 [1].
+
+   A summary of the Access-Request packet format is shown below.  The
+   fields are transmitted from left to right.
+
+
+
+Rigney, et. al.             Standards Track                    [Page 13]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Request Authenticator                     |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      1 for Access-Request.
+
+   Identifier
+
+      The Identifier field MUST be changed whenever the content of the
+      Attributes field changes, and whenever a valid reply has been
+      received for a previous request.  For retransmissions, the
+      Identifier MUST remain unchanged.
+
+   Request Authenticator
+
+      The Request Authenticator value MUST be changed each time a new
+      Identifier is used.
+
+   Attributes
+
+      The Attribute field is variable in length, and contains the list
+      of Attributes that are required for the type of service, as well
+      as any desired optional Attributes.
+
+4.2.  Access-Accept
+
+   Description
+
+      Access-Accept packets are sent by the RADIUS server, and provide
+      specific configuration information necessary to begin delivery of
+      service to the user.  If all Attribute values received in an
+      Access-Request are acceptable then the RADIUS implementation MUST
+      transmit a packet with the Code field set to 2 (Access-Accept).
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 14]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      On reception of an Access-Accept, the Identifier field is matched
+      with a pending Access-Request.  Additionally, the Response
+      Authenticator field MUST contain the correct response for the
+      pending Access-Request.  Invalid packets are silently discarded.
+
+   A summary of the Access-Accept packet format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Response Authenticator                    |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      2 for Access-Accept.
+
+   Identifier
+
+      The Identifier field is a copy of the Identifier field of the
+      Access-Request which caused this Access-Accept.
+
+   Response Authenticator
+
+      The Response Authenticator value is calculated from the Access-
+      Request value, as described earlier.
+
+   Attributes
+
+      The Attribute field is variable in length, and contains a list of
+      zero or more Attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 15]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+4.3.  Access-Reject
+
+   Description
+
+      If any value of the received Attributes is not acceptable, then
+      the RADIUS server MUST transmit a packet with the Code field set
+      to 3 (Access-Reject).  It MAY include one or more Reply-Message
+      Attributes with a text message which the NAS MAY display to the
+      user.
+
+   A summary of the Access-Reject packet format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Response Authenticator                    |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      3 for Access-Reject.
+
+   Identifier
+
+      The Identifier field is a copy of the Identifier field of the
+      Access-Request which caused this Access-Reject.
+
+   Response Authenticator
+
+      The Response Authenticator value is calculated from the Access-
+      Request value, as described earlier.
+
+   Attributes
+
+      The Attribute field is variable in length, and contains a list of
+      zero or more Attributes.
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 16]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+4.4.  Access-Challenge
+
+   Description
+
+      If the RADIUS server desires to send the user a challenge
+      requiring a response, then the RADIUS server MUST respond to the
+      Access-Request by transmitting a packet with the Code field set to
+      11 (Access-Challenge).
+
+      The Attributes field MAY have one or more Reply-Message
+      Attributes, and MAY have a single State Attribute, or none.  No
+      other Attributes are permitted in an Access-Challenge.
+
+      On receipt of an Access-Challenge, the Identifier field is matched
+      with a pending Access-Request.  Additionally, the Response
+      Authenticator field MUST contain the correct response for the
+      pending Access-Request.  Invalid packets are silently discarded.
+
+      If the NAS does not support challenge/response, it MUST treat an
+      Access-Challenge as though it had received an Access-Reject
+      instead.
+
+      If the NAS supports challenge/response, receipt of a valid
+      Access-Challenge indicates that a new Access-Request SHOULD be
+      sent.  The NAS MAY display the text message, if any, to the user,
+      and then prompt the user for a response.  It then sends its
+      original Access-Request with a new request ID and Request
+      Authenticator, with the User-Password Attribute replaced by the
+      user's response (encrypted), and including the State Attribute
+      from the Access-Challenge, if any.  Only 0 or 1 instances of the
+      State Attribute can be present in an Access-Request.
+
+      A NAS which supports PAP MAY forward the Reply-Message to the
+      dialin client and accept a PAP response which it can use as though
+      the user had entered the response.  If the NAS cannot do so, it
+      should treat the Access-Challenge as though it had received an
+      Access-Reject instead.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 17]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   A summary of the Access-Challenge packet format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Response Authenticator                    |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      11 for Access-Challenge.
+
+   Identifier
+
+      The Identifier field is a copy of the Identifier field of the
+      Access-Request which caused this Access-Challenge.
+
+   Response Authenticator
+
+      The Response Authenticator value is calculated from the Access-
+      Request value, as described earlier.
+
+   Attributes
+
+      The Attributes field is variable in length, and contains a list of
+      zero or more Attributes.
+
+5.  Attributes
+
+   RADIUS Attributes carry the specific authentication, authorization,
+   information and configuration details for the request and reply.
+
+   Some Attributes MAY be included more than once.  The effect of this
+   is Attribute specific, and is specified in each Attribute
+   description.
+
+   The end of the list of Attributes is indicated by the Length of the
+   RADIUS packet.
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 18]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   A summary of the Attribute format is shown below.  The fields are
+   transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  Value ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      The Type field is one octet.  Up-to-date values of the RADIUS Type
+      field are specified in the most recent "Assigned Numbers" RFC [3].
+      Values 192-223 are reserved for experimental use, values 224-240
+      are reserved for implementation-specific use, and values 241-255
+      are reserved and should not be used.  This specification concerns
+      the following values:
+
+      A RADIUS server MAY ignore Attributes with an unknown Type.
+
+      A RADIUS client MAY ignore Attributes with an unknown Type.
+
+          1      User-Name
+          2      User-Password
+          3      CHAP-Password
+          4      NAS-IP-Address
+          5      NAS-Port
+          6      Service-Type
+          7      Framed-Protocol
+          8      Framed-IP-Address
+          9      Framed-IP-Netmask
+         10      Framed-Routing
+         11      Filter-Id
+         12      Framed-MTU
+         13      Framed-Compression
+         14      Login-IP-Host
+         15      Login-Service
+         16      Login-TCP-Port
+         17      (unassigned)
+         18      Reply-Message
+         19      Callback-Number
+         20      Callback-Id
+         21      (unassigned)
+         22      Framed-Route
+         23      Framed-IPX-Network
+         24      State
+         25      Class
+         26      Vendor-Specific
+
+
+
+Rigney, et. al.             Standards Track                    [Page 19]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+         27      Session-Timeout
+         28      Idle-Timeout
+         29      Termination-Action
+         30      Called-Station-Id
+         31      Calling-Station-Id
+         32      NAS-Identifier
+         33      Proxy-State
+         34      Login-LAT-Service
+         35      Login-LAT-Node
+         36      Login-LAT-Group
+         37      Framed-AppleTalk-Link
+         38      Framed-AppleTalk-Network
+         39      Framed-AppleTalk-Zone
+         40-59   (reserved for accounting)
+         60      CHAP-Challenge
+         61      NAS-Port-Type
+         62      Port-Limit
+         63      Login-LAT-Port
+
+   Length
+
+      The Length field is one octet, and indicates the length of this
+      Attribute including the Type, Length and Value fields.  If an
+      Attribute is received in an Access-Request but with an invalid
+      Length, an Access-Reject SHOULD be transmitted.  If an Attribute
+      is received in an Access-Accept, Access-Reject or Access-Challenge
+      packet with an invalid length, the packet MUST either be treated
+      an Access-Reject or else silently discarded.
+
+   Value
+
+      The Value field is zero or more octets and contains information
+      specific to the Attribute.  The format and length of the Value
+      field is determined by the Type and Length fields.
+
+      Note that a "string" in RADIUS does not require termination by an
+      ASCII NUL because the Attribute already has a length field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 20]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      The format of the value field is one of four data types.
+
+      string    0-253 octets
+
+      address   32 bit value, most significant octet first.
+
+      integer   32 bit value, most significant octet first.
+
+      time      32 bit value, most significant octet first -- seconds
+                since 00:00:00 GMT, January 1, 1970.  The standard
+                Attributes do not use this data type but it is presented
+                here for possible use within Vendor-Specific attributes.
+
+
+5.1.  User-Name
+
+   Description
+
+      This Attribute indicates the name of the user to be authenticated.
+      It is only used in Access-Request packets.
+
+   A summary of the User-Name Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      1 for User-Name.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The NAS may limit the
+      maximum length of the User-Name but the ability to handle at least
+      63 octets is recommended.
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 21]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      The format of the username MAY be one of several forms:
+
+      monolithic Consisting only of alphanumeric characters.  This
+                 simple form might be used to locally manage a NAS.
+
+      simple    Consisting only of printable ASCII characters.
+
+      name@fqdn SMTP address.  The Fully Qualified Domain Name (with or
+                without trailing dot) indicates the realm in which the
+                name part applies.
+
+      distinguished name
+                A name in ASN.1 form used in Public Key authentication
+                systems.
+
+5.2.  User-Password
+
+   Description
+
+      This Attribute indicates the password of the user to be
+      authenticated, or the user's input following an Access-Challenge.
+      It is only used in Access-Request packets.
+
+      On transmission, the password is hidden.  The password is first
+      padded at the end with nulls to a multiple of 16 octets.  A one-
+      way MD5 hash is calculated over a stream of octets consisting of
+      the shared secret followed by the Request Authenticator.  This
+      value is XORed with the first 16 octet segment of the password and
+      placed in the first 16 octets of the String field of the User-
+      Password Attribute.
+
+      If the password is longer than 16 characters, a second one-way MD5
+      hash is calculated over a stream of octets consisting of the
+      shared secret followed by the result of the first xor.  That hash
+      is XORed with the second 16 octet segment of the password and
+      placed in the second 16 octets of the String field of the User-
+      Password Attribute.
+
+      If necessary, this operation is repeated, with each xor result
+      being used along with the shared secret to generate the next hash
+      to xor the next segment of the password, to no more than 128
+      characters.
+
+      The method is taken from the book "Network Security" by Kaufman,
+      Perlman and Speciner [4] pages 109-110.  A more precise
+      explanation of the method follows:
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 22]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      Call the shared secret S and the pseudo-random 128-bit Request
+      Authenticator RA.  Break the password into 16-octet chunks p1, p2,
+      etc.  with the last one padded at the end with nulls to a 16-octet
+      boundary.  Call the ciphertext blocks c(1), c(2), etc.  We'll need
+      intermediate values b1, b2, etc.
+
+         b1 = MD5(S + RA)       c(1) = p1 xor b1
+         b2 = MD5(S + c(1))     c(2) = p2 xor b2
+                .                       .
+                .                       .
+                .                       .
+         bi = MD5(S + c(i-1))   c(i) = pi xor bi
+
+      The String will contain c(1)+c(2)+...+c(i) where + denotes
+      concatenation.
+
+      On receipt, the process is reversed to yield the original
+      password.
+
+   A summary of the User-Password Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      2 for User-Password.
+
+   Length
+
+      At least 18 and no larger than 130.
+
+   String
+
+      The String field is between 16 and 128 octets long, inclusive.
+
+5.3.  CHAP-Password
+
+   Description
+
+      This Attribute indicates the response value provided by a PPP
+      Challenge-Handshake Authentication Protocol (CHAP) user in
+      response to the challenge.  It is only used in Access-Request
+      packets.
+
+
+
+Rigney, et. al.             Standards Track                    [Page 23]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      The CHAP challenge value is found in the CHAP-Challenge Attribute
+      (60) if present in the packet, otherwise in the Request
+      Authenticator field.
+
+   A summary of the CHAP-Password Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  CHAP Ident   |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      3 for CHAP-Password.
+
+   Length
+
+      19
+
+   CHAP Ident
+
+      This field is one octet, and contains the CHAP Identifier from the
+      user's CHAP Response.
+
+   String
+
+      The String field is 16 octets, and contains the CHAP Response from
+      the user.
+
+5.4.  NAS-IP-Address
+
+   Description
+
+      This Attribute indicates the identifying IP Address of the NAS
+      which is requesting authentication of the user.  It is only used
+      in Access-Request packets.  Either NAS-IP-Address or NAS-
+      Identifier SHOULD be present in an Access-Request packet.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 24]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   A summary of the NAS-IP-Address Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |            Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Address (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      4 for NAS-IP-Address.
+
+   Length
+
+      6
+
+   Address
+
+      The Address field is four octets.
+
+5.5.  NAS-Port
+
+   Description
+
+      This Attribute indicates the physical port number of the NAS which
+      is authenticating the user.  It is only used in Access-Request
+      packets.  Note that this is using "port" in its sense of a
+      physical connection on the NAS, not in the sense of a TCP or UDP
+      port number.  Either NAS-Port or NAS-Port-Type (61) or both SHOULD
+      be present in an Access-Request packet, if the NAS differentiates
+      among its ports.
+
+   A summary of the NAS-Port Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 25]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      5 for NAS-Port.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  Despite the size of the field,
+      values range from 0 to 65535.
+
+5.6.  Service-Type
+
+   Description
+
+      This Attribute indicates the type of service the user has
+      requested, or the type of service to be provided.  It MAY be used
+      in both Access-Request and Access-Accept packets.  A NAS is not
+      required to implement all of these service types, and MUST treat
+      unknown or unsupported Service-Types as though an Access-Reject
+      had been received instead.
+
+   A summary of the Service-Type Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      6 for Service-Type.
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 26]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       1      Login
+       2      Framed
+       3      Callback Login
+       4      Callback Framed
+       5      Outbound
+       6      Administrative
+       7      NAS Prompt
+       8      Authenticate Only
+       9      Callback NAS Prompt
+
+
+      The service types are defined as follows when used in an Access-
+      Accept.  When used in an Access-Request, they should be considered
+      to be a hint to the RADIUS server that the NAS has reason to
+      believe the user would prefer the kind of service indicated, but
+      the server is not required to honor the hint.
+
+      Login               The user should be connected to a host.
+
+      Framed              A Framed Protocol should be started for the
+                          User, such as PPP or SLIP.
+
+      Callback Login      The user should be disconnected and called
+                          back, then connected to a host.
+
+      Callback Framed     The user should be disconnected and called
+                          back, then a Framed Protocol should be started
+                          for the User, such as PPP or SLIP.
+
+      Outbound            The user should be granted access to outgoing
+                          devices.
+
+      Administrative      The user should be granted access to the
+                          administrative interface to the NAS from which
+                          privileged commands can be executed.
+
+      NAS Prompt          The user should be provided a command prompt
+                          on the NAS from which non-privileged commands
+                          can be executed.
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 27]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      Authenticate Only   Only Authentication is requested, and no
+                          authorization information needs to be returned
+                          in the Access-Accept (typically used by proxy
+                          servers rather than the NAS itself).
+
+      Callback NAS Prompt The user should be disconnected and called
+                          back, then provided a command prompt on the
+                          NAS from which non-privileged commands can be
+                          executed.
+
+5.7.  Framed-Protocol
+
+   Description
+
+      This Attribute indicates the framing to be used for framed access.
+      It MAY be used in both Access-Request and Access-Accept packets.
+
+   A summary of the Framed-Protocol Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      7 for Framed-Protocol.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       1      PPP
+       2      SLIP
+       3      AppleTalk Remote Access Protocol (ARAP)
+       4      Gandalf proprietary SingleLink/MultiLink protocol
+       5      Xylogics proprietary IPX/SLIP
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 28]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+5.8.  Framed-IP-Address
+
+   Description
+
+      This Attribute indicates the address to be configured for the
+      user.  It MAY be used in Access-Accept packets.  It MAY be used in
+      an Access-Request packet as a hint by the NAS to the server that
+      it would prefer that address, but the server is not required to
+      honor the hint.
+
+   A summary of the Framed-IP-Address Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |            Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Address (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      8 for Framed-IP-Address.
+
+   Length
+
+      6
+
+   Address
+
+      The Address field is four octets.  The value 0xFFFFFFFF indicates
+      that the NAS should allow the user to select an address (e.g.
+      Negotiated).  The value 0xFFFFFFFE indicates that the NAS should
+      select an address for the user (e.g. Assigned from a pool of
+      addresses kept by the NAS).  Other valid values indicate that the
+      NAS should use that value as the user's IP address.
+
+5.9.  Framed-IP-Netmask
+
+   Description
+
+      This Attribute indicates the IP netmask to be configured for the
+      user when the user is a router to a network.  It MAY be used in
+      Access-Accept packets.  It MAY be used in an Access-Request packet
+      as a hint by the NAS to the server that it would prefer that
+      netmask, but the server is not required to honor the hint.
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 29]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   A summary of the Framed-IP-Netmask Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |            Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Address (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      9 for Framed-IP-Netmask.
+
+   Length
+
+      6
+
+   Address
+
+      The Address field is four octets specifying the IP netmask of the
+      user.
+
+5.10.  Framed-Routing
+
+   Description
+
+      This Attribute indicates the routing method for the user, when the
+      user is a router to a network.  It is only used in Access-Accept
+      packets.
+
+   A summary of the Framed-Routing Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      10 for Framed-Routing.
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 30]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       0      None
+       1      Send routing packets
+       2      Listen for routing packets
+       3      Send and Listen
+
+5.11.  Filter-Id
+
+   Description
+
+      This Attribute indicates the name of the filter list for this
+      user.  Zero or more Filter-Id attributes MAY be sent in an
+      Access-Accept packet.
+
+      Identifying a filter list by name allows the filter to be used on
+      different NASes without regard to filter-list implementation
+      details.
+
+   A summary of the Filter-Id Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      11 for Filter-Id.
+
+   Length
+
+      >= 3
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 31]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   String
+
+      The String field is one or more octets, and its contents are
+      implementation dependent.  It is intended to be human readable and
+      MUST NOT affect operation of the protocol.  It is recommended that
+      the message contain displayable ASCII characters from the range 32
+      through 126 decimal.
+
+5.12.  Framed-MTU
+
+   Description
+
+      This Attribute indicates the Maximum Transmission Unit to be
+      configured for the user, when it is not negotiated by some other
+      means (such as PPP).  It is only used in Access-Accept packets.
+
+      A summary of the Framed-MTU Attribute format is shown below.  The
+      fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      12 for Framed-MTU.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  Despite the size of the field,
+      values range from 64 to 65535.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 32]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+5.13.  Framed-Compression
+
+   Description
+
+      This Attribute indicates a compression protocol to be used for the
+      link.  It MAY be used in Access-Accept packets.  It MAY be used in
+      an Access-Request packet as a hint to the server that the NAS
+      would prefer to use that compression, but the server is not
+      required to honor the hint.
+
+      More than one compression protocol Attribute MAY be sent.  It is
+      the responsibility of the NAS to apply the proper compression
+      protocol to appropriate link traffic.
+
+   A summary of the Framed-Compression Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      13 for Framed-Compression.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       0      None
+       1      VJ TCP/IP header compression [5]
+       2      IPX header compression
+
+5.14.  Login-IP-Host
+
+   Description
+
+      This Attribute indicates the system with which to connect the
+      user, when the Login-Service Attribute is included.  It MAY be
+      used in Access-Accept packets.  It MAY be used in an Access-
+
+
+
+Rigney, et. al.             Standards Track                    [Page 33]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      Request packet as a hint to the server that the NAS would prefer
+      to use that host, but the server is not required to honor the
+      hint.
+
+   A summary of the Login-IP-Host Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |            Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Address (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      14 for Login-IP-Host.
+
+   Length
+
+      6
+
+   Address
+
+      The Address field is four octets.  The value 0xFFFFFFFF indicates
+      that the NAS SHOULD allow the user to select an address.  The
+      value 0 indicates that the NAS SHOULD select a host to connect the
+      user to.  Other values indicate the address the NAS SHOULD connect
+      the user to.
+
+5.15.  Login-Service
+
+   Description
+
+      This Attribute indicates the service which should be used to
+      connect the user to the login host.  It is only used in Access-
+      Accept packets.
+
+   A summary of the Login-Service Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 34]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      15 for Login-Service.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       0      Telnet
+       1      Rlogin
+       2      TCP Clear
+       3      PortMaster (proprietary)
+       4      LAT
+
+5.16.  Login-TCP-Port
+
+   Description
+
+      This Attribute indicates the TCP port with which the user is to be
+      connected, when the Login-Service Attribute is also present.  It
+      is only used in Access-Accept packets.
+
+   A summary of the Login-TCP-Port Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      16 for Login-TCP-Port.
+
+
+
+Rigney, et. al.             Standards Track                    [Page 35]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  Despite the size of the field,
+      values range from 0 to 65535.
+
+5.17.  (unassigned)
+
+   Description
+
+      ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
+
+5.18.  Reply-Message
+
+   Description
+
+      This Attribute indicates text which MAY be displayed to the user.
+
+      When used in an Access-Accept, it is the success message.
+
+      When used in an Access-Reject, it is the failure message.  It MAY
+      indicate a dialog message to prompt the user before another
+      Access-Request attempt.
+
+      When used in an Access-Challenge, it MAY indicate a dialog message
+      to prompt the user for a response.
+
+      Multiple Reply-Message's MAY be included and if any are displayed,
+      they MUST be displayed in the same order as they appear in the
+      packet.
+
+   A summary of the Reply-Message Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+   Type
+
+      18 for Reply-Message.
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 36]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets, and its contents are
+      implementation dependent.  It is intended to be human readable,
+      and MUST NOT affect operation of the protocol.  It is recommended
+      that the message contain displayable ASCII characters from the
+      range 10, 13, and 32 through 126 decimal.  Mechanisms for
+      extension to other character sets are beyond the scope of this
+      specification.
+
+5.19.  Callback-Number
+
+   Description
+
+      This Attribute indicates a dialing string to be used for callback.
+      It MAY be used in Access-Accept packets.  It MAY be used in an
+      Access-Request packet as a hint to the server that a Callback
+      service is desired, but the server is not required to honor the
+      hint.
+
+   A summary of the Callback-Number Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      19 for Callback-Number.
+
+   Length
+
+      >= 3
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 37]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.20.  Callback-Id
+
+   Description
+
+      This Attribute indicates the name of a place to be called, to be
+      interpreted by the NAS.  It MAY be used in Access-Accept packets.
+
+   A summary of the Callback-Id Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      20 for Callback-Id.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.21.  (unassigned)
+
+   Description
+
+      ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 38]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+5.22.  Framed-Route
+
+   Description
+
+      This Attribute provides routing information to be configured for
+      the user on the NAS.  It is used in the Access-Accept packet and
+      can appear multiple times.
+
+   A summary of the Framed-Route Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      22 for Framed-Route.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets, and its contents are
+      implementation dependent.  It is intended to be human readable and
+      MUST NOT affect operation of the protocol.  It is recommended that
+      the message contain displayable ASCII characters from the range 32
+      through 126 decimal.
+
+      For IP routes, it SHOULD contain a destination prefix in dotted
+      quad form optionally followed by a slash and a decimal length
+      specifier stating how many high order bits of the prefix should be
+      used.  That is followed by a space, a gateway address in dotted
+      quad form, a space, and one or more metrics separated by spaces.
+      For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
+      specifier may be omitted in which case it should default to 8 bits
+      for class A prefixes, 16 bits for class B prefixes, and 24 bits
+      for class C prefixes.  For example, "192.168.1.0 192.168.1.1 1".
+
+      Whenever the gateway address is specified as "0.0.0.0" the IP
+      address of the user SHOULD be used as the gateway address.
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 39]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+5.23.  Framed-IPX-Network
+
+   Description
+
+      This Attribute indicates the IPX Network number to be configured
+      for the user.  It is used in Access-Accept packets.
+
+   A summary of the Framed-IPX-Network Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      23 for Framed-IPX-Network.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  The value 0xFFFFFFFE indicates
+      that the NAS should select an IPX network for the user (e.g.
+      assigned from a pool of one or more IPX networks kept by the NAS).
+      Other values should be used as the IPX network for the link to the
+      user.
+
+5.24.  State
+
+   Description
+
+      This Attribute is available to be sent by the server to the client
+      in an Access-Challenge and MUST be sent unmodified from the client
+      to the server in the new Access-Request reply to that challenge,
+      if any.
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 40]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      This Attribute is available to be sent by the server to the client
+      in an Access-Accept that also includes a Termination-Action
+      Attribute with the value of RADIUS-Request.  If the NAS performs
+      the Termination-Action by sending a new Access-Request upon
+      termination of the current session, it MUST include the State
+      attribute unchanged in that Access-Request.
+
+      In either usage, no interpretation by the client should be made.
+      A packet may have only one State Attribute.  Usage of the State
+      Attribute is implementation dependent.
+
+   A summary of the State Attribute format is shown below.  The fields
+   are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      24 for State.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.25.  Class
+
+   Description
+
+      This Attribute is available to be sent by the server to the client
+      in an Access-Accept and should be sent unmodified by the client to
+      the accounting server as part of the Accounting-Request packet if
+      accounting is supported.  No interpretation by the client should
+      be made.
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 41]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   A summary of the Class Attribute format is shown below.  The fields
+   are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      25 for Class.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.26.  Vendor-Specific
+
+   Description
+
+      This Attribute is available to allow vendors to support their own
+      extended Attributes not suitable for general usage.  It MUST not
+      affect the operation of the RADIUS protocol.
+
+      Servers not equipped to interpret the vendor-specific information
+      sent by a client MUST ignore it (although it may be reported).
+      Clients which do not receive desired vendor-specific information
+      SHOULD make an attempt to operate without it, although they may do
+      so (and report they are doing so) in a degraded mode.
+
+   A summary of the Vendor-Specific Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 42]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |  Length       |            Vendor-Id
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+        Vendor-Id (cont)           |  String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      26 for Vendor-Specific.
+
+   Length
+
+       >= 7
+
+   Vendor-Id
+
+      The high-order octet is 0 and the low-order 3 octets are the SMI
+      Network Management Private Enterprise Code of the Vendor in
+      network byte order, as defined in the Assigned Numbers RFC [3].
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+      It SHOULD be encoded as a sequence of vendor type / vendor length
+      / value fields, as follows.  The Attribute-Specific field is
+      dependent on the vendor's definition of that attribute.  An
+      example encoding of the Vendor-Specific attribute using this
+      method follows:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |  Length       |            Vendor-Id
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           Vendor-Id (cont)           | Vendor type   | Vendor length |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Attribute-Specific...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 43]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+5.27.  Session-Timeout
+
+   Description
+
+      This Attribute sets the maximum number of seconds of service to be
+      provided to the user before termination of the session or prompt.
+      This Attribute is available to be sent by the server to the client
+      in an Access-Accept or Access-Challenge.
+
+   A summary of the Session-Timeout Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      27 for Session-Timeout.
+
+   Length
+
+      6
+
+   Value
+
+      The field is 4 octets, containing a 32-bit unsigned integer with
+      the maximum number of seconds this user should be allowed to
+      remain connected by the NAS.
+
+5.28.  Idle-Timeout
+
+   Description
+
+      This Attribute sets the maximum number of consecutive seconds of
+      idle connection allowed to the user before termination of the
+      session or prompt.  This Attribute is available to be sent by the
+      server to the client in an Access-Accept or Access-Challenge.
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 44]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   A summary of the Idle-Timeout Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      28 for Idle-Timeout.
+
+   Length
+
+      6
+
+   Value
+
+      The field is 4 octets, containing a 32-bit unsigned integer with
+      the maximum number of consecutive seconds of idle time this user
+      should be permitted before being disconnected by the NAS.
+
+5.29.  Termination-Action
+
+   Description
+
+      This Attribute indicates what action the NAS should take when the
+      specified service is completed.  It is only used in Access-Accept
+      packets.
+
+   A summary of the Termination-Action Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      29 for Termination-Action.
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 45]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       0      Default
+       1      RADIUS-Request
+
+      If the Value is set to RADIUS-Request, upon termination of the
+      specified service the NAS MAY send a new Access-Request to the
+      RADIUS server, including the State attribute if any.
+
+5.30.  Called-Station-Id
+
+   Description
+
+   This Attribute allows the NAS to send in the Access-Request packet
+   the phone number that the user called, using Dialed Number
+   Identification (DNIS) or similar technology.  Note that this may be
+   different from the phone number the call comes in on.  It is only
+   used in Access-Request packets.
+
+   A summary of the Called-Station-Id Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+   Type
+
+      30 for Called-Station-Id.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets, containing the phone
+      number that the user's call came in on.
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 46]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      The actual format of the information is site or application
+      specific.  Printable ASCII is recommended, but a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.31.  Calling-Station-Id
+
+   Description
+
+      This Attribute allows the NAS to send in the Access-Request packet
+      the phone number that the call came from, using Automatic Number
+      Identification (ANI) or similar technology.  It is only used in
+      Access-Request packets.
+
+   A summary of the Calling-Station-Id Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      31 for Calling-Station-Id.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets, containing the phone
+      number that the user placed the call from.
+
+      The actual format of the information is site or application
+      specific.  Printable ASCII is recommended, but a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 47]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+5.32.  NAS-Identifier
+
+   Description
+
+      This Attribute contains a string identifying the NAS originating
+      the Access-Request.  It is only used in Access-Request packets.
+      Either NAS-IP-Address or NAS-Identifier SHOULD be present in an
+      Access-Request packet.
+
+   A summary of the NAS-Identifier Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      32 for NAS-Identifier.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets, and should be unique to
+      the NAS within the scope of the RADIUS server.  For example, a
+      fully qualified domain name would be suitable as a NAS-Identifier.
+
+      The actual format of the information is site or application
+      specific, and a robust implementation SHOULD support the field as
+      undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.33.  Proxy-State
+
+   Description
+
+      This Attribute is available to be sent by a proxy server to
+      another server when forwarding an Access-Request and MUST be
+      returned unmodified in the Access-Accept, Access-Reject or
+      Access-Challenge.  This attribute should be removed by the proxy
+      server before the response is forwarded to the NAS.
+
+
+
+Rigney, et. al.             Standards Track                    [Page 48]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      Usage of the Proxy-State Attribute is implementation dependent.  A
+      description of its function is outside the scope of this
+      specification.
+
+   A summary of the Proxy-State Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      33 for Proxy-State.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.34.  Login-LAT-Service
+
+   Description
+
+      This Attribute indicates the system with which the user is to be
+      connected by LAT.  It MAY be used in Access-Accept packets, but
+      only when LAT is specified as the Login-Service.  It MAY be used
+      in an Access-Request packet as a hint to the server, but the
+      server is not required to honor the hint.
+
+      Administrators use the service attribute when dealing with
+      clustered systems, such as a VAX or Alpha cluster. In such an
+      environment several different time sharing hosts share the same
+      resources (disks, printers, etc.), and administrators often
+      configure each to offer access (service) to each of the shared
+      resources. In this case, each host in the cluster advertises its
+      services through LAT broadcasts.
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 49]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      Sophisticated users often know which service providers (machines)
+      are faster and tend to use a node name when initiating a LAT
+      connection.  Alternately, some administrators want particular
+      users to use certain machines as a primitive form of load
+      balancing (although LAT knows how to do load balancing itself).
+
+   A summary of the Login-LAT-Service Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+   Type
+
+      34 for Login-LAT-Service.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets, and contains the identity
+      of the LAT service to use.  The LAT Architecture allows this
+      string to contain $ (dollar), - (hyphen), . (period), _
+      (underscore), numerics, upper and lower case alphabetics, and the
+      ISO Latin-1 character set extension [6].  All LAT string
+      comparisons are case insensitive.
+
+5.35.  Login-LAT-Node
+
+   Description
+
+      This Attribute indicates the Node with which the user is to be
+      automatically connected by LAT.  It MAY be used in Access-Accept
+      packets, but only when LAT is specified as the Login-Service.  It
+      MAY be used in an Access-Request packet as a hint to the server,
+      but the server is not required to honor the hint.
+
+   A summary of the Login-LAT-Node Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 50]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      35 for Login-LAT-Node.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets, and contains the identity
+      of the LAT Node to connect the user to.  The LAT Architecture
+      allows this string to contain $ (dollar), - (hyphen), . (period),
+      _ (underscore), numerics, upper and lower case alphabetics, and
+      the ISO Latin-1 character set extension.  All LAT string
+      comparisons are case insensitive.
+
+5.36.  Login-LAT-Group
+
+   Description
+
+      This Attribute contains a string identifying the LAT group codes
+      which this user is authorized to use.  It MAY be used in Access-
+      Accept packets, but only when LAT is specified as the Login-
+      Service.  It MAY be used in an Access-Request packet as a hint to
+      the server, but the server is not required to honor the hint.
+
+      LAT supports 256 different group codes, which LAT uses as a form
+      of access rights.  LAT encodes the group codes as a 256 bit
+      bitmap.
+
+      Administrators can assign one or more of the group code bits at
+      the LAT service provider; it will only accept LAT connections that
+      have these group codes set in the bit map. The administrators
+      assign a bitmap of authorized group codes to each user; LAT gets
+      these from the operating system, and uses these in its requests to
+      the service providers.
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 51]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   A summary of the Login-LAT-Group Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      36 for Login-LAT-Group.
+
+   Length
+
+      34
+
+   String
+
+      The String field is a 32 octet bit map, most significant octet
+      first.  A robust implementation SHOULD support the field as
+      undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.37.  Framed-AppleTalk-Link
+
+   Description
+
+      This Attribute indicates the AppleTalk network number which should
+      be used for the serial link to the user, which is another
+      AppleTalk router.  It is only used in Access-Accept packets.  It
+      is never used when the user is not another router.
+
+   A summary of the Framed-AppleTalk-Link Attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 52]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   Type
+
+      37 for Framed-AppleTalk-Link.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  Despite the size of the field,
+      values range from 0 to 65535.  The special value of 0 indicates
+      that this is an unnumbered serial link.  A value of 1-65535 means
+      that the serial line between the NAS and the user should be
+      assigned that value as an AppleTalk network number.
+
+5.38.  Framed-AppleTalk-Network
+
+   Description
+
+      This Attribute indicates the AppleTalk Network number which the
+      NAS should probe to allocate an AppleTalk node for the user.  It
+      is only used in Access-Accept packets.  It is never used when the
+      user is another router.  Multiple instances of this Attribute
+      indicate that the NAS may probe using any of the network numbers
+      specified.
+
+   A summary of the Framed-AppleTalk-Network Attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      38 for Framed-AppleTalk-Network.
+
+   Length
+
+      6
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 53]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   Value
+
+      The Value field is four octets.  Despite the size of the field,
+      values range from 0 to 65535.  The special value 0 indicates that
+      the NAS should assign a network for the user, using its default
+      cable range.  A value between 1 and 65535 (inclusive) indicates
+      the AppleTalk Network the NAS should probe to find an address for
+      the user.
+
+5.39.  Framed-AppleTalk-Zone
+
+   Description
+
+      This Attribute indicates the AppleTalk Default Zone to be used for
+      this user.  It is only used in Access-Accept packets.  Multiple
+      instances of this attribute in the same packet are not allowed.
+
+   A summary of the Framed-AppleTalk-Zone Attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      39 for Framed-AppleTalk-Zone.
+
+   Length
+
+      >= 3
+
+   String
+
+      The name of the Default AppleTalk Zone to be used for this user.
+      A robust implementation SHOULD support the field as
+      undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 54]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+5.40.  CHAP-Challenge
+
+   Description
+
+      This Attribute contains the CHAP Challenge sent by the NAS to a
+      PPP Challenge-Handshake Authentication Protocol (CHAP) user.  It
+      is only used in Access-Request packets.
+
+      If the CHAP challenge value is 16 octets long it MAY be placed in
+      the Request Authenticator field instead of using this attribute.
+
+   A summary of the CHAP-Challenge Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |    String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      60 for CHAP-Challenge.
+
+   Length
+
+      >= 7
+
+   String
+
+      The String field contains the CHAP Challenge.
+
+5.41.  NAS-Port-Type
+
+   Description
+
+      This Attribute indicates the type of the physical port of the NAS
+      which is authenticating the user.  It can be used instead of or in
+      addition to the NAS-Port (5) attribute.  It is only used in
+      Access-Request packets.  Either NAS-Port (5) or NAS-Port-Type or
+      both SHOULD be present in an Access-Request packet, if the NAS
+      differentiates among its ports.
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 55]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   A summary of the NAS-Port-Type Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      61 for NAS-Port-Type.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  "Virtual" refers to a connection
+      to the NAS via some transport protocol, instead of through a
+      physical port.  For example, if a user telnetted into a NAS to
+      authenticate himself as an Outbound-User, the Access-Request might
+      include NAS-Port-Type = Virtual as a hint to the RADIUS server
+      that the user was not on a physical port.
+
+      0       Async
+      1       Sync
+      2       ISDN Sync
+      3       ISDN Async V.120
+      4       ISDN Async V.110
+      5       Virtual
+
+5.42.  Port-Limit
+
+   Description
+
+      This Attribute sets the maximum number of ports to be provided to
+      the user by the NAS.  This Attribute MAY be sent by the server to
+      the client in an Access-Accept packet.  It is intended for use in
+      conjunction with Multilink PPP [7] or similar uses.  It MAY also
+      be sent by the NAS to the server as a hint that that many ports
+      are desired for use, but the server is not required to honor the
+      hint.
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 56]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   A summary of the Port-Limit Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      62 for Port-Limit.
+
+   Length
+
+      6
+
+   Value
+
+      The field is 4 octets, containing a 32-bit unsigned integer with
+      the maximum number of ports this user should be allowed to connect
+      to on the NAS.
+
+5.43.  Login-LAT-Port
+
+   Description
+
+      This Attribute indicates the Port with which the user is to be
+      connected by LAT.  It MAY be used in Access-Accept packets, but
+      only when LAT is specified as the Login-Service.  It MAY be used
+      in an Access-Request packet as a hint to the server, but the
+      server is not required to honor the hint.
+
+   A summary of the Login-LAT-Port Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      63 for Login-LAT-Port.
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 57]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets, and contains the identity
+      of the LAT port to use.  The LAT Architecture allows this string
+      to contain $ (dollar), - (hyphen), . (period), _ (underscore),
+      numerics, upper and lower case alphabetics, and the ISO Latin-1
+      character set extension.  All LAT string comparisons are case
+      insensitive.
+
+5.44.  Table of Attributes
+
+   The following table provides a guide to which attributes may be found
+   in which kinds of packets, and in what quantity.
+
+   Request   Accept   Reject   Challenge   #    Attribute
+   1         0        0        0            1   User-Name
+   0-1       0        0        0            2   User-Password [Note 1]
+   0-1       0        0        0            3   CHAP-Password [Note 1]
+   0-1       0        0        0            4   NAS-IP-Address
+   0-1       0        0        0            5   NAS-Port
+   0-1       0-1      0        0            6   Service-Type
+   0-1       0-1      0        0            7   Framed-Protocol
+   0-1       0-1      0        0            8   Framed-IP-Address
+   0-1       0-1      0        0            9   Framed-IP-Netmask
+   0         0-1      0        0           10   Framed-Routing
+   0         0+       0        0           11   Filter-Id
+   0         0-1      0        0           12   Framed-MTU
+   0+        0+       0        0           13   Framed-Compression
+   0+        0+       0        0           14   Login-IP-Host
+   0         0-1      0        0           15   Login-Service
+   0         0-1      0        0           16   Login-TCP-Port
+   0         0+       0+       0+          18   Reply-Message
+   0-1       0-1      0        0           19   Callback-Number
+   0         0-1      0        0           20   Callback-Id
+   0         0+       0        0           22   Framed-Route
+   0         0-1      0        0           23   Framed-IPX-Network
+   0-1       0-1      0        0-1         24   State
+   0         0+       0        0           25   Class
+   0+        0+       0        0+          26   Vendor-Specific
+   0         0-1      0        0-1         27   Session-Timeout
+   0         0-1      0        0-1         28   Idle-Timeout
+   0         0-1      0        0           29   Termination-Action
+   0-1       0        0        0           30   Called-Station-Id
+   0-1       0        0        0           31   Calling-Station-Id
+
+
+
+Rigney, et. al.             Standards Track                    [Page 58]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   0-1       0        0        0           32   NAS-Identifier
+   0+        0+       0+       0+          33   Proxy-State
+   0-1       0-1      0        0           34   Login-LAT-Service
+   0-1       0-1      0        0           35   Login-LAT-Node
+   0-1       0-1      0        0           36   Login-LAT-Group
+   0         0-1      0        0           37   Framed-AppleTalk-Link
+   0         0+       0        0           38   Framed-AppleTalk-Network
+   0         0-1      0        0           39   Framed-AppleTalk-Zone
+   0-1       0        0        0           60   CHAP-Challenge
+   0-1       0        0        0           61   NAS-Port-Type
+   0-1       0-1      0        0           62   Port-Limit
+   0-1       0-1      0        0           63   Login-LAT-Port
+
+
+   Request   Accept   Reject   Challenge   #    Attribute
+
+
+   [Note 1] An Access-Request MUST contain either a User-Password or a
+   CHAP-Password, and MUST NOT contain both.
+
+   The following table defines the meaning of the above table entries.
+
+ 0     This attribute MUST NOT be present in packet.
+ 0+    Zero or more instances of this attribute MAY be present in packet.
+ 0-1   Zero or one instance of this attribute MAY be present in packet.
+ 1     Exactly one instance of this attribute MUST be present in packet.
+
+6.  Examples
+
+   A few examples are presented to illustrate the flow of packets and
+   use of typical attributes.  These examples are not intended to be
+   exhaustive, many others are possible.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 59]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+6.1.  User Telnet to Specified Host
+
+   The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+   RADIUS Server for a user named nemo logging in on port 3.
+
+      Code = 1        (Access-Request)
+      ID = 0
+      Length = 56
+      Request Authenticator = {16 octet random number}
+      Attributes:
+          User-Name = "nemo"
+          User-Password = {16 octets of Password padded at end with nulls,
+                      XORed with MD5(shared secret|Request Authenticator)}
+          NAS-IP-Address = 192.168.1.16
+          NAS-Port = 3
+
+   The RADIUS server authenticates nemo, and sends an Access-Accept UDP
+   packet to the NAS telling it to telnet nemo to host 192.168.1.3.
+
+      Code = 2        (Access-Accept)
+      ID = 0          (same as in Access-Request)
+      Length = 38
+      Response Authenticator = {16-octet MD-5 checksum of the code (2),
+                      id (0), Length (38), the Request Authenticator from
+                      above, the attributes in this reply, and the shared
+                      secret}
+      Attributes:
+          Service-Type = Login-User
+          Login-Service = Telnet
+          Login-Host = 192.168.1.3
+
+6.2.  Framed User Authenticating with CHAP
+
+   The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+   RADIUS Server for a user named flopsy logging in on port 20 with PPP,
+   authenticating using CHAP.  The NAS sends along the Service-Type and
+   Framed-Protocol attributes as a hint to the RADIUS server that this
+   user is looking for PPP, although the NAS is not required to do so.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 60]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+      Code = 1        (Access-Request)
+      ID = 1
+      Length = 71
+      Request Authenticator = {16 octet random number also used as
+                               CHAP challenge}
+      Attributes:
+          User-Name = "flopsy"
+          CHAP-Password = {1 octet CHAP ID followed by 16 octet
+                           CHAP response}
+          NAS-IP-Address = 192.168.1.16
+          NAS-Port = 20
+          Service-Type = Framed-User
+          Framed-Protocol = PPP
+
+   The RADIUS server authenticates flopsy, and sends an Access-Accept
+   UDP packet to the NAS telling it to start PPP service and assign an
+   address for the user out of its dynamic address pool.
+
+      Code = 2        (Access-Accept)
+      ID = 1          (same as in Access-Request)
+      Length = 56
+      Response Authenticator = {16-octet MD-5 checksum of the code (2),
+                      id (1), Length (56), the Request Authenticator from
+                      above, the attributes in this reply, and the shared
+                      secret}
+      Attributes:
+          Service-Type = Framed-User
+          Framed-Protocol = PPP
+          Framed-IP-Address = 255.255.255.254
+          Framed-Routing = None
+          Framed-Compression = 1      (VJ TCP/IP Header Compression)
+          Framed-MTU = 1500
+
+6.3.  User with Challenge-Response card
+
+   The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+   RADIUS Server for a user named mopsy logging in on port 7.
+
+      Code = 1        (Access-Request)
+      ID = 2
+      Length = 57
+      Request Authenticator = {16 octet random number}
+      Attributes:
+          User-Name = "mopsy"
+          User-Password = {16 octets of Password padded at end with nulls,
+                      XORed with MD5(shared secret|Request Authenticator)}
+          NAS-IP-Address = 192.168.1.16
+          NAS-Port = 7
+
+
+
+Rigney, et. al.             Standards Track                    [Page 61]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+   The RADIUS server decides to challenge mopsy, sending back a
+   challenge string and looking for a response.  The RADIUS server
+   therefore and sends an Access-Challenge UDP packet to the NAS.
+
+      Code = 11       (Access-Challenge}
+      ID = 2          (same as in Access-Request)
+      Length = 78
+      Response Authenticator = {16-octet MD-5 checksum of the code (11),
+                      id (2), length (78), the Request Authenticator from
+                      above, the attributes in this reply, and the shared
+                      secret}
+      Attributes:
+          Reply-Message = "Challenge 32769430.  Enter response at prompt."
+          State =     {Magic Cookie to be returned along with user's response;
+                       in this example 8 octets of data}
+
+   The user enters his response, and the NAS send a new Access-Request
+   with that response, and includes the State Attribute.
+
+      Code = 1        (Access-Request)
+      ID = 3          (Note that this changes)
+      Length = 67
+      Request Authenticator = {NEW 16 octet random number}
+      Attributes:
+          User-Name = "mopsy"
+          User-Password = {16 octets of Response padded at end with
+                      nulls, XORed with MD5 checksum of shared secret
+                      plus above Request Authenticator}
+          NAS-IP-Address = 192.168.1.16
+          NAS-Port = 7
+          State =     {Magic Cookie from Access-Challenge packet, unchanged}
+
+   The Response was incorrect, so the RADIUS server tells the NAS to
+   reject the login attempt.
+
+      Code = 3        (Access-Reject)
+      ID = 3          (same as in Access-Request)
+      Length = 20
+      Response Authenticator = {16-octet MD-5 checksum of the code (3),
+                      id (3), length(20), the Request Authenticator from
+                      above, the attributes in this reply if any, and the
+                      shared secret}
+      Attributes:
+              (none, although a Reply-Message could be sent)
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 62]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+Security Considerations
+
+   Security issues are the primary topic of this document.
+
+   In practice, within or associated with each RADIUS server, there is a
+   database which associates "user" names with authentication
+   information ("secrets").  It is not anticipated that a particular
+   named user would be authenticated by multiple methods.  This would
+   make the user vulnerable to attacks which negotiate the least secure
+   method from among a set.  Instead, for each named user there should
+   be an indication of exactly one method used to authenticate that user
+   name.  If a user needs to make use of different authentication
+   methods under different circumstances, then distinct user names
+   SHOULD be employed, each of which identifies exactly one
+   authentication method.
+
+   Passwords and other secrets should be stored at the respective ends
+   such that access to them is as limited as possible.  Ideally, the
+   secrets should only be accessible to the process requiring access in
+   order to perform the authentication.
+
+   The secrets should be distributed with a mechanism that limits the
+   number of entities that handle (and thus gain knowledge of) the
+   secret.  Ideally, no unauthorized person should ever gain knowledge
+   of the secrets.  It is possible to achieve this with SNMP Security
+   Protocols [8], but such a mechanism is outside the scope of this
+   specification.
+
+   Other distribution methods are currently undergoing research and
+   experimentation.  The SNMP Security document [8] also has an
+   excellent overview of threats to network protocols.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 63]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+References
+
+   [1]   Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
+         RFC 1321, MIT Laboratory for Computer Science, RSA Data
+         Security Inc., April 1992.
+
+   [2]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+         USC/Information Sciences Institute, August 1980.
+
+   [3]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+         1700, USC/Information Sciences Institute, October 1994.
+
+   [4]   Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
+         Private Communications in a Public World", Prentice Hall, March
+         1995, ISBN 0-13-061466-1.
+
+   [5]   Jacobson, V., "Compressing TCP/IP headers for low-speed serial
+         links", RFC 1144, Lawrence Berkeley Laboratory, February 1990.
+
+   [6]   ISO 8859. International Standard -- Information Processing --
+         8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
+         Alphabet No. 1, ISO 8859-1:1987.
+         <URL:http://www.iso.ch/cate/d16338.html>
+
+   [7]   Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP
+         Multilink Protocol (MP)", RFC 1717, University of California
+         Berkeley, Lloyd Internetworking, Newbridge Networks
+         Corporation, November 1994.
+
+   [8]   Galvin, J., McCloghrie, K., and Davin, J., "SNMP Security
+         Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
+         LAN Systems, Inc., MIT Laboratory for Computer Science, July
+         1992.
+
+   [9]   Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
+
+Acknowledgments
+
+   RADIUS was originally developed by Livingston Enterprises for their
+   PortMaster series of Network Access Servers.
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 64]
+
+RFC 2138                         RADIUS                       April 1997
+
+
+Chair's Address
+
+   The working group can be contacted via the current chair:
+
+   Carl Rigney
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   Phone: +1 510 426 0770
+   EMail: cdr@livingston.com
+
+Authors' Addresses
+
+   Questions about this memo can also be directed to:
+
+   Carl Rigney
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   Phone: +1 510 426 0770
+   EMail: cdr@livingston.com
+
+   Allan C. Rubens
+   Merit Network, Inc.
+   4251 Plymouth Road
+   Ann Arbor, Michigan  48105-2785
+
+   EMail: acr@merit.edu
+
+   William Allen Simpson
+   Daydreamer
+   Computer Systems Consulting Services
+   1384 Fontaine
+   Madison Heights, Michigan  48071
+
+   EMail: wsimpson@greendragon.com
+
+   Steve Willens
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   EMail: steve@livingston.com
+
+
+
+
+
+
+Rigney, et. al.             Standards Track                    [Page 65]
+
diff --git a/doc/rfc2139.txt b/doc/rfc2139.txt
new file mode 100644
index 0000000..88c5af8
--- /dev/null
+++ b/doc/rfc2139.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                          C. Rigney
+Request for Comments: 2139                                    Livingston
+Obsoletes: 2059                                               April 1997
+Category: Informational
+
+
+                           RADIUS Accounting
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This document describes a protocol for carrying accounting
+   information between a Network Access Server and a shared Accounting
+   Server.
+
+Implementation Note
+
+   This memo documents the RADIUS Accounting protocol.  There has been
+   some confusion in the assignment of port numbers for this protocol.
+   The early deployment of RADIUS Accounting was done using the
+   erroneously chosen port number 1646, which conflicts with the "sa-
+   msg-port" service.  The officially assigned port number for RADIUS
+   Accounting is 1813.
+
+Table of Contents
+
+   1.     Introduction ..........................................    2
+      1.1       Specification of Requirements ...................    3
+      1.2       Terminology .....................................    3
+   2.     Operation .............................................    4
+   3.     Packet Format .........................................    5
+   4.     Packet Types ..........................................    7
+      4.1       Accounting-Request ..............................    7
+      4.2       Accounting-Response .............................    8
+   5.     Attributes ............................................   10
+      5.1       Acct-Status-Type ................................   11
+      5.2       Acct-Delay-Time .................................   12
+      5.3       Acct-Input-Octets ...............................   13
+      5.4       Acct-Output-Octets ..............................   14
+      5.5       Acct-Session-Id .................................   14
+      5.6       Acct-Authentic ..................................   15
+      5.7       Acct-Session-Time ...............................   16
+      5.8       Acct-Input-Packets ..............................   16
+
+
+
+Rigney                       Informational                      [Page 1]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+      5.9       Acct-Output-Packets .............................   17
+      5.10      Acct-Terminate-Cause ............................   18
+      5.11      Acct-Multi-Session-Id ...........................   20
+      5.12      Acct-Link-Count .................................   21
+      5.13      Table of Attributes .............................   22
+   Security Considerations ......................................   24
+   References ...................................................   24
+   Acknowledgements .............................................   24
+   Chair's Address ..............................................   24
+   Author's Address .............................................   25
+
+1.  Introduction
+
+   Managing dispersed serial line and modem pools for large numbers of
+   users can create the need for significant administrative support.
+   Since modem pools are by definition a link to the outside world, they
+   require careful attention to security, authorization and accounting.
+   This can be best achieved by managing a single "database" of users,
+   which allows for authentication (verifying user name and password) as
+   well as configuration information detailing the type of service to
+   deliver to the user (for example, SLIP, PPP, telnet, rlogin).
+
+   The RADIUS (Remote Authentication Dial In User Service) document [4]
+   specifies the RADIUS protocol used for Authentication and
+   Authorization.  This memo extends the use of the RADIUS protocol to
+   cover delivery of accounting information from the Network Access
+   Server (NAS) to a RADIUS accounting server.
+
+   Key features of RADIUS Accounting are:
+
+      Client/Server Model
+
+         A Network Access Server (NAS) operates as a client of the
+         RADIUS accounting server.  The client is responsible for
+         passing user accounting information to a designated RADIUS
+         accounting server.
+
+         The RADIUS accounting server is responsible for receiving the
+         accounting request and returning a response to the client
+         indicating that it has successfully received the request.
+
+         The RADIUS accounting server can act as a proxy client to other
+         kinds of accounting servers.
+
+
+
+
+
+
+
+
+Rigney                       Informational                      [Page 2]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+      Network Security
+
+         Transactions between the client and RADIUS accounting server
+         are authenticated through the use of a shared secret, which is
+         never sent over the network.
+
+      Extensible Protocol
+
+         All transactions are comprised of variable length Attribute-
+         Length-Value 3-tuples.  New attribute values can be added
+         without disturbing existing implementations of the protocol.
+
+1.1.  Specification of Requirements
+
+   In this document, several words are used to signify the requirements
+   of the specification.  These words are often capitalized.
+
+   MUST      This word, or the adjective "required", means that the
+             definition is an absolute requirement of the specification.
+
+   MUST NOT  This phrase means that the definition is an absolute
+             prohibition of the specification.
+
+   SHOULD    This word, or the adjective "recommended", means that there
+             may exist valid reasons in particular circumstances to
+             ignore this item, but the full implications must be
+             understood and carefully weighed before choosing a
+             different course.
+
+   MAY       This word, or the adjective "optional", means that this
+             item is one of an allowed set of alternatives.  An
+             implementation which does not include this option MUST be
+             prepared to interoperate with another implementation which
+             does include the option.
+
+1.2.  Terminology
+
+      This document uses the following terms:
+
+   service   The NAS provides a service to the dial-in user, such as PPP
+             or Telnet.
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                      [Page 3]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+   session   Each service provided by the NAS to a dial-in user
+             constitutes a session, with the beginning of the session
+             defined as the point where service is first provided and
+             the end of the session defined as the point where service
+             is ended.  A user may have multiple sessions in parallel or
+             series if the NAS supports that, with each session
+             generating a separate start and stop accounting record with
+             its own Acct-Session-Id.
+
+   silently discard
+      This means the implementation discards the packet without
+      further processing.  The implementation SHOULD provide the
+      capability of logging the error, including the contents of
+      the silently discarded packet, and SHOULD record the event
+      in a statistics counter.
+
+2.  Operation
+
+   When a client is configured to use RADIUS Accounting, at the start of
+   service delivery it will generate an Accounting Start packet
+   describing the type of service being delivered and the user it is
+   being delivered to, and will send that to the RADIUS Accounting
+   server, which will send back an acknowledgement that the packet has
+   been received.  At the end of service delivery the client will
+   generate an Accounting Stop packet describing the type of service
+   that was delivered and optionally statistics such as elapsed time,
+   input and output octets, or input and output packets.  It will send
+   that to the RADIUS Accounting server, which will send back an
+   acknowledgement that the packet has been received.
+
+   The Accounting-Request (whether for Start or Stop) is submitted to
+   the RADIUS accounting server via the network. It is recommended that
+   the client continue attempting to send the Accounting-Request packet
+   until it receives an acknowledgement, using some form of backoff.  If
+   no response is returned within a length of time, the request is re-
+   sent a number of times.  The client can also forward requests to an
+   alternate server or servers in the event that the primary server is
+   down or unreachable.  An alternate server can be used either after a
+   number of tries to the primary server fail, or in a round-robin
+   fashion.  Retry and fallback algorithms are the topic of current
+   research and are not specified in detail in this document.
+
+   The RADIUS accounting server MAY make requests of other servers in
+   order to satisfy the request, in which case it acts as a client.
+
+   If the RADIUS accounting server is unable to successfully record the
+   accounting packet it MUST NOT send an Accounting-Response
+   acknowledgment to the client.
+
+
+
+Rigney                       Informational                      [Page 4]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+3.  Packet Format
+
+   Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
+   field [1], where the UDP Destination Port field indicates 1813
+   (decimal).
+
+   When a reply is generated, the source and destination ports are
+   reversed.
+
+   This memo documents the RADIUS Accounting protocol.  There has been
+   some confusion in the assignment of port numbers for this protocol.
+   The early deployment of RADIUS Accounting was done using the
+   erroneously chosen port number 1646, which conflicts with the "sa-
+   msg-port" service.  The officially assigned port number for RADIUS
+   Accounting is 1813.
+
+   A summary of the RADIUS data format is shown below.  The fields are
+   transmitted from left to right.
+
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|     Code      |  Identifier   |            Length             |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                                                               |
+|                         Authenticator                         |
+|                                                               |
+|                                                               |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|  Attributes ...
++-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+Code
+
+   The Code field is one octet, and identifies the type of RADIUS
+   packet.  When a packet is received with an invalid Code field, it is
+   silently discarded.
+
+   RADIUS Accounting Codes (decimal) are assigned as follows:
+
+      4       Accounting-Request
+      5       Accounting-Response
+
+Identifier
+
+   The Identifier field is one octet, and aids in matching requests and
+   replies.
+
+
+
+Rigney                       Informational                      [Page 5]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+Length
+
+   The Length field is two octets.  It indicates the length of the
+   packet including the Code, Identifier, Length, Authenticator and
+   Attribute fields.  Octets outside the range of the Length field
+   should be treated as padding and should be ignored on reception.  If
+   the packet is shorter than the Length field indicates, it should be
+   silently discarded.  The minimum length is 20 and maximum length is
+   4096.
+
+Authenticator
+
+   The Authenticator field is sixteen (16) octets.  The most significant
+   octet is transmitted first.  This value is used to authenticate the
+   messages between the client and RADIUS accounting server.
+
+Request Authenticator
+
+   In Accounting-Request Packets, the Authenticator value is a 16 octet
+   MD5 [3] checksum, called the Request Authenticator.
+
+   The NAS and RADIUS accounting server share a secret.  The Request
+   Authenticator field in Accounting-Request packets contains a one- way
+   MD5 hash calculated over a stream of octets consisting of the Code +
+   Identifier + Length + 16 zero octets + request attributes + shared
+   secret (where + indicates concatenation).  The 16 octet MD5 hash
+   value is stored in the Authenticator field of the Accounting-Request
+   packet.
+
+      Note that the Request Authenticator of an Accounting-Request can
+      not be done the same way as the Request Authenticator of a RADIUS
+      Access-Request, because there is no User-Password attribute in an
+      Accounting-Request.
+
+Response Authenticator
+
+   The Authenticator field in an Accounting-Response packet is called
+   the Response Authenticator, and contains a one-way MD5 hash
+   calculated over a stream of octets consisting of the Accounting-
+   Response Code, Identifier, Length, the Request Authenticator field
+   from the Accounting-Request packet being replied to, and the response
+   attributes if any, followed by the shared secret.  The resulting 16
+   octet MD5 hash value is stored in the Authenticator field of the
+   Accounting-Response packet.
+
+
+
+
+
+
+
+Rigney                       Informational                      [Page 6]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+Attributes
+
+   Attributes may have multiple instances, in such a case the order of
+   attributes of the same type SHOULD be preserved.  The order of
+   attributes of different types is not required to be preserved.
+
+4.  Packet Types
+
+   The RADIUS packet type is determined by the Code field in the first
+   octet of the packet.
+
+4.1.  Accounting-Request
+
+   Description
+
+      Accounting-Request packets are sent from a client (typically a
+      Network Access Server or its proxy) to a RADIUS accounting server,
+      and convey information used to provide accounting for a service
+      provided to a user.  The client transmits a RADIUS packet with the
+      Code field set to 4 (Accounting-Request).
+
+      Upon receipt of an Accounting-Request, the server MUST transmit an
+      Accounting-Response reply if it successfully records the
+      accounting packet, and MUST NOT transmit any reply if it fails to
+      record the accounting packet.
+
+      Any attribute valid in a RADIUS Access-Request or Access-Accept
+      packet is valid in a RADIUS Accounting-Request packet, except that
+      the following attributes MUST NOT be present in an Accounting-
+      Request: User-Password, CHAP-Password, Reply-Message, State.
+      Either NAS-IP-Address or NAS-Identifier MUST be present in a
+      RADIUS Accounting-Request.  It SHOULD contain a NAS-Port or NAS-
+      Port-Type attribute or both unless the service does not involve a
+      port or the NAS does not distinguish among its ports.
+
+   A summary of the Accounting-Request packet format is shown below.
+   The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                      [Page 7]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Request Authenticator                     |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      4 for Accounting-Request.
+
+   Identifier
+
+      The Identifier field MUST be changed whenever the content of the
+      Attributes field changes, and whenever a valid reply has been
+      received for a previous request.  For retransmissions where the
+      contents are identical, the Identifier MUST remain unchanged.
+
+      Note that if Acct-Delay-Time is included in the attributes of an
+      Accounting-Request then the Acct-Delay-Time value will be updated
+      when the packet is retransmitted, changing the content of the
+      Attributes field and requiring a new Identifier and Request
+      Authenticator.
+
+   Request Authenticator
+
+      The Request Authenticator of an Accounting-Request contains a 16-
+      octet MD5 hash value calculated according to the method described
+      in "Request Authenticator" above.
+
+   Attributes
+
+      The Attributes field is variable in length, and contains a list of
+      Attributes.
+
+4.2.  Accounting-Response
+
+   Description
+
+      Accounting-Response packets are sent by the RADIUS accounting
+      server to the client to acknowledge that the Accounting-Request
+      has been received and recorded successfully.  If the Accounting-
+
+
+
+Rigney                       Informational                      [Page 8]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+      Request was recorded successfully then the RADIUS accounting
+      server MUST transmit a packet with the Code field set to 5
+      (Accounting-Response).  On reception of an Accounting-Response by
+      the client, the Identifier field is matched with a pending
+      Accounting-Request.  Invalid packets are silently discarded.
+
+      A RADIUS Accounting-Response is not required to have any
+      attributes in it.
+
+   A summary of the Accounting-Response packet format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Response Authenticator                    |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      5 for Accounting-Response.
+
+   Identifier
+
+      The Identifier field is a copy of the Identifier field of the
+      Accounting-Request which caused this Accounting-Response.
+
+   Response Authenticator
+
+      The Response Authenticator of an Accounting-Response contains a
+      16-octet MD5 hash value calculated according to the method
+      described in "Response Authenticator" above.
+
+   Attributes
+
+      The Attributes field is variable in length, and contains a list of
+      zero or more Attributes.
+
+
+
+
+
+
+
+Rigney                       Informational                      [Page 9]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+5.  Attributes
+
+   RADIUS Attributes carry the specific authentication, authorization
+   and accounting details for the request and response.
+
+   Some attributes MAY be included more than once.  The effect of this
+   is attribute specific, and is specified in each attribute
+   description.
+
+   The end of the list of attributes is indicated by the Length of the
+   RADIUS packet.
+
+   A summary of the attribute format is shown below.  The fields are
+   transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |  Value ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      The Type field is one octet.  Up-to-date values of the RADIUS Type
+      field are specified in the most recent "Assigned Numbers" RFC [2].
+      Values 192-223 are reserved for experimental use, values 224-240
+      are reserved for implementation-specific use, and values 241-255
+      are reserved and should not be used.  This specification concerns
+      the following values:
+
+           1-39   (refer to RADIUS document [4])
+          40      Acct-Status-Type
+          41      Acct-Delay-Time
+          42      Acct-Input-Octets
+          43      Acct-Output-Octets
+          44      Acct-Session-Id
+          45      Acct-Authentic
+          46      Acct-Session-Time
+          47      Acct-Input-Packets
+          48      Acct-Output-Packets
+          49      Acct-Terminate-Cause
+          50      Acct-Multi-Session-Id
+          51      Acct-Link-Count
+          60+     (refer to RADIUS document [4])
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 10]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+   Length
+
+      The Length field is one octet, and indicates the length of this
+      attribute including the Type, Length and Value fields.  If an
+      attribute is received in an Accounting-Request with an invalid
+      Length, the entire request should be silently discarded.
+
+   Value
+
+      The Value field is zero or more octets and contains information
+      specific to the attribute.  The format and length of the Value
+      field is determined by the Type and Length fields.
+
+      The format of the value field is one of four data types.
+
+      string    0-253 octets
+
+      address   32 bit value, most significant octet first.
+
+      integer   32 bit value, most significant octet first.
+
+      time      32 bit value, most significant octet first -- seconds
+                since 00:00:00 GMT, January 1, 1970.  The standard
+                Attributes do not use this data type but it is presented
+                here for possible use within Vendor-Specific attributes.
+
+5.1.  Acct-Status-Type
+
+   Description
+
+      This attribute indicates whether this Accounting-Request marks the
+      beginning of the user service (Start) or the end (Stop).
+
+      It MAY be used by the client to mark the start of accounting (for
+      example, upon booting) by specifying Accounting-On and to mark the
+      end of accounting (for example, just before a scheduled reboot) by
+      specifying Accounting-Off.
+
+   A summary of the Acct-Status-Type attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Rigney                       Informational                     [Page 11]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+   Type
+
+      40 for Acct-Status-Type.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       1      Start
+       2      Stop
+       7      Accounting-On
+       8      Accounting-Off
+
+5.2.  Acct-Delay-Time
+
+   Description
+
+      This attribute indicates how many seconds the client has been
+      trying to send this record for, and can be subtracted from the
+      time of arrival on the server to find the approximate time of the
+      event generating this Accounting-Request.  (Network transit time
+      is ignored.)
+
+      Note that changing the Acct-Delay-Time causes the Identifier to
+      change; see the discussion under Identifier above.
+
+   A summary of the Acct-Delay-Time attribute format is shown below.
+   The fields are transmitted from left to right.
+
+          0                   1                   2                   3
+          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         |     Type      |    Length     |             Value
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                    Value (cont)         |
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      41 for Acct-Delay-Time.
+
+   Length
+
+      6
+
+
+
+Rigney                       Informational                     [Page 12]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+   Value
+
+      The Value field is four octets.
+
+5.3.  Acct-Input-Octets
+
+   Description
+
+      This attribute indicates how many octets have been received from
+      the port over the course of this service being provided, and can
+      only be present in Accounting-Request records where the Acct-
+      Status-Type is set to Stop.
+
+   A summary of the Acct-Input-Octets attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      42 for Acct-Input-Octets.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+5.4.  Acct-Output-Octets
+
+   Description
+
+      This attribute indicates how many octets have been sent to the
+      port in the course of delivering this service, and can only be
+      present in Accounting-Request records where the Acct-Status-Type
+      is set to Stop.
+
+   A summary of the Acct-Output-Octets attribute format is shown below.
+   The fields are transmitted from left to right.
+
+
+
+
+Rigney                       Informational                     [Page 13]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      43 for Acct-Output-Octets.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+5.5.  Acct-Session-Id
+
+   Description
+
+      This attribute is a unique Accounting ID to make it easy to match
+      start and stop records in a log file.  The start and stop records
+      for a given session MUST have the same Acct-Session-Id.  It is
+      strongly recommended that the Acct-Session-Id be a printable ASCII
+      string.
+
+      For example, one implementation uses a string with an 8-digit
+      upper case hexadecimal number, the first two digits increment on
+      each reboot (wrapping every 256 reboots) and the next 6 digits
+      counting from 0 for the first person logging in after a reboot up
+      to 2^24-1, about 16 million.  Other encodings are possible.
+
+   A summary of the Acct-Session-Id attribute format is shown below.
+   The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 14]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      44 for Acct-Session-Id.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field SHOULD be a string of printable ASCII characters.
+
+5.6.  Acct-Authentic
+
+   Description
+
+      This attribute MAY be included in an Accounting-Request to
+      indicate how the user was authenticated, whether by RADIUS, the
+      NAS itself, or another remote authentication protocol.  Users who
+      are delivered service without being authenticated SHOULD NOT
+      generate Accounting records.
+
+   A summary of the Acct-Authentic attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      45 for Acct-Authentic.
+
+   Length
+
+      6
+
+
+
+
+
+Rigney                       Informational                     [Page 15]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+   Value
+
+      The Value field is four octets.
+
+       1      RADIUS
+       2      Local
+       3      Remote
+
+5.7.  Acct-Session-Time
+
+   Description
+
+      This attribute indicates how many seconds the user has received
+      service for, and can only be present in Accounting-Request records
+      where the Acct-Status-Type is set to Stop.
+
+   A summary of the Acct-Session-Time attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      46 for Acct-Session-Time.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+5.8.  Acct-Input-Packets
+
+   Description
+
+      This attribute indicates how many packets have been received from
+      the port over the course of this service being provided to a
+      Framed User, and can only be present in Accounting-Request records
+      where the Acct-Status-Type is set to Stop.
+
+
+
+
+Rigney                       Informational                     [Page 16]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+   A summary of the Acct-Input-packets attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      47 for Acct-Input-Packets.
+
+   Length
+
+       6
+
+   Value
+
+      The Value field is four octets.
+
+5.9.  Acct-Output-Packets
+
+   Description
+
+      This attribute indicates how many packets have been sent to the
+      port in the course of delivering this service to a Framed User,
+      and can only be present in Accounting-Request records where the
+      Acct-Status-Type is set to Stop.
+
+   A summary of the Acct-Output-Packets attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      48 for Acct-Output-Packets.
+
+
+
+
+
+Rigney                       Informational                     [Page 17]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+5.10.  Acct-Terminate-Cause
+
+   Description
+
+      This attribute indicates how the session was terminated, and can
+      only be present in Accounting-Request records where the Acct-
+      Status-Type is set to Stop.
+
+   A summary of the Acct-Terminate-Cause attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      49 for Acct-Terminate-Cause
+
+   Length
+
+      6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 18]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+   Value
+
+      The Value field is four octets, containing an integer specifying
+      the cause of session termination, as follows:
+
+      1       User Request
+      2       Lost Carrier
+      3       Lost Service
+      4       Idle Timeout
+      5       Session Timeout
+      6       Admin Reset
+      7       Admin Reboot
+      8       Port Error
+      9       NAS Error
+      10      NAS Request
+      11      NAS Reboot
+      12      Port Unneeded
+      13      Port Preempted
+      14      Port Suspended
+      15      Service Unavailable
+      16      Callback
+      17      User Error
+      18      Host Request
+
+
+
+      The termination causes are as follows:
+
+      User Request         User requested termination of service, for
+                           example with LCP Terminate or by logging out.
+
+      Lost Carrier         DCD was dropped on the port.
+
+      Lost Service         Service can no longer be provided; for
+                           example, user's connection to a host was
+                           interrupted.
+
+      Idle Timeout         Idle timer expired.
+
+      Session Timeout      Maximum session length timer expired.
+
+      Admin Reset          Administrator reset the port or session.
+
+      Admin Reboot         Administrator is ending service on the NAS,
+                           for example prior to rebooting the NAS.
+
+      Port Error           NAS detected an error on the port which
+                           required ending the session.
+
+
+
+Rigney                       Informational                     [Page 19]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+      NAS Error            NAS detected some error (other than on the
+                           port) which required ending the session.
+
+      NAS Request          NAS ended session for a non-error reason not
+                           otherwise listed here.
+
+      NAS Reboot           The NAS ended the session in order to reboot
+                           non-administratively ("crash").
+
+      Port Unneeded        NAS ended session because resource usage fell
+                           below low-water mark (for example, if a
+                           bandwidth-on-demand algorithm decided that
+                           the port was no longer needed).
+
+      Port Preempted       NAS ended session in order to allocate the
+                           port to a higher priority use.
+
+      Port Suspended       NAS ended session to suspend a virtual
+                           session.
+
+      Service Unavailable  NAS was unable to provide requested service.
+
+      Callback             NAS is terminating current session in order
+                           to perform callback for a new session.
+
+      User Error           Input from user is in error, causing
+                           termination of session.
+
+      Host Request         Login Host terminated session normally.
+
+5.11.  Acct-Multi-Session-Id
+
+   Description
+
+      This attribute is a unique Accounting ID to make it easy to link
+      together multiple related sessions in a log file.  Each session
+      linked together would have a unique Acct-Session-Id but the same
+      Acct-Multi-Session-Id.  It is strongly recommended that the Acct-
+      Multi-Session-Id be a printable ASCII string.
+
+   A summary of the Acct-Session-Id attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Rigney                       Informational                     [Page 20]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+   Type
+
+      50 for Acct-Multi-Session-Id.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field SHOULD be a string of printable ASCII characters.
+
+5.12.  Acct-Link-Count
+
+   Description
+
+      This attribute gives the count of links which are known to have
+      been in a given multilink session at the time the accounting
+      record is generated.  The NAS MAY include the Acct-Link-Count
+      attribute in any Accounting-Request which might have multiple
+      links.
+
+   A summary of the Acct-Link-Count attribute format is show below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      51 for Acct-Link-Count.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets, and contains the number of links
+      seen so far in this Multilink Session.
+
+
+
+
+
+
+Rigney                       Informational                     [Page 21]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+      It may be used to make it easier for an accounting server to know
+      when it has all the records for a given Multilink session.  When
+      the number of Accounting-Requests received with Acct-Status-Type =
+      Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
+      Id's equals the largest value of Acct-Link-Count seen in those
+      Accounting-Requests, all Stop Accounting-Requests for that
+      Multilink Session have been received.
+
+      An example showing 8 Accounting-Requests should make things
+      clearer.  For clarity only the relevant attributes are shown, but
+      additional attributes containing accounting information will also
+      be present in the Accounting-Request.
+
+      Multi-Session-Id   Session-Id   Status-Type   Link-Count
+      "10"               "10"         Start         1
+      "10"               "11"         Start         2
+      "10"               "11"         Stop          2
+      "10"               "12"         Start         3
+      "10"               "13"         Start         4
+      "10"               "12"         Stop          4
+      "10"               "13"         Stop          4
+      "10"               "10"         Stop          4
+
+5.13.  Table of Attributes
+
+   The following table provides a guide to which attributes may be found
+   in Accounting-Request packets.  No attributes should be found in
+   Accounting-Response packets except Proxy-State and possibly Vendor-
+   Specific.
+
+                      #     Attribute
+                      0-1   User-Name
+                      0     User-Password
+                      0     CHAP-Password
+                      0-1   NAS-IP-Address [5]
+                      0-1   NAS-Port
+                      0-1   Service-Type
+                      0-1   Framed-Protocol
+                      0-1   Framed-IP-Address
+                      0-1   Framed-IP-Netmask
+                      0-1   Framed-Routing
+                      0+    Filter-Id
+                      0-1   Framed-MTU
+                      0+    Framed-Compression
+                      0+    Login-IP-Host
+                      0-1   Login-Service
+                      0-1   Login-TCP-Port
+                      0     Reply-Message
+
+
+
+Rigney                       Informational                     [Page 22]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+                      0-1   Callback-Number
+                      0-1   Callback-Id
+                      0+    Framed-Route
+                      0-1   Framed-IPX-Network
+                      0     State
+                      0+    Class
+                      0+    Vendor-Specific
+                      0-1   Session-Timeout
+                      0-1   Idle-Timeout
+                      0-1   Termination-Action
+                      0-1   Called-Station-Id
+                      0-1   Calling-Station-Id
+                      0-1   NAS-Identifier [4]
+                      0+    Proxy-State
+                      0-1   Login-LAT-Service
+                      0-1   Login-LAT-Node
+                      0-1   Login-LAT-Group
+                      0-1   Framed-AppleTalk-Link
+                      0-1   Framed-AppleTalk-Network
+                      0-1   Framed-AppleTalk-Zone
+                      1     Acct-Status-Type
+                      0-1   Acct-Delay-Time
+                      0-1   Acct-Input-Octets
+                      0-1   Acct-Output-Octets
+                      1     Acct-Session-Id
+                      0-1   Acct-Authentic
+                      0-1   Acct-Session-Time
+                      0-1   Acct-Input-Packets
+                      0-1   Acct-Output-Packets
+                      0-1   Acct-Terminate-Cause
+                      0+    Acct-Multi-Session-Id
+                      0+    Acct-Link-Count
+                      0     CHAP-Challenge
+                      0-1   NAS-Port-Type
+                      0-1   Port-Limit
+                      0-1   Login-LAT-Port
+
+
+   [5] An Accounting-Request MUST contain either a NAS-IP-Address or a
+   NAS-Identifier, and it is permitted (but not recommended) for it to
+   contain both.
+
+   The following table defines the above table entries.
+
+      0     This attribute MUST NOT be present
+      0+    Zero or more instances of this attribute MAY be present.
+      0-1   Zero or one instance of this attribute MAY be present.
+      1     Exactly one instance of this attribute MUST be present.
+
+
+
+Rigney                       Informational                     [Page 23]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+Security Considerations
+
+   Security issues are briefly discussed in sections concerning the
+   authenticator included in accounting requests and responses, using a
+   shared secret which is never sent over the network.
+
+References
+
+   [1]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+         USC/Information Sciences Institute, August 1980.
+
+   [2]   Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
+         1700, USC/Information Sciences Institute, October 1994.
+
+   [3]   Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm",
+         RFC 1321, MIT Laboratory for Computer Science, RSA Data
+         Security Inc., April 1992.
+
+   [4]   Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote
+         Authentication Dial In User Service (RADIUS)", RFC 2138,
+         April 1997.
+
+Acknowledgments
+
+   RADIUS and RADIUS Accounting were originally developed by Livingston
+   Enterprises for their PortMaster series of Network Access Servers.
+
+Chair's Address
+
+   The RADIUS working group can be contacted via the current chair:
+
+   Carl Rigney
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   Phone: +1 510 426 0770
+   EMail: cdr@livingston.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 24]
+
+RFC 2139                   RADIUS Accounting                  April 1997
+
+
+Author's Address
+
+   Questions about this memo can also be directed to:
+
+   Carl Rigney
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   EMail: cdr@livingston.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 25]
+
diff --git a/doc/rfc2548.txt b/doc/rfc2548.txt
new file mode 100644
index 0000000..35c83c3
--- /dev/null
+++ b/doc/rfc2548.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Network Working Group                                            G. Zorn
+Request for Comments: 2548                         Microsoft Corporation
+Category: Informational                                       March 1999
+
+
+              Microsoft Vendor-specific RADIUS Attributes
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   This document describes the set of Microsoft vendor-specific RADIUS
+   attributes.  These attributes are designed to support Microsoft
+   proprietary dial-up protocols and/or provide support for features
+   which is not provided by the standard RADIUS attribute set [3].  It
+   is expected that this memo will be updated whenever Microsoft defines
+   a new vendor-specific attribute, since its primary purpose is to
+   provide an open, easily accessible reference for third-parties
+   wishing to interoperate with Microsoft products.
+
+1.  Specification of Requirements
+
+   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+   "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
+   described in [2].
+
+2.  Attributes
+
+   The following sections describe sub-attributes which may be
+   transmitted in one or more RADIUS attributes of type Vendor-Specific
+   [3].  More than one sub-attribute MAY be transmitted in a single
+   Vendor-Specific Attribute; if this is done, the sub-attributes SHOULD
+   be packed as a sequence of Vendor-Type/Vendor-Length/Value triples
+   following the inital Type, Length and Vendor-ID fields.  The Length
+   field of the Vendor-Specific Attribute MUST be set equal to the sum
+   of the Vendor-Length fields of the sub-attributes contained in the
+   Vendor-Specific Attribute, plus six.  The Vendor-ID field of the
+   Vendor-Specific Attribute(s) MUST be set to decimal 311 (Microsoft).
+
+
+
+
+
+Zorn                         Informational                      [Page 1]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+2.1.  Attributes for Support of MS-CHAP Version 1
+
+2.1.1.  Introduction
+
+   Microsoft created Microsoft Challenge-Handshake Authentication
+   Protocol (MS-CHAP) [4] to authenticate remote Windows workstations,
+   providing the functionality to which LAN-based users are accustomed.
+   Where possible, MS-CHAP is consistent with standard CHAP [5], and the
+   differences are easily modularized.  Briefly, the differences between
+   MS-CHAP and standard CHAP are:
+
+      * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP
+        option 3, Authentication Protocol.
+
+      * The MS-CHAP Response packet is in a format designed for
+        compatibility with Microsoft Windows NT 3.5, 3.51 and 4.0,
+        Microsoft Windows95, and Microsoft LAN Manager 2.x networking
+        products.  The MS-CHAP format does not require the authenticator
+        to store a clear-text or reversibly encrypted password.
+
+      * MS-CHAP provides an authenticator-controlled authentication
+        retry mechanism.
+
+      * MS-CHAP provides an authenticator-controlled password changing
+        mechanism.
+
+      * MS-CHAP defines an extended  set of reason-for-failure codes,
+        returned in the Failure packet Message field.
+
+   The attributes defined in this section reflect these differences.
+
+2.1.2.  MS-CHAP-Challenge
+
+   Description
+
+      This Attribute contains the challenge sent by a NAS to a Microsoft
+      Challenge-Handshake Authentication Protocol (MS-CHAP) user.  It
+      MAY be used in both Access-Request and Access-Challenge packets.
+
+   A summary of the MS-CHAP-Challenge Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                      [Page 2]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |           String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      11 for MS-CHAP-Challenge.
+
+   Vendor-Length
+      > 2
+
+   String
+      The String field contains the MS-CHAP challenge.
+
+2.1.3.  MS-CHAP-Response
+
+   Description
+
+      This Attribute contains the response value provided by a PPP
+      Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP)
+      user in response to the challenge.  It is only used in Access-
+      Request packets.
+
+   A summary of the MS-CHAP-Response Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                      [Page 3]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |     Ident     |     Flags     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            LM-Response
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             LM-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             LM-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             LM-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             LM-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             LM-Response(cont)                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           NT-Response
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             NT-Response (cont)                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      1 for MS-CHAP-Response.
+
+   Vendor-Length
+      52
+
+   Ident
+      Identical to the PPP CHAP Identifier.
+
+   Flags
+      The Flags field is one octet in length.  If the Flags field is one
+      (0x01), the NT-Response field is to be used in preference to the
+      LM-Response field for authentication.  The LM-Response field MAY
+      still be used (if non-empty), but the NT-Response SHOULD be tried
+      first.  If it is zero, the NT-Response field MUST be ignored and
+      the LM-Response field used.
+
+
+
+
+
+Zorn                         Informational                      [Page 4]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   LM-Response
+      The LM-Response field is 24 octets in length and holds an encoded
+      function of the password and the received challenge.  If this
+      field is empty, it SHOULD be zero-filled.
+
+   NT-Response
+
+      The NT-Response field is 24 octets in length and holds an encoded
+      function of the password and the received challenge.  If this
+      field is empty, it SHOULD be zero-filled.
+
+2.1.4.  MS-CHAP-Domain
+
+   Description
+
+      The MS-CHAP-Domain Attribute indicates the Windows NT domain in
+      which the user was authenticated.  It MAY be included in both
+      Access-Accept and Accounting-Request packets.
+
+   A summary of the MS-CHAP-Domain Attribute format is given below.  The
+   fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |     Ident     |    String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      10 for MS-CHAP-Domain.
+
+   Vendor-Length
+      > 3
+
+   Ident
+      The Ident field is one octet and aids in matching requests and
+      replies.
+
+   String
+      This  field contains the name in ASCII of the Windows NT domain in
+      which the user was authenticated.
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                      [Page 5]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+2.1.5.  MS-CHAP-Error
+
+   Description
+
+      The MS-CHAP-Error Attribute contains error data related to the
+      preceding MS-CHAP exchange.  This Attribute may be used in both
+      MS-CHAP-V1 and MS-CHAP-V2 (see below) exchanges.  It is only used
+      in Access-Reject packets.
+
+   A summary of the MS-CHAP-Error Attribute format is given below.  The
+   fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |     Ident     |    String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      2 for MS-CHAP-Error.
+
+   Vendor-Length
+      > 3
+
+   Ident
+      The Ident field is one octet and aids in matching requests and
+      replies.
+
+   String
+      This field contains specially formatted ASCII text, which is
+      interpreted by the authenticating peer.
+
+2.1.6.  MS-CHAP-CPW-1
+
+   Description
+
+      This Attribute allows the user to change their password if it has
+      expired.  This Attribute is only used in Access-Request packets, and
+      should only be included if an MS-CHAP-Error attribute was included in
+      the immediately preceding Access-Reject packet, the String field of
+      the MS-CHAP-Error attribute indicated that the user password had
+      expired, and the MS-CHAP version is less than 2.
+
+   A summary of the MS-CHAP-CPW-1  Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+
+
+
+
+
+Zorn                         Informational                      [Page 6]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |     Code      |     Ident     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       LM-Old-Password
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         LM-Old-Password (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         LM-Old-Password (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         LM-Old-Password (cont)                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       LM-New-Password
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         LM-New-Password (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         LM-New-Password (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         LM-New-Password (cont)                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       NT-Old-Password
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         NT-Old-Password (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         NT-Old-Password (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         NT-Old-Password (cont)                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       NT-New-Password
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         NT-New-Password (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         NT-New-Password (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                         NT-New-Password (cont)                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     New-LM-Password-Length    |             Flags             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      3 for MS-CHAP-PW-1
+
+   Vendor-Length
+      72
+
+   Code
+      The Code field is one octet in length.  Its value is always 5.
+
+
+
+Zorn                         Informational                      [Page 7]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   Ident
+      The  Ident  field  is  one octet and aids in matching requests and
+      replies.
+
+   LM-Old-Password
+      The LM-Old-Password field is 16 octets in length.  It contains the
+      encrypted Lan Manager hash of the old password.
+
+   LM-New-Password
+      The LM-New-Password field is 16 octets in length.  It contains the
+      encrypted Lan Manager hash of the new password.
+
+   NT-Old-Password
+      The NT-Old-Password field is 16 octets in length.  It contains the
+      encrypted Lan Manager hash of the old password.
+
+   NT-New-Password
+      The NT-New-Password field is 16 octets in length.  It contains the
+      encrypted Lan Manager hash of the new password.
+
+   New-LM-Password-Length
+      The New-LM-Password-Length field is two octets in length and
+      contains the length in octets of the new LAN Manager-compatible
+      password.
+
+   Flags
+      The Flags field is two octets in length.  If the least significant
+      bit  of  the  Flags  field is one, this indicates that the NT-New-
+      Password and NT-Old-Password fields are valid and SHOULD be  used.
+      Otherwise,  the LM-New-Password and LM-Old-Password fields MUST be
+      used.
+
+2.1.7.  MS-CHAP-CPW-2
+
+   Description
+
+      This Attribute allows the user to change their password if it has
+      expired.  This Attribute is only used in Access-Request packets,
+      and should only be included if an MS-CHAP-Error attribute was
+      included in the immediately preceding Access-Reject packet, the
+      String field of the MS-CHAP-Error attribute indicated that the
+      user password had expired, and the MS-CHAP version is equal to 2.
+
+   A summary of the MS-CHAP-CPW-2  Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+
+
+
+
+
+Zorn                         Informational                      [Page 8]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |     Code      |     Ident     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Old-NT-Hash
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Old-NT-Hash (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Old-NT-Hash (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Old-NT-Hash (cont)                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Old-LM-Hash
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Old-LM-Hash(cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Old-LM-Hash(cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Old-LM-Hash(cont)                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         LM-Response
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           LM-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           LM-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           LM-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           LM-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           LM-Response (cont)                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          NT-Response
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
+                           NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
+                           NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           NT-Response (cont)                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             Flags             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Zorn                         Informational                      [Page 9]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   Vendor-Type
+      4 for MS-CHAP-PW-2
+
+   Vendor-Length
+      86
+
+   Code
+      6
+
+   Ident
+      The Ident field is one octet and aids in matching requests and
+      replies.  The value of this field MUST be identical to that in the
+      Ident field in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-
+      Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access-
+      Request packet.
+
+   Old-NT-Hash
+      The Old-NT-Hash field is 16 octets in length.  It contains the old
+      Windows NT password hash encrypted with the new Windows NT
+      password hash.
+
+   Old-LM-Hash
+      The Old-LM-Hash field is 16 octets in length.  It contains the old
+      Lan Manager password hash encrypted with the new Windows NT
+      password hash.
+
+   LM-Response
+      The LM-Response field is 24 octets in length and holds an encoded
+      function of the password and the received challenge.  If this
+      field is empty, it SHOULD be zero-filled.
+
+   NT-Response
+      The NT-Response field is 24 octets in length and holds an encoded
+      function of the password and the received challenge.  If this
+      field is empty, it SHOULD be zero-filled.
+
+   Flags
+      The Flags field is two octets in length.  If the least significant
+      bit (bit 0) of this field is one, the NT-Response field is to be
+      used in preference to the LM-Response field for authentication.
+      The LM-Response field MAY still be used (if present), but the NT-
+      Response SHOULD be tried first.  If least significant bit of the
+      field is zero, the NT-Response field MUST be ignored and the LM-
+      Response field used instead.  If bit 1 of the Flags field is one,
+      the Old-LM-Hash field is valid and SHOULD be used.  If this bit is
+      set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST
+      be included in the packet.
+
+
+
+
+Zorn                         Informational                     [Page 10]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+2.1.8.  MS-CHAP-LM-Enc-PW
+
+   Description
+
+      This Attribute contains the new Windows NT password encrypted with
+      the old LAN Manager password hash.  The encrypted Windows NT
+      password is 516 octets in length; since this is longer than the
+      maximum lengtth of a RADIUS attribute, the password must be split
+      into several attibutes for transmission.  A 2 octet sequence
+      number is included in the attribute to help preserve ordering of
+      the password fragments.
+
+      This Attribute is only used in Access-Request packets, in
+      conjunction with the MS-CHAP-CPW-2 attribute.  It should only be
+      included if an MS-CHAP-Error attribute was included in the
+      immediately preceding Access-Reject packet, the String field of
+      the MS-CHAP-Error attribute indicated that the user password had
+      expired, and the MS-CHAP version is 2 or greater.
+
+   A summary of the MS-CHAP-LM-Enc-PW Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |      Code     |     Ident     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Sequence-Number         |          String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      5 for MS-CHAP-LM-Enc-PW
+
+   Vendor-Length
+      > 6
+
+   Code 6.  Code is the same as for the MS-CHAP-PW-2 attribute.
+
+   Ident
+      The Ident field is one octet and aids in matching requests and
+      replies.  The value of this field MUST be identical in all
+      instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-
+      CHAP-PW-2 attributes which are present in the same Access-Request
+      packet.
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 11]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   Sequence-Number
+      The Sequence-Number field is two octets in length and indicates
+      which "chunk" of the encrypted password is contained in the
+      following String field.
+
+   String The String field contains a portion of the encrypted password.
+
+2.2.  MS-CHAP-NT-Enc-PW
+
+   Description
+
+      This Attribute contains the new Windows NT password encrypted with
+      the old Windows NT password hash.  The encrypted Windows NT
+      password is 516 octets in length; since this is longer than the
+      maximum lengtth of a RADIUS attribute, the password must be split
+      into several attibutes for transmission.  A 2 octet sequence
+      number is included in the attribute to help preserve ordering of
+      the password fragments.
+
+      This Attribute is only used in Access-Request packets, in conjunc-
+      tion with the MS-CHAP-CPW-2 and MS-CHAP2-CPW attributes.  It
+      should only be included if an MS-CHAP-Error attribute was included
+      in the immediately preceding Access-Reject packet, the String
+      field of the MS-CHAP-Error attribute indicated that the user
+      password had expired, and the MS-CHAP version is 2 or greater.
+
+   A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |      Code     |     Ident     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Sequence-Number        |           String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      6 for MS-CHAP-NT-Enc-PW
+
+   Vendor-Length
+      > 6
+
+   Code
+      6.  Code is the same as for the MS-CHAP-PW-2 attribute.
+
+
+
+
+
+
+Zorn                         Informational                     [Page 12]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   Ident
+      The Ident field is one octet and aids in matching requests and
+      replies.  The value of this field MUST be identical in all
+      instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-
+      CHAP-PW-2 attributes which are present in the same Access-Request
+      packet.
+
+   Sequence-Number
+      The Sequence-Number field is two octets in length and indicates
+      which "chunk" of the encrypted password is contained in the
+      following String field.
+
+   String
+      The String field contains a portion of the encrypted password.
+
+2.3.  Attributes for Support of MS-CHAP Version 2
+
+2.3.1.  Introduction
+
+   This section describes RADIUS attributes supporting version two of
+   Microsoft's PPP CHAP dialect (MS-CHAP-V2) [14].  MS-CHAP-V2 is
+   similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1)
+   [4].  Certain protocol fields have been deleted or reused but with
+   different semantics.  Where possible, MS-CHAP-V2 is consistent with
+   both MS-CHAP-V1 and standard CHAP [1].  Briefly, the differences
+   between MS-CHAP-V2 and MS-CHAP-V1 are:
+
+      * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP
+        option 3, Authentication Protocol.
+
+      * MS-CHAP-V2 provides mutual authentication between peers by
+        piggybacking a peer challenge on the Response packet and an
+        authenticator response on the Success packet.
+
+      * The calculation of the "Windows NT compatible challenge
+        response" sub-field in the Response packet has been changed to
+        include the peer challenge and the user name.
+
+      * In MS-CHAP-V1, the "LAN Manager compatible challenge response"
+        sub-field was always sent in the Response packet.  This field
+        has been replaced in MS-CHAP-V2 by the Peer-Challenge field.
+
+      * The format of the Message field in the Failure packet has been
+        changed.
+
+      * The Change Password (version 1) and Change Password (version 2)
+        packets are no longer supported. They have been replaced with a
+        single Change-Password packet.
+
+
+
+Zorn                         Informational                     [Page 13]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   The attributes defined in this section reflect these differences.
+
+2.3.2.  MS-CHAP2-Response
+
+   Description
+
+      This Attribute contains the response value provided by an MS-
+      CHAP-V2 peer in response to the challenge.  It is only used in
+      Access-Request packets.
+
+   A summary of the MS-CHAP2-Response Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |     Ident     |     Flags     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Peer-Challenge
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                            Peer-Challenge (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                            Peer-Challenge (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                            Peer-Challenge (cont)                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Reserved
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               Reserved (cont)                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Response
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               Response (cont)                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      25 for MS-CHAP2-Response.
+
+   Vendor-Length
+      52
+
+
+
+Zorn                         Informational                     [Page 14]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   Ident
+      Identical to the PPP MS-CHAP v2 Identifier.
+
+   Flags
+      The Flags field is one octet in length.  It is reserved for future
+      use and MUST be zero.
+
+   Peer-Challenge
+      The Peer-Challenge field is a 16-octet random number.
+
+   Reserved
+      This field is reserved for future use and MUST be zero.
+
+   Response
+      The Response field is 24 octets in length and holds an encoded
+      function of the password, the Peer-Challenge field and the
+      received challenge.
+
+2.3.3.  MS-CHAP2-Success
+
+   Description
+
+      This Attribute contains a 42-octet authenticator response string.
+      This string MUST be included in the Message field of the MS-CHAP-
+      V2 Success packet sent from the NAS to the peer.  This Attribute
+      is only used in Access-Accept packets.
+
+   A summary of the MS-CHAP2-Success Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |     Ident     |   String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      26 for MS-CHAP2-Success.
+
+   Vendor-Length
+      45
+
+   Ident
+      Identical to the PPP MS-CHAP v2 Identifier.
+
+   String
+      The 42-octet authenticator string (see above).
+
+
+
+
+Zorn                         Informational                     [Page 15]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+2.3.4.  MS-CHAP2-CPW
+
+   Description
+
+      This Attribute allows the user to change their password if it has
+      expired.  This Attribute is only used in conjunction with the MS-
+      CHAP-NT-Enc-PW attribute in Access-Request packets, and should
+      only be included if an MS-CHAP-Error attribute was included in the
+      immediately preceding Access-Reject packet, the String field of
+      the MS-CHAP-Error attribute indicated that the user password had
+      expired, and the MS-CHAP version is equal to 3.
+
+   A summary of the MS-CHAP-CPW-2 Attribute format is shown below.   The
+   fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 16]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |     Code      |     Ident     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Encrypted-Hash
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Encrypted-Hash (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Encrypted-Hash (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Encrypted-Hash (cont)                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Peer-Challenge
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Peer-Challenge (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Peer-Challenge (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Peer-Challenge (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Peer-Challenge (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                          Peer-Challenge (cont)                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          NT-Response
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
+                           NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
+                           NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           NT-Response (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           NT-Response (cont)                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             Flags             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      27 for MS-CHAP2-PW
+
+   Vendor-Length
+      70
+
+   Code
+      7
+
+
+
+Zorn                         Informational                     [Page 17]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   Ident
+      The Ident field is one octet and aids in matching requests and
+      replies.  The value of this field MUST be identical to that in the
+      Ident field in all instances of the MS-CHAP-NT-Enc-PW contained in
+      the Access-Request packet.
+
+   Encrypted-Hash
+      The Encrypted-Hash field is 16 octets in length.  It contains the
+      old Windows NT password hash encrypted with the new Windows NT
+      password hash.
+
+   NT-Response
+      The NT-Response field is 24 octets in length and holds an encoded
+      function of the new password, the Peer-Challenge field and the
+      received challenge.
+
+   Flags
+      The Flags field is two octets in length.  This field is reserved
+      for future use and MUST be zero.
+
+2.4.  Attributes for MPPE Support
+
+   This section describes a set of Attributes designed to support the
+   use of Microsoft Point-to-Point Encryption (MPPE) [6] in dial-up
+   networks.  MPPE is a means of representing Point to Point Protocol
+   (PPP) [7] packets in a encrypted form.  MPPE uses the RSA RC4 [8]
+   algorithm for encryption.  The length of the session key to be used
+   for initializing encryption tables can be negotiated; MPPE currently
+   supports 40 bit and 128 bit session keys.  MPPE is negotiated within
+   option 18 in the PPP Compression Control Protocol (CCP)[9], [10].
+
+2.4.1.  MS-CHAP-MPPE-Keys
+
+   Description
+
+      The MS-CHAP-MPPE-Keys Attribute contains two session keys for use
+      by the Microsoft Point-to-Point Encryption Protocol (MPPE).  This
+      Attribute is only included in Access-Accept packets.
+
+   A summary of the MS-CHAP-MPPE-Keys Attribute format is given below.
+   The fields are transmitted left to right.
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 18]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |           Keys
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             Keys (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             Keys (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             Keys (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             Keys (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             Keys (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             Keys (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                             Keys (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Keys (cont)          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      12 for MS-CHAP-MPPE-Keys.
+
+   Vendor-Length
+      34
+
+   Keys
+      The Keys field consists of two logical sub-fields: the LM-Key and
+      the NT-Key.  The LM-Key is eight octets in length and contains the
+      first eight bytes of the output of the function LmPasswordHash(P,
+      This hash is constructed as follows: let the plain-text password
+      be represented by P.
+
+      The NT-Key sub-field is sixteen octets in length and contains the
+      first sixteen octets of the hashed Windows NT password.  The
+      format of the plaintext Keys field is illustrated in the following
+      diagram:
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 19]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           LM-Key
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               LM-Key (cont)                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           NT-Key
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               NT-Key (cont)
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               NT-Key (cont)
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               NT-Key (cont)                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Padding
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                              Padding (cont)                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      The Keys field MUST be encrypted by the RADIUS server using the
+      same method defined for the User-Password Attribute [3].  Padding
+      is required because the method referenced above requires the field
+      to be encrypted to be a multiple of sixteen octets in length.
+
+   Implementation Note
+         This attribute should only be returned in response to an
+         Access-Request packet containing MS-CHAP attributes.
+
+2.4.2.  MS-MPPE-Send-Key
+
+   Description
+
+      The MS-MPPE-Send-Key Attribute contains a session key for use by
+      the Microsoft Point-to-Point Encryption Protocol (MPPE).  As the
+      name implies, this key is intended for encrypting packets sent
+      from the NAS to the remote host.  This Attribute is only included
+      in Access-Accept packets.
+
+   A summary of the MS-MPPE-Send-Key Attribute format is given below.
+   The fields are transmitted left to right.
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 20]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |             Salt
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      16 for MS-MPPE-Send-Key.
+
+   Vendor-Length
+      > 4
+
+   Salt
+      The Salt field is two octets in length and is used to ensure the
+      uniqueness of the keys used to encrypt each of the encrypted
+      attributes occurring in a given Access-Accept packet.  The most
+      significant bit (leftmost) of the Salt field MUST be set (1).  The
+      contents of each Salt field in a given Access-Accept packet MUST
+      be unique.
+
+   String
+      The plaintext String field consists of three logical sub-fields:
+      the Key-Length and Key sub-fields (both of which are required),
+      and the optional Padding sub-field.  The Key-Length sub-field is
+      one octet in length and contains the length of the unencrypted Key
+      sub-field.  The Key sub-field contains the actual encryption key.
+      If the combined length (in octets) of the unencrypted Key-Length
+      and Key sub-fields is not an even multiple of 16, then the Padding
+      sub-field MUST be present.  If it is present, the length of the
+      Padding sub-field is variable, between 1 and 15 octets.  The
+      String field MUST be encrypted as follows, prior to transmission:
+
+         Construct a plaintext version of the String field by concate-
+         nating the Key-Length and Key sub-fields.  If necessary, pad
+         the resulting string until its length (in octets) is an even
+         multiple of 16.  It is recommended that zero octets (0x00) be
+         used for padding.  Call this plaintext P.
+
+         Call the shared secret S, the pseudo-random 128-bit Request
+         Authenticator (from the corresponding Access-Request packet) R,
+         and the contents of the Salt field A.  Break P into 16 octet
+         chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
+         ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
+         Intermediate values b(1), b(2)...c(i) are required.  Encryption
+         is performed in the following manner ('+' indicates
+         concatenation):
+
+
+
+Zorn                         Informational                     [Page 21]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+      b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
+      b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
+                  .                      .
+                  .                      .
+                  .                      .
+      b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)
+
+      The   resulting   encrypted   String   field    will    contain
+      c(1)+c(2)+...+c(i).
+
+   On receipt, the process is reversed to yield the plaintext String.
+
+   Implementation Notes
+      It is possible that the length of the key returned may be larger
+      than needed for the encryption scheme in use.  In this case, the
+      RADIUS client is responsible for performing any necessary
+      truncation.
+
+      This attribute MAY be used to pass a key from an external (e.g.,
+      EAP [15]) server to the RADIUS server.  In this case, it may be
+      impossible for the external server to correctly encrypt the key,
+      since the RADIUS shared secret might be unavailable.  The external
+      server SHOULD, however, return the attribute as defined above; the
+      Salt field SHOULD be zero-filled and padding of the String field
+      SHOULD be done.  When the RADIUS server receives the attribute
+      from the external server, it MUST correctly set the Salt field and
+      encrypt the String field before transmitting it to the RADIUS
+      client.  If the channel used to communicate the MS-MPPE-Send-Key
+      attribute is not secure from eavesdropping, the attribute MUST be
+      cryptographically protected.
+
+2.4.3.  MS-MPPE-Recv-Key
+
+   Description
+
+      The MS-MPPE-Recv-Key Attribute contains a session key for use by
+      the Microsoft Point-to-Point Encryption Protocol (MPPE).  As the
+      name implies, this key is intended for encrypting packets received
+      by the NAS from the remote host.  This Attribute is only included
+      in Access-Accept packets.
+
+   A summary of the MS-MPPE-Recv-Key Attribute format is given below.
+   The fields are transmitted left to right.
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 22]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |             Salt
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                               String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      17 for MS-MPPE-Recv-Key.
+
+   Vendor-Length
+      > 4
+
+   Salt
+      The Salt field is two octets in length and is used to ensure the
+      uniqueness of the keys used to encrypt each of the encrypted
+      attributes occurring in a given Access-Accept packet.  The most
+      significant bit (leftmost) of the Salt field MUST be set (1).  The
+      contents of each Salt field in a given Access-Accept packet MUST
+      be unique.
+
+   String
+      The plaintext String field consists of three logical sub-fields:
+      the Key-Length and Key sub-fields (both of which are required),
+      and the optional Padding sub-field.  The Key-Length sub-field is
+      one octet in length and contains the length of the unencrypted Key
+      sub-field.  The Key sub-field contains the actual encryption key.
+      If the combined length (in octets) of the unencrypted Key-Length
+      and Key sub-fields is not an even multiple of 16, then the Padding
+      sub-field MUST be present.  If it is present, the length of the
+      Padding sub-field is variable, between 1 and 15 octets.  The
+      String field MUST be encrypted as follows, prior to transmission:
+
+         Construct a plaintext version of the String field by
+         concatenating the Key-Length and Key sub-fields.  If necessary,
+         pad the resulting string until its length (in octets) is an
+         even multiple of 16.  It is recommended that zero octets (0x00)
+         be used for padding.  Call this plaintext P.
+
+         Call the shared secret S, the pseudo-random 128-bit Request
+         Authenticator (from the corresponding Access-Request packet) R,
+         and the contents of the Salt field A.  Break P into 16 octet
+         chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
+         ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
+         Intermediate values b(1), b(2)...c(i) are required.  Encryption
+         is performed in the following manner ('+' indicates
+         concatenation):
+
+
+
+Zorn                         Informational                     [Page 23]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+         b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
+         b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
+                     .                      .
+                     .                      .
+                     .                      .
+         b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)
+
+         The resulting encrypted String field will contain
+         c(1)+c(2)+...+c(i).
+
+      On receipt, the process is reversed to yield the plaintext String.
+
+   Implementation Notes
+      It is possible that the length of the key returned may be larger
+      than needed for the encryption scheme in use.  In this case, the
+      RADIUS client is responsible for performing any necessary
+      truncation.
+
+      This attribute MAY be used to pass a key from an external (e.g.,
+      EAP [15]) server to the RADIUS server.  In this case, it may be
+      impossible for the external server to correctly encrypt the key,
+      since the RADIUS shared secret might be unavailable.  The external
+      server SHOULD, however, return the attribute as defined above; the
+      Salt field SHOULD be zero-filled and padding of the String field
+      SHOULD be done.  When the RADIUS server receives the attribute
+      from the external server, it MUST correctly set the Salt field and
+      encrypt the String field before transmitting it to the RADIUS
+      client.  If the channel used to communicate the MS-MPPE-Recv-Key
+      attribute is not secure from eavesdropping, the attribute MUST be
+      cryptographically protected.
+
+2.4.4.  MS-MPPE-Encryption-Policy
+
+   Description
+
+      The MS-MPPE-Encryption-Policy Attribute may be used to signify
+      whether the use of encryption is allowed or required.  If the
+      Policy field is equal to 1 (Encryption-Allowed), any or none of
+      the encryption types specified in the MS-MPPE-Encryption-Types
+      Attribute MAY be used.  If the Policy field is equal to 2
+      (Encryption-Required), any of the encryption types specified in
+      the MS-MPPE-Encryption-Types Attribute MAY be used, but at least
+      one MUST be used.
+
+   A summary of the MS-MPPE-Encryption-Policy Attribute format is given
+   below.  The fields are transmitted left to right.
+
+
+
+
+
+Zorn                         Informational                     [Page 24]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |             Policy
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Policy (cont)        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      7 for MS-MPPE-Encryption-Policy.
+
+   Vendor-Length
+      6
+
+   Policy
+      The Policy field is 4 octets in length.  Defined values are:
+
+         1      Encryption-Allowed 2      Encryption-Required
+
+2.4.5.  MS-MPPE-Encryption-Types
+
+   Description
+
+      The MS-MPPE-Encryption-Types Attribute is used to signify the
+      types of encryption available for use with MPPE.  It is a four
+      octet integer that is interpreted as a string of bits.
+
+   A summary of the MS-MPPE-Encryption-Policy Attribute format is given
+   below.  The fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |             Types
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+               Types (cont)        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      8 for MS-MPPE-Encryption-Types.
+
+   Vendor-Length
+      6
+
+   Policy
+      The Types field is 4 octets in length.  The following diagram
+      illustrates the Types field.
+
+
+
+
+Zorn                         Informational                     [Page 25]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+         3                   2                   1
+       1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                         |S|L| |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      If the L bit is set, RC4[5] encryption using a 40-bit key is
+      allowed.  If the S bit is set, RC4 encryption using a 128-bit key
+      is allowed.  If both the L and S bits are set, then either 40- or
+      128-bit keys may be used with the RC4 algorithm.
+
+2.5.  Attributes for BAP Support
+
+   This section describes a set of vendor-specific RADIUS attributes
+   designed to support the dynamic control of bandwidth allocation in
+   multilink PPP [11].  Attributes are defined that specify whether use
+   of the PPP Bandwidth Allocation Protocol (BAP) [12] is allowed or
+   required on incoming calls, the level of line capacity (expressed as
+   a percentage) below which utilization must fall before a link is
+   eligible to be dropped, and the length of time (in seconds) that a
+   link must be under-utilized before it is dropped.
+
+2.5.1.  MS-BAP-Usage
+
+   Description
+
+      This Attribute describes whether the use of BAP is allowed,
+      disallowed or required on new multilink calls.  It MAY be used in
+      Access-Accept packets.
+
+   A summary of the MS-BAP-Usage Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |            Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      13 for MS-BAP-Usage.
+
+   Vendor-Length
+      6
+
+
+
+
+
+Zorn                         Informational                     [Page 26]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   Value
+      The Value field is four octets.
+
+         0      BAP usage not allowed
+         1      BAP usage allowed
+         2      BAP usage required
+
+2.5.2.  MS-Link-Utilization-Threshold
+
+   Description
+
+      This Attribute represents the percentage of available bandwidth
+      utilization below which the link must fall before the link is
+      eligible for termination.  Permissible values for the MS-Link-
+      Utilization-Threshold Attribute are in the range 1-100, inclusive.
+      It is only used in Access-Accept packets.
+
+   A summary of the MS-Link-Utilization-Threshold Attribute format is
+   shown below.  The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |            Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      14 for MS-Link-Utilization-Threshold
+
+   Vendor-Length 6
+
+   Value The Value field is four octets in length and represents the
+      percentage of available bandwidth utilization below which the link
+      must fall before the link is eligible for termination.
+      Permissible values are in the range 1-100, inclusive.
+
+2.5.3.  MS-Link-Drop-Time-Limit
+
+   Description
+
+      The MS-Link-Drop-Time-Limit Attribute indicates the length of time
+      (in seconds) that a link must be underutilized before it is
+      dropped.  It MAY only be included in Access-Accept packets.
+
+   A summary of the MS-Link-Drop-Time-Limit Attribute format is given
+   below.  The fields are transmitted left to right.
+
+
+
+Zorn                         Informational                     [Page 27]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+             Value (cont)          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      15 for MS-Link-Drop-Time-Limit
+
+   Vendor-Length
+      6
+
+   Value
+      The Value field represents the number of seconds that a link must
+      be underutilized (i.e., display bandwidth utilization below the
+      threshold specified in the MS-Link-Utilization-Threshold
+      Attribute) before the link is dropped.
+
+2.6.  Attributes for ARAP Support
+
+   This section describes a set of Attributes designed to support the
+   Apple Remote Access Protocol (ARAP).
+
+2.6.1.  MS-Old-ARAP-Password
+
+   Description
+
+      The MS-Old-ARAP-Password Attribute is used to transmit the old
+      ARAP password during an ARAP password change operation.  It MAY be
+      included in Access-Request packets.
+
+   A summary of the MS-Old-ARAP-Password Attribute Attribute format is
+   given below.  The fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |          String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      19 for MS-Old-ARAP-Password Attribute
+
+   Vendor-Length
+      > 3
+
+
+
+
+Zorn                         Informational                     [Page 28]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   String
+      The String field is one or more octets.  It contains the old ARAP
+      password DES-encrypted using itself as the key.
+
+2.6.2.  MS-New-ARAP-Password
+
+   Description
+
+      The MS-New-ARAP-Password Attribute is used to transmit the new
+      ARAP password during an ARAP password change operation.  It MAY be
+      included in Access-Request packets.
+
+   A summary of the MS-New-ARAP-Password Attribute Attribute format is
+   given below.  The fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |          String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      20 for MS-New-ARAP-Password Attribute
+
+   Vendor-Length
+      > 3
+
+   String
+      The  String field is one or more octets.  It contains the new ARAP
+      password DES-encrypted using the old ARAP password as the key.
+
+2.6.3.  MS-ARAP-Password-Change-Reason
+
+   Description
+
+      The MS-ARAP-Password-Change-Reason Attribute is used to indicate
+      reason for a server-initiated password change.  It MAY be included
+      in Access-Challenge packets.
+
+   A summary of the MS-ARAP-Password-Change-Reason Attribute format is
+   given below.  The fields are transmitted left to right.
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 29]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |             Why
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+               Why (cont)          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      21 for MS-ARAP-Password-Change-Reason
+
+   Vendor-Length
+      6
+
+   Why
+      The Why field is 4 octets in length.  The following values are
+      defined:
+         Just-Change-Password            1
+         Expired-Password                2
+         Admin-Requires-Password-Change  3
+         Password-Too-Short              4
+
+2.6.4.  MS-ARAP-Challenge
+
+   Description
+
+      This attribute is only present in an Access-Request packet
+      containing a Framed-Protocol Attribute with the value 3 (ARAP).
+
+   A summary of the MS-ARAP-Challenge Attribute format is given below.
+   The fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |           Challenge
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                            Challenge (cont)                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Challenge (cont)       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      33 for MS-ARAP-Challenge
+
+   Vendor-Length
+      10
+
+
+
+
+Zorn                         Informational                     [Page 30]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   Value
+      The Challenge Field is 8 octets in length.  It contains the
+      challenge (as two 4-octet quantities) sent by the NAS to the peer.
+
+2.7.  Miscellaneous Attributes
+
+   This section describes attributes which do not fall into any
+   particular category, but are used in the identification and operation
+   of Microsoft remote access products.
+
+2.7.1.  MS-RAS-Vendor
+
+   Description
+
+      The MS-RAS-Vendor Attribute is used to indicate the manufacturer
+      of the RADIUS client machine.  It MAY be included in both Access-
+      Request and Accounting-Request packets.
+
+   A summary of the MS-RAS-Vendor Attribute format is given below.  The
+   fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |           Vendor-ID
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           Vendor-ID (cont)        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      9 for MS-RAS-Vendor
+
+   Vendor-Length
+      6
+
+   Vendor-ID
+      The Vendor-ID field is 4 octets in length.  The high-order octet
+      is 0 and the low-order 3 octets are the SMI Network Management
+      Private Enterprise Code of the Vendor in network byte order, as
+      defined in the Assigned Numbers RFC [13].
+
+2.7.2.  MS-RAS-Version
+
+   Description
+
+      The MS-RAS-Version Attribute is used to indicate the version of
+      the RADIUS client software.  This attribute SHOULD be included in
+      packets containing an MS-RAS-Vendor Attribute; it SHOULD NOT be
+
+
+
+Zorn                         Informational                     [Page 31]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+      sent in packets which do not contain an MS-RAS-Vendor Attribute.
+      It MAY be included in both Access-Request and Accounting-Request
+      packets.
+
+   A summary of the MS-RAS-Version Attribute format is given below.  The
+   fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |          String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      18 for MS-RAS-Version
+
+   Vendor-Length
+      > 3
+
+   String
+      The  String field is one or more octets.  The actual format of the
+      information is vendor specific, and a robust implementation SHOULD
+      support the field as undistinguished octets.
+
+2.7.3.  MS-Filter
+
+   Description
+
+      The MS-Filter Attribute is used to transmit traffic filters.  It
+      MAY be included in both Access-Accept and Accounting-Request
+      packets.
+
+      If multiple MS-Filter Attributes are contained within a packet,
+      they MUST be in order and they MUST be consecutive attributes in
+      the packet.
+
+   A summary of the MS-Filter Attribute format is given below.  The
+   fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |           Filter...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      22 for MS-Filter Attribute
+
+
+
+
+Zorn                         Informational                     [Page 32]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   Vendor-Length
+      > 3
+
+   Filter
+      The Filter field is one or more octets.  It contains a sequence of
+      undifferentiated octets.
+
+      If multiple MS-Filter Attributes occur in a single Access-Accept
+      packet, the Filter field from each MUST be concatenated in the
+      order received to form the actual filter.
+
+2.7.4.  MS-Acct-Auth-Type
+
+   Description
+
+      The MS-Acct-Auth-Type Attribute is used to represent the method
+      used to authenticate the dial-up user.  It MAY be included in
+      Accounting-Request packets.
+
+   A summary of the MS-Acct-Auth-Type Attribute format is given below.
+   The fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |           Auth-Type
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Auth-Type (cont)       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      23 for MS-Acct-Auth-Type
+
+   Vendor-Length
+      6
+
+   Auth-Type
+      The Auth-Type field is 4 octets in length.  The following values
+      are defined for this field:
+
+         PAP               1
+         CHAP              2
+         MS-CHAP-1         3
+         MS-CHAP-2         4
+         EAP               5
+
+
+
+
+
+
+Zorn                         Informational                     [Page 33]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+2.7.5.  MS-Acct-EAP-Type
+
+   Description
+
+      The MS-Acct-EAP-Type Attribute is used to represent the Extensible
+      Authentication Protocol (EAP) [15] type used to authenticate the
+      dial-up user.  It MAY be included in Accounting-Request packets.
+
+   A summary of the MS-Acct-EAP-Type Attribute format is given below.
+   The fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |           EAP-Type
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+             EAP-Type (cont)       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      24 for MS-Acct-EAP-Type
+
+   Vendor-Length
+      6
+
+   Auth-Type
+      The EAP-Type field is 4 octets in length.  The following values
+      are currently defined for this field:
+
+         MD5                    4
+         OTP                    5
+         Generic Token Card     6
+         TLS                    13
+
+2.7.6.  MS-Primary-DNS-Server
+
+   Description
+
+      The MS-Primary-DNS-Server Attribute is used to indicate the
+      address of the primary Domain Name Server (DNS) [16, 17] server to
+      be used by the PPP peer.  It MAY be included in both Access-Accept
+      and Accounting-Request packets.
+
+   A summary of the MS-Primary-DNS-Server Attribute format is given
+   below.  The fields are transmitted left to right.
+
+
+
+
+
+
+Zorn                         Informational                     [Page 34]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |           IP-Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           IP-Address (cont)       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      28 for MS-Primary-DNS-Server
+
+   Vendor-Length
+      6
+
+   IP-Address
+      The IP-Address field is 4 octets in length.  It contains the IP
+      address of the primary DNS server.
+
+2.7.7.  MS-Secondary-DNS-Server
+
+   Description
+
+      The MS-Secondary-DNS-Server Attribute is used to indicate the
+      address of the secondary DNS server to be used by the PPP peer.
+      It MAY be included in both Access-Accept and Accounting-Request
+      packets.
+
+   A summary of the MS-Secondary-DNS-Server Attribute format is given
+   below.  The fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |           IP-Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           IP-Address (cont)       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      29 for MS-Secondary-DNS-Server
+
+   Vendor-Length
+      6
+
+   IP-Address
+      The IP-Address field is 4 octets in length.  It contains the IP
+      address of the secondary DNS server.
+
+
+
+
+Zorn                         Informational                     [Page 35]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+2.7.8.  MS-Primary-NBNS-Server
+
+   Description
+
+      The MS-Primary-NBNS-Server Attribute is used to indicate the
+      address of the primary NetBIOS Name Server (NBNS) [18] server to
+      be used by the PPP peer.  It MAY be included in both Access-Accept
+      and Accounting-Request packets.
+
+   A summary of the MS-Primary-MBNS-Server Attribute format is given
+   below.  The fields are transmitted left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |           IP-Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           IP-Address (cont)       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      30 for MS-Primary-NBNS-Server
+
+   Vendor-Length
+      6
+
+   IP-Address
+      The IP-Address field is 4 octets in length.  It contains the IP
+      address of the primary NBNS server.
+
+2.7.9.  MS-Secondary-NBNS-Server
+
+   Description
+
+      The MS-Secondary-NBNS-Server Attribute is used to indicate the
+      address of the secondary DNS server to be used by the PPP peer.
+      It MAY be included in both Access-Accept and Accounting-Request
+      packets.
+
+   A summary of the MS-Secondary-NBNS-Server Attribute format is given
+   below.  The fields are transmitted left to right.
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 36]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Vendor-Type  | Vendor-Length |           IP-Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           IP-Address (cont)       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Vendor-Type
+      31 for MS-Secondary-NBNS-Server
+
+   Vendor-Length
+      6
+
+   IP-Address
+      The IP-Address field is 4 octets in length.  It contains the IP
+      address of the secondary NBNS server.
+
+3.  Table of Attributes
+
+   The following table provides a guide to which of the above attributes
+   may be found in which kinds of packets, and in what quantity.
+
+ Request Accept Reject Challenge Acct-Request #  Attribute
+ 0-1     0      0      0         0             1 MS-CHAP-Response
+ 0       0      0-1    0         0             2 MS-CHAP-Error
+ 0-1     0      0      0         0             3 MS-CHAP-CPW-1
+ 0-1     0      0      0         0             4 MS-CHAP-CPW-2
+ 0+      0      0      0         0             5 MS-CHAP-LM-Enc-PW
+ 0+      0      0      0         0             6 MS-CHAP-NT-Enc-PW
+ 0       0-1    0      0         0             7 MS-MPPE-Encryption-
+                                                 Policy
+ 0       0-1    0      0         0             8 MS-MPPE-Encryption-Type
+ 0-1     0      0      0         0-1           9 MS-RAS-Vendor
+ 0       0-1    0      0         0-1          10 MS-CHAP-Domain
+ 0-1     0      0      0-1       0            11 MS-CHAP-Challenge
+ 0       0-1    0      0         0            12 MS-CHAP-MPPE-Keys
+ 0       0-1    0      0         0            13 MS-BAP-Usage
+ 0       0-1    0      0         0            14 MS-Link-Utilization-
+                                                 Threshold
+ 0       0-1    0      0         0            15 MS-Link-Drop-Time-Limit
+ 0       0-1    0      0         0            16 MS-MPPE-Send-Key
+ 0       0-1    0      0         0            17 MS-MPPE-Recv-Key
+ 0-1     0      0      0         0-1          18 MS-RAS-Version
+ 0-1     0      0      0         0            19 MS-Old-ARAP-Password
+ 0-1     0      0      0         0            20 MS-New-ARAP-Password
+ 0       0      0      0-1       0            21 MS-ARAP-PW-Change-
+                                                 Reason
+
+
+
+Zorn                         Informational                     [Page 37]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+ 0       0+     0      0         0+           22 MS-Filter
+ 0       0      0      0         0-1          23 MS-Acct-Auth-Type
+ 0       0      0      0         0-1          24 MS-Acct-EAP-Type
+ 0-1     0      0      0         0            25 MS-CHAP2-Response
+ 0       0-1    0      0         0            26 MS-CHAP2-Success
+ 0-1     0      0      0         0            27 MS-CHAP2-CPW
+ 0       0-1    0      0         0-1          28 MS-Primary-DNS-Server
+ 0       0-1    0      0         0-1          29 MS-Secondary-DNS-Server
+ 0       0-1    0      0         0-1          30 MS-Primary-NBNS-Server
+ 0       0-1    0      0         0-1          31 MS-Secondary-NBNS-
+                                                 Server
+ 0-1     0      0      0         0            33 MS-ARAP-Challenge
+
+The following table defines the meaning of the above table entries.
+
+0     This attribute MUST NOT be present in packet.
+0+    Zero or more instances of this attribute MAY be present in packet.
+0-1   Zero or one instance of this attribute MAY be present in packet.
+
+4.  Security Considerations
+
+   MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks.  User
+   passwords should be chosen with care, and be of sufficient length to
+   deter easy guessing.
+
+   Although the scheme used to protect the Keys field of the MS-CHAP-
+   MPPE-Keys, MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes is
+   believed to be relatively secure on the wire, RADIUS proxies will
+   decrypt and re-encrypt the field for forwarding.  Therefore, these
+   attributes SHOULD NOT be used on networks where untrusted RADIUS
+   proxies reside.
+
+5.  Acknowledgements
+
+   Thanks to Carl Rigney (cdr@livingston.com), Ashwin Palekar (ash-
+   winp@microsoft.com), Aydin Edguer (edguer@MorningStar.com), Narendra
+   Gidwani (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com),
+   Pat Calhoun (pcalhoun@eng.sun.com), Dave Mitton
+   (dmitton@baynetworks.com), Paul Funk (paul@funk.com), Gurdeep Singh
+   Pall (gurdeep@microsoft.com), Stephen Bensley (sbens@microsoft.com),
+   and Don Rule (don-aldr@microsoft.com) for useful suggestions and
+   editorial feedback.
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 38]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+6.  Editor's Address
+
+   Questions about this memo can be directed to:
+
+   Glen Zorn
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, Washington 98052
+
+   Phone: +1 425 703 1559
+   Fax:   +1 425 936 7329
+   EMail: glennz@microsoft.com
+
+7.  References
+
+   [1]  Simpson, W., "PPP Challenge Handshake Authentication
+        Protocol (CHAP)", RFC 1994, August 1996.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
+        Access Dial In User Service", RFC 2138, April 1997.
+
+   [4]  Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433,
+        October 1998.
+
+   [5]  Simpson, W., "PPP Challenge Handshake Authentication Protocol
+        (CHAP)", RFC 1994, August 1996.
+
+   [6]  Zorn, G. and G. Pall, "Microsoft Point-to-Point Encryption
+        (MPPE) Protocol", Work in Progress.
+
+   [7]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
+        1661, July 1994.
+
+   [8]  RC4 is a proprietary encryption algorithm available under
+        license from RSA Data Security Inc.  For licensing information,
+        contact:
+               RSA Data Security, Inc.
+               100 Marine Parkway
+               Redwood City, CA 94065-1031
+
+   [9]  Pall, G., "Microsoft Point-to-Point Compression (MPPC)
+        Protocol", RFC 2118, March 1997.
+
+   [10] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
+        1962, June 1996.
+
+
+
+Zorn                         Informational                     [Page 39]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+   [11] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
+        "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
+
+   [12] Richards, C. and K. Smith, "The PPP Bandwidth Allocation
+        Protocol (BAP) The PPP Bandwidth Allocation Control Protocol
+        (BACP)", RFC 2125, March 1997.
+
+   [13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+        October 1994.
+
+   [14] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", Work in
+        Progress.
+
+   [15] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
+        Protocol (EAP)", RFC 2284, March 1998.
+
+   [16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+        13, RFC 1034, USC/ISI, November 1987.
+
+   [17] Mockapetris, P., "Domain Names - Implementation and
+        Specification", STD 13, RFC 1035, November 1987.
+
+   [18] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS
+        Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002,
+        March 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 40]
+
+RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zorn                         Informational                     [Page 41]
+
diff --git a/doc/rfc2865.txt b/doc/rfc2865.txt
new file mode 100644
index 0000000..10ec231
--- /dev/null
+++ b/doc/rfc2865.txt
@@ -0,0 +1,4259 @@
+
+
+
+
+
+
+Network Working Group                                          C. Rigney
+Request for Comments: 2865                                    S. Willens
+Obsoletes: 2138                                               Livingston
+Category: Standards Track                                      A. Rubens
+                                                                   Merit
+                                                              W. Simpson
+                                                              Daydreamer
+                                                               June 2000
+
+
+          Remote Authentication Dial In User Service (RADIUS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+IESG Note:
+
+   This protocol is widely implemented and used.  Experience has shown
+   that it can suffer degraded performance and lost data when used in
+   large scale systems, in part because it does not include provisions
+   for congestion control.  Readers of this document may find it
+   beneficial to track the progress of the IETF's AAA working group,
+   which may develop a successor protocol that better addresses the
+   scaling and congestion control issues.
+
+Abstract
+
+   This document describes a protocol for carrying authentication,
+   authorization, and configuration information between a Network Access
+   Server which desires to authenticate its links and a shared
+   Authentication Server.
+
+Implementation Note
+
+   This memo documents the RADIUS protocol.  The early deployment of
+   RADIUS was done using UDP port number 1645, which conflicts with the
+   "datametrics" service.  The officially assigned port number for
+   RADIUS is 1812.
+
+
+
+
+Rigney, et al.              Standards Track                     [Page 1]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+Table of Contents
+
+   1.     Introduction ..........................................    3
+      1.1       Specification of Requirements ...................    4
+      1.2       Terminology .....................................    5
+   2.     Operation .............................................    5
+      2.1       Challenge/Response ..............................    7
+      2.2       Interoperation with PAP and CHAP ................    8
+      2.3       Proxy ...........................................    8
+      2.4       Why UDP? ........................................   11
+      2.5       Retransmission Hints ............................   12
+      2.6       Keep-Alives Considered Harmful ..................   13
+   3.     Packet Format .........................................   13
+   4.     Packet Types ..........................................   17
+      4.1       Access-Request ..................................   17
+      4.2       Access-Accept ...................................   18
+      4.3       Access-Reject ...................................   20
+      4.4       Access-Challenge ................................   21
+   5.     Attributes ............................................   22
+      5.1       User-Name .......................................   26
+      5.2       User-Password ...................................   27
+      5.3       CHAP-Password ...................................   28
+      5.4       NAS-IP-Address ..................................   29
+      5.5       NAS-Port ........................................   30
+      5.6       Service-Type ....................................   31
+      5.7       Framed-Protocol .................................   33
+      5.8       Framed-IP-Address ...............................   34
+      5.9       Framed-IP-Netmask ...............................   34
+      5.10      Framed-Routing ..................................   35
+      5.11      Filter-Id .......................................   36
+      5.12      Framed-MTU ......................................   37
+      5.13      Framed-Compression ..............................   37
+      5.14      Login-IP-Host ...................................   38
+      5.15      Login-Service ...................................   39
+      5.16      Login-TCP-Port ..................................   40
+      5.17      (unassigned) ....................................   41
+      5.18      Reply-Message ...................................   41
+      5.19      Callback-Number .................................   42
+      5.20      Callback-Id .....................................   42
+      5.21      (unassigned) ....................................   43
+      5.22      Framed-Route ....................................   43
+      5.23      Framed-IPX-Network ..............................   44
+      5.24      State ...........................................   45
+      5.25      Class ...........................................   46
+      5.26      Vendor-Specific .................................   47
+      5.27      Session-Timeout .................................   48
+      5.28      Idle-Timeout ....................................   49
+      5.29      Termination-Action ..............................   49
+
+
+
+Rigney, et al.              Standards Track                     [Page 2]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+      5.30      Called-Station-Id ...............................   50
+      5.31      Calling-Station-Id ..............................   51
+      5.32      NAS-Identifier ..................................   52
+      5.33      Proxy-State .....................................   53
+      5.34      Login-LAT-Service ...............................   54
+      5.35      Login-LAT-Node ..................................   55
+      5.36      Login-LAT-Group .................................   56
+      5.37      Framed-AppleTalk-Link ...........................   57
+      5.38      Framed-AppleTalk-Network ........................   58
+      5.39      Framed-AppleTalk-Zone ...........................   58
+      5.40      CHAP-Challenge ..................................   59
+      5.41      NAS-Port-Type ...................................   60
+      5.42      Port-Limit ......................................   61
+      5.43      Login-LAT-Port ..................................   62
+      5.44      Table of Attributes .............................   63
+   6.     IANA Considerations ...................................   64
+      6.1       Definition of Terms .............................   64
+      6.2       Recommended Registration Policies ...............   65
+   7.     Examples ..............................................   66
+      7.1       User Telnet to Specified Host ...................   66
+      7.2       Framed User Authenticating with CHAP ............   67
+      7.3       User with Challenge-Response card ...............   68
+   8.     Security Considerations ...............................   71
+   9.     Change Log ............................................   71
+   10.    References ............................................   73
+   11.    Acknowledgements ......................................   74
+   12.    Chair's Address .......................................   74
+   13.    Authors' Addresses ....................................   75
+   14.    Full Copyright Statement ..............................   76
+
+1.  Introduction
+
+   This document obsoletes RFC 2138 [1].  A summary of the changes
+   between this document and RFC 2138 is available in the "Change Log"
+   appendix.
+
+   Managing dispersed serial line and modem pools for large numbers of
+   users can create the need for significant administrative support.
+   Since modem pools are by definition a link to the outside world, they
+   require careful attention to security, authorization and accounting.
+   This can be best achieved by managing a single "database" of users,
+   which allows for authentication (verifying user name and password) as
+   well as configuration information detailing the type of service to
+   deliver to the user (for example, SLIP, PPP, telnet, rlogin).
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                     [Page 3]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Key features of RADIUS are:
+
+   Client/Server Model
+
+      A Network Access Server (NAS) operates as a client of RADIUS.  The
+      client is responsible for passing user information to designated
+      RADIUS servers, and then acting on the response which is returned.
+
+      RADIUS servers are responsible for receiving user connection
+      requests, authenticating the user, and then returning all
+      configuration information necessary for the client to deliver
+      service to the user.
+
+      A RADIUS server can act as a proxy client to other RADIUS servers
+      or other kinds of authentication servers.
+
+   Network Security
+
+      Transactions between the client and RADIUS server are
+      authenticated through the use of a shared secret, which is never
+      sent over the network.  In addition, any user passwords are sent
+      encrypted between the client and RADIUS server, to eliminate the
+      possibility that someone snooping on an unsecure network could
+      determine a user's password.
+
+   Flexible Authentication Mechanisms
+
+      The RADIUS server can support a variety of methods to authenticate
+      a user.  When it is provided with the user name and original
+      password given by the user, it can support PPP PAP or CHAP, UNIX
+      login, and other authentication mechanisms.
+
+   Extensible Protocol
+
+      All transactions are comprised of variable length Attribute-
+      Length-Value 3-tuples.  New attribute values can be added without
+      disturbing existing implementations of the protocol.
+
+1.1.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [2].  These key
+   words mean the same thing whether capitalized or not.
+
+   An implementation is not compliant if it fails to satisfy one or more
+   of the must or must not requirements for the protocols it implements.
+   An implementation that satisfies all the must, must not, should and
+
+
+
+Rigney, et al.              Standards Track                     [Page 4]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   should not requirements for its protocols is said to be
+   "unconditionally compliant"; one that satisfies all the must and must
+   not requirements but not all the should or should not requirements
+   for its protocols is said to be "conditionally compliant".
+
+   A NAS that does not implement a given service MUST NOT implement the
+   RADIUS attributes for that service.  For example, a NAS that is
+   unable to offer ARAP service MUST NOT implement the RADIUS attributes
+   for ARAP.  A NAS MUST treat a RADIUS access-accept authorizing an
+   unavailable service as an access-reject instead.
+
+1.2.  Terminology
+
+   This document frequently uses the following terms:
+
+   service   The NAS provides a service to the dial-in user, such as PPP
+             or Telnet.
+
+   session   Each service provided by the NAS to a dial-in user
+             constitutes a session, with the beginning of the session
+             defined as the point where service is first provided and
+             the end of the session defined as the point where service
+             is ended.  A user may have multiple sessions in parallel or
+             series if the NAS supports that.
+
+   silently discard
+             This means the implementation discards the packet without
+             further processing.  The implementation SHOULD provide the
+             capability of logging the error, including the contents of
+             the silently discarded packet, and SHOULD record the event
+             in a statistics counter.
+
+2.  Operation
+
+   When a client is configured to use RADIUS, any user of the client
+   presents authentication information to the client.  This might be
+   with a customizable login prompt, where the user is expected to enter
+   their username and password.  Alternatively, the user might use a
+   link framing protocol such as the Point-to-Point Protocol (PPP),
+   which has authentication packets which carry this information.
+
+   Once the client has obtained such information, it may choose to
+   authenticate using RADIUS.  To do so, the client creates an "Access-
+   Request" containing such Attributes as the user's name, the user's
+   password, the ID of the client and the Port ID which the user is
+   accessing.  When a password is present, it is hidden using a method
+   based on the RSA Message Digest Algorithm MD5 [3].
+
+
+
+
+Rigney, et al.              Standards Track                     [Page 5]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   The Access-Request is submitted to the RADIUS server via the network.
+   If no response is returned within a length of time, the request is
+   re-sent a number of times.  The client can also forward requests to
+   an alternate server or servers in the event that the primary server
+   is down or unreachable.  An alternate server can be used either after
+   a number of tries to the primary server fail, or in a round-robin
+   fashion.  Retry and fallback algorithms are the topic of current
+   research and are not specified in detail in this document.
+
+   Once the RADIUS server receives the request, it validates the sending
+   client.  A request from a client for which the RADIUS server does not
+   have a shared secret MUST be silently discarded.  If the client is
+   valid, the RADIUS server consults a database of users to find the
+   user whose name matches the request.  The user entry in the database
+   contains a list of requirements which must be met to allow access for
+   the user.  This always includes verification of the password, but can
+   also specify the client(s) or port(s) to which the user is allowed
+   access.
+
+   The RADIUS server MAY make requests of other servers in order to
+   satisfy the request, in which case it acts as a client.
+
+   If any Proxy-State attributes were present in the Access-Request,
+   they MUST be copied unmodified and in order into the response packet.
+   Other Attributes can be placed before, after, or even between the
+   Proxy-State attributes.
+
+   If any condition is not met, the RADIUS server sends an "Access-
+   Reject" response indicating that this user request is invalid.  If
+   desired, the server MAY include a text message in the Access-Reject
+   which MAY be displayed by the client to the user.  No other
+   Attributes (except Proxy-State) are permitted in an Access-Reject.
+
+   If all conditions are met and the RADIUS server wishes to issue a
+   challenge to which the user must respond, the RADIUS server sends an
+   "Access-Challenge" response.  It MAY include a text message to be
+   displayed by the client to the user prompting for a response to the
+   challenge, and MAY include a State attribute.
+
+   If the client receives an Access-Challenge and supports
+   challenge/response it MAY display the text message, if any, to the
+   user, and then prompt the user for a response.  The client then re-
+   submits its original Access-Request with a new request ID, with the
+   User-Password Attribute replaced by the response (encrypted), and
+   including the State Attribute from the Access-Challenge, if any.
+   Only 0 or 1 instances of the State Attribute SHOULD be
+
+
+
+
+
+Rigney, et al.              Standards Track                     [Page 6]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   present in a request.  The server can respond to this new Access-
+   Request with either an Access-Accept, an Access-Reject, or another
+   Access-Challenge.
+
+   If all conditions are met, the list of configuration values for the
+   user are placed into an "Access-Accept" response.  These values
+   include the type of service (for example: SLIP, PPP, Login User) and
+   all necessary values to deliver the desired service.  For SLIP and
+   PPP, this may include values such as IP address, subnet mask, MTU,
+   desired compression, and desired packet filter identifiers.  For
+   character mode users, this may include values such as desired
+   protocol and host.
+
+2.1.  Challenge/Response
+
+   In challenge/response authentication, the user is given an
+   unpredictable number and challenged to encrypt it and give back the
+   result. Authorized users are equipped with special devices such as
+   smart cards or software that facilitate calculation of the correct
+   response with ease. Unauthorized users, lacking the appropriate
+   device or software and lacking knowledge of the secret key necessary
+   to emulate such a device or software, can only guess at the response.
+
+   The Access-Challenge packet typically contains a Reply-Message
+   including a challenge to be displayed to the user, such as a numeric
+   value unlikely ever to be repeated. Typically this is obtained from
+   an external server that knows what type of authenticator is in the
+   possession of the authorized user and can therefore choose a random
+   or non-repeating pseudorandom number of an appropriate radix and
+   length.
+
+   The user then enters the challenge into his device (or software) and
+   it calculates a response, which the user enters into the client which
+   forwards it to the RADIUS server via a second Access-Request.  If the
+   response matches the expected response the RADIUS server replies with
+   an Access-Accept, otherwise an Access-Reject.
+
+   Example: The NAS sends an Access-Request packet to the RADIUS Server
+   with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
+   just be a fixed string like "challenge" or ignored).  The server
+   sends back an Access-Challenge packet with State and a Reply-Message
+   along the lines of "Challenge 12345678, enter your response at the
+   prompt" which the NAS displays.  The NAS prompts for the response and
+   sends a NEW Access-Request to the server (with a new ID) with NAS-
+   Identifier, NAS-Port, User-Name, User-Password (the response just
+   entered by the user, encrypted), and the same State Attribute that
+
+
+
+
+
+Rigney, et al.              Standards Track                     [Page 7]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   came with the Access-Challenge.  The server then sends back either an
+   Access-Accept or Access-Reject based on whether the response matches
+   the required value, or it can even send another Access-Challenge.
+
+2.2.  Interoperation with PAP and CHAP
+
+   For PAP, the NAS takes the PAP ID and password and sends them in an
+   Access-Request packet as the User-Name and User-Password. The NAS MAY
+   include the Attributes Service-Type = Framed-User and Framed-Protocol
+   = PPP as a hint to the RADIUS server that PPP service is expected.
+
+   For CHAP, the NAS generates a random challenge (preferably 16 octets)
+   and sends it to the user, who returns a CHAP response along with a
+   CHAP ID and CHAP username.  The NAS then sends an Access-Request
+   packet to the RADIUS server with the CHAP username as the User-Name
+   and with the CHAP ID and CHAP response as the CHAP-Password
+   (Attribute 3).  The random challenge can either be included in the
+   CHAP-Challenge attribute or, if it is 16 octets long, it can be
+   placed in the Request Authenticator field of the Access-Request
+   packet.  The NAS MAY include the Attributes Service-Type = Framed-
+   User and Framed-Protocol = PPP as a hint to the RADIUS server that
+   PPP service is expected.
+
+   The RADIUS server looks up a password based on the User-Name,
+   encrypts the challenge using MD5 on the CHAP ID octet, that password,
+   and the CHAP challenge (from the CHAP-Challenge attribute if present,
+   otherwise from the Request Authenticator), and compares that result
+   to the CHAP-Password.  If they match, the server sends back an
+   Access-Accept, otherwise it sends back an Access-Reject.
+
+   If the RADIUS server is unable to perform the requested
+   authentication it MUST return an Access-Reject.  For example, CHAP
+   requires that the user's password be available in cleartext to the
+   server so that it can encrypt the CHAP challenge and compare that to
+   the CHAP response.  If the password is not available in cleartext to
+   the RADIUS server then the server MUST send an Access-Reject to the
+   client.
+
+2.3.  Proxy
+
+   With proxy RADIUS, one RADIUS server receives an authentication (or
+   accounting) request from a RADIUS client (such as a NAS), forwards
+   the request to a remote RADIUS server, receives the reply from the
+   remote server, and sends that reply to the client, possibly with
+   changes to reflect local administrative policy.  A common use for
+   proxy RADIUS is roaming.  Roaming permits two or more administrative
+   entities to allow each other's users to dial in to either entity's
+   network for service.
+
+
+
+Rigney, et al.              Standards Track                     [Page 8]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   The NAS sends its RADIUS access-request to the "forwarding server"
+   which forwards it to the "remote server".  The remote server sends a
+   response (Access-Accept, Access-Reject, or Access-Challenge) back to
+   the forwarding server, which sends it back to the NAS.  The User-Name
+   attribute MAY contain a Network Access Identifier [8] for RADIUS
+   Proxy operations.  The choice of which server receives the forwarded
+   request SHOULD be based on the authentication "realm". The
+   authentication realm MAY be the realm part of a Network Access
+   Identifier (a "named realm").  Alternatively, the choice of which
+   server receives the forwarded request MAY be based on whatever other
+   criteria the forwarding server is configured to use, such as Called-
+   Station-Id (a "numbered realm").
+
+   A RADIUS server can function as both a forwarding server and a remote
+   server, serving as a forwarding server for some realms and a remote
+   server for other realms.  One forwarding server can act as a
+   forwarder for any number of remote servers.  A remote server can have
+   any number of servers forwarding to it and can provide authentication
+   for any number of realms.  One forwarding server can forward to
+   another forwarding server to create a chain of proxies, although care
+   must be taken to avoid introducing loops.
+
+   The following scenario illustrates a proxy RADIUS communication
+   between a NAS and the forwarding and remote RADIUS servers:
+
+   1. A NAS sends its access-request to the forwarding server.
+
+   2. The forwarding server forwards the access-request to the remote
+      server.
+
+   3. The remote server sends an access-accept, access-reject or
+      access-challenge back to the forwarding server.  For this example,
+      an access-accept is sent.
+
+   4. The forwarding server sends the access-accept to the NAS.
+
+   The forwarding server MUST treat any Proxy-State attributes already
+   in the packet as opaque data.  Its operation MUST NOT depend on the
+   content of Proxy-State attributes added by previous servers.
+
+   If there are any Proxy-State attributes in the request received from
+   the client, the forwarding server MUST include those Proxy-State
+   attributes in its reply to the client.  The forwarding server MAY
+   include the Proxy-State attributes in the access-request when it
+   forwards the request, or MAY omit them in the forwarded request.  If
+   the forwarding server omits the Proxy-State attributes in the
+   forwarded access-request, it MUST attach them to the response before
+   sending it to the client.
+
+
+
+Rigney, et al.              Standards Track                     [Page 9]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   We now examine each step in more detail.
+
+   1. A NAS sends its access-request to the forwarding server.  The
+      forwarding server decrypts the User-Password, if present, using
+      the shared secret it knows for the NAS.  If a CHAP-Password
+      attribute is present in the packet and no CHAP-Challenge attribute
+      is present, the forwarding server MUST leave the Request-
+      Authenticator untouched or copy it to a CHAP-Challenge attribute.
+
+   '' The forwarding server MAY add one Proxy-State attribute to the
+      packet.  (It MUST NOT add more than one.)  If it adds a Proxy-
+      State, the Proxy-State MUST appear after any other Proxy-States in
+      the packet.  The forwarding server MUST NOT modify any other
+      Proxy-States that were in the packet (it may choose not to forward
+      them, but it MUST NOT change their contents).  The forwarding
+      server MUST NOT change the order of any attributes of the same
+      type, including Proxy-State.
+
+   2. The forwarding server encrypts the User-Password, if present,
+      using the secret it shares with the remote server, sets the
+      Identifier as needed, and forwards the access-request to the
+      remote server.
+
+   3. The remote server (if the final destination) verifies the user
+      using User-Password, CHAP-Password, or such method as future
+      extensions may dictate, and returns an access-accept, access-
+      reject or access-challenge back to the forwarding server.  For
+      this example, an access-accept is sent.  The remote server MUST
+      copy all Proxy-State attributes (and only the Proxy-State
+      attributes) in order from the access-request to the response
+      packet, without modifying them.
+
+   4. The forwarding server verifies the Response Authenticator using
+      the secret it shares with the remote server, and silently discards
+      the packet if it fails verification.  If the packet passes
+      verification, the forwarding server removes the last Proxy-State
+      (if it attached one), signs the Response Authenticator using the
+      secret it shares with the NAS, restores the Identifier to match
+      the one in the original request by the NAS, and sends the access-
+      accept to the NAS.
+
+   A forwarding server MAY need to modify attributes to enforce local
+   policy.  Such policy is outside the scope of this document, with the
+   following restrictions.  A forwarding server MUST not modify existing
+   Proxy-State, State, or Class attributes present in the packet.
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 10]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Implementers of forwarding servers should consider carefully which
+   values it is willing to accept for Service-Type.  Careful
+   consideration must be given to the effects of passing along Service-
+   Types of NAS-Prompt or Administrative in a proxied Access-Accept, and
+   implementers may wish to provide mechanisms to block those or other
+   service types, or other attributes.  Such mechanisms are outside the
+   scope of this document.
+
+2.4.  Why UDP?
+
+   A frequently asked question is why RADIUS uses UDP instead of TCP as
+   a transport protocol.  UDP was chosen for strictly technical reasons.
+
+   There are a number of issues which must be understood.  RADIUS is a
+   transaction based protocol which has several interesting
+   characteristics:
+
+   1. If the request to a primary Authentication server fails, a
+      secondary server must be queried.
+
+      To meet this requirement, a copy of the request must be kept above
+      the transport layer to allow for alternate transmission.  This
+      means that retransmission timers are still required.
+
+   2. The timing requirements of this particular protocol are
+      significantly different than TCP provides.
+
+      At one extreme, RADIUS does not require a "responsive" detection
+      of lost data.  The user is willing to wait several seconds for the
+      authentication to complete.  The generally aggressive TCP
+      retransmission (based on average round trip time) is not required,
+      nor is the acknowledgement overhead of TCP.
+
+      At the other extreme, the user is not willing to wait several
+      minutes for authentication.  Therefore the reliable delivery of
+      TCP data two minutes later is not useful.  The faster use of an
+      alternate server allows the user to gain access before giving up.
+
+   3. The stateless nature of this protocol simplifies the use of UDP.
+
+      Clients and servers come and go.  Systems are rebooted, or are
+      power cycled independently.  Generally this does not cause a
+      problem and with creative timeouts and detection of lost TCP
+      connections, code can be written to handle anomalous events.  UDP
+      however completely eliminates any of this special handling.  Each
+      client and server can open their UDP transport just once and leave
+      it open through all types of failure events on the network.
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 11]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   4. UDP simplifies the server implementation.
+
+      In the earliest implementations of RADIUS, the server was single
+      threaded.  This means that a single request was received,
+      processed, and returned.  This was found to be unmanageable in
+      environments where the back-end security mechanism took real time
+      (1 or more seconds).  The server request queue would fill and in
+      environments where hundreds of people were being authenticated
+      every minute, the request turn-around time increased to longer
+      than users were willing to wait (this was especially severe when a
+      specific lookup in a database or over DNS took 30 or more
+      seconds).  The obvious solution was to make the server multi-
+      threaded.  Achieving this was simple with UDP.  Separate processes
+      were spawned to serve each request and these processes could
+      respond directly to the client NAS with a simple UDP packet to the
+      original transport of the client.
+
+   It's not all a panacea.  As noted, using UDP requires one thing which
+   is built into TCP: with UDP we must artificially manage
+   retransmission timers to the same server, although they don't require
+   the same attention to timing provided by TCP.  This one penalty is a
+   small price to pay for the advantages of UDP in this protocol.
+
+   Without TCP we would still probably be using tin cans connected by
+   string.  But for this particular protocol, UDP is a better choice.
+
+2.5.  Retransmission Hints
+
+   If the RADIUS server and alternate RADIUS server share the same
+   shared secret, it is OK to retransmit the packet to the alternate
+   RADIUS server with the same ID and Request Authenticator, because the
+   content of the attributes haven't changed.  If you want to use a new
+   Request Authenticator when sending to the alternate server, you may.
+
+   If you change the contents of the User-Password attribute (or any
+   other attribute), you need a new Request Authenticator and therefore
+   a new ID.
+
+   If the NAS is retransmitting a RADIUS request to the same server as
+   before, and the attributes haven't changed, you MUST use the same
+   Request Authenticator, ID, and source port.  If any attributes have
+   changed, you MUST use a new Request Authenticator and ID.
+
+   A NAS MAY use the same ID across all servers, or MAY keep track of
+   IDs separately for each server, it is up to the implementer.  If a
+   NAS needs more than 256 IDs for outstanding requests, it MAY use
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 12]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   additional source ports to send requests from, and keep track of IDs
+   for each source port.  This allows up to 16 million or so outstanding
+   requests at one time to a single server.
+
+2.6.  Keep-Alives Considered Harmful
+
+   Some implementers have adopted the practice of sending test RADIUS
+   requests to see if a server is alive.  This practice is strongly
+   discouraged, since it adds to load and harms scalability without
+   providing any additional useful information.  Since a RADIUS request
+   is contained in a single datagram, in the time it would take you to
+   send a ping you could just send the RADIUS request, and getting a
+   reply tells you that the RADIUS server is up.  If you do not have a
+   RADIUS request to send, it does not matter if the server is up or
+   not, because you are not using it.
+
+   If you want to monitor your RADIUS server, use SNMP.  That's what
+   SNMP is for.
+
+3.  Packet Format
+
+   Exactly one RADIUS packet is encapsulated in the UDP Data field [4],
+   where the UDP Destination Port field indicates 1812 (decimal).
+
+   When a reply is generated, the source and destination ports are
+   reversed.
+
+   This memo documents the RADIUS protocol.  The early deployment of
+   RADIUS was done using UDP port number 1645, which conflicts with the
+   "datametrics" service.  The officially assigned port number for
+   RADIUS is 1812.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 13]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   A summary of the RADIUS data format is shown below.  The fields are
+   transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                         Authenticator                         |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      The Code field is one octet, and identifies the type of RADIUS
+      packet.  When a packet is received with an invalid Code field, it
+      is silently discarded.
+
+      RADIUS Codes (decimal) are assigned as follows:
+
+        1       Access-Request
+        2       Access-Accept
+        3       Access-Reject
+        4       Accounting-Request
+        5       Accounting-Response
+       11       Access-Challenge
+       12       Status-Server (experimental)
+       13       Status-Client (experimental)
+      255       Reserved
+
+   Codes 4 and 5 are covered in the RADIUS Accounting document [5].
+   Codes 12 and 13 are reserved for possible use, but are not further
+   mentioned here.
+
+   Identifier
+
+      The Identifier field is one octet, and aids in matching requests
+      and replies.  The RADIUS server can detect a duplicate request if
+      it has the same client source IP address and source UDP port and
+      Identifier within a short span of time.
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 14]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Length
+
+      The Length field is two octets.  It indicates the length of the
+      packet including the Code, Identifier, Length, Authenticator and
+      Attribute fields.  Octets outside the range of the Length field
+      MUST be treated as padding and ignored on reception.  If the
+      packet is shorter than the Length field indicates, it MUST be
+      silently discarded.  The minimum length is 20 and maximum length
+      is 4096.
+
+   Authenticator
+
+      The Authenticator field is sixteen (16) octets.  The most
+      significant octet is transmitted first.  This value is used to
+      authenticate the reply from the RADIUS server, and is used in the
+      password hiding algorithm.
+
+      Request Authenticator
+
+         In Access-Request Packets, the Authenticator value is a 16
+         octet random number, called the Request Authenticator.  The
+         value SHOULD be unpredictable and unique over the lifetime of a
+         secret (the password shared between the client and the RADIUS
+         server), since repetition of a request value in conjunction
+         with the same secret would permit an attacker to reply with a
+         previously intercepted response.  Since it is expected that the
+         same secret MAY be used to authenticate with servers in
+         disparate geographic regions, the Request Authenticator field
+         SHOULD exhibit global and temporal uniqueness.
+
+         The Request Authenticator value in an Access-Request packet
+         SHOULD also be unpredictable, lest an attacker trick a server
+         into responding to a predicted future request, and then use the
+         response to masquerade as that server to a future Access-
+         Request.
+
+         Although protocols such as RADIUS are incapable of protecting
+         against theft of an authenticated session via realtime active
+         wiretapping attacks, generation of unique unpredictable
+         requests can protect against a wide range of active attacks
+         against authentication.
+
+         The NAS and RADIUS server share a secret.  That shared secret
+         followed by the Request Authenticator is put through a one-way
+         MD5 hash to create a 16 octet digest value which is xored with
+         the password entered by the user, and the xored result placed
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 15]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+         in the User-Password attribute in the Access-Request packet.
+         See the entry for User-Password in the section on Attributes
+         for a more detailed description.
+
+      Response Authenticator
+
+         The value of the Authenticator field in Access-Accept, Access-
+         Reject, and Access-Challenge packets is called the Response
+         Authenticator, and contains a one-way MD5 hash calculated over
+         a stream of octets consisting of: the RADIUS packet, beginning
+         with the Code field, including the Identifier, the Length, the
+         Request Authenticator field from the Access-Request packet, and
+         the response Attributes, followed by the shared secret.  That
+         is, ResponseAuth =
+         MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
+         denotes concatenation.
+
+   Administrative Note
+
+      The secret (password shared between the client and the RADIUS
+      server) SHOULD be at least as large and unguessable as a well-
+      chosen password.  It is preferred that the secret be at least 16
+      octets.  This is to ensure a sufficiently large range for the
+      secret to provide protection against exhaustive search attacks.
+      The secret MUST NOT be empty (length 0) since this would allow
+      packets to be trivially forged.
+
+      A RADIUS server MUST use the source IP address of the RADIUS UDP
+      packet to decide which shared secret to use, so that RADIUS
+      requests can be proxied.
+
+      When using a forwarding proxy, the proxy must be able to alter the
+      packet as it passes through in each direction - when the proxy
+      forwards the request, the proxy MAY add a Proxy-State Attribute,
+      and when the proxy forwards a response, it MUST remove its Proxy-
+      State Attribute if it added one.  Proxy-State is always added or
+      removed after any other Proxy-States, but no other assumptions
+      regarding its location within the list of attributes can be made.
+      Since Access-Accept and Access-Reject replies are authenticated on
+      the entire packet contents, the stripping of the Proxy-State
+      attribute invalidates the signature in the packet - so the proxy
+      has to re-sign it.
+
+      Further details of RADIUS proxy implementation are outside the
+      scope of this document.
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 16]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+4.  Packet Types
+
+   The RADIUS Packet type is determined by the Code field in the first
+   octet of the Packet.
+
+4.1.  Access-Request
+
+   Description
+
+      Access-Request packets are sent to a RADIUS server, and convey
+      information used to determine whether a user is allowed access to
+      a specific NAS, and any special services requested for that user.
+      An implementation wishing to authenticate a user MUST transmit a
+      RADIUS packet with the Code field set to 1 (Access-Request).
+
+      Upon receipt of an Access-Request from a valid client, an
+      appropriate reply MUST be transmitted.
+
+      An Access-Request SHOULD contain a User-Name attribute.  It MUST
+      contain either a NAS-IP-Address attribute or a NAS-Identifier
+      attribute (or both).
+
+      An Access-Request MUST contain either a User-Password or a CHAP-
+      Password or a State.  An Access-Request MUST NOT contain both a
+      User-Password and a CHAP-Password.  If future extensions allow
+      other kinds of authentication information to be conveyed, the
+      attribute for that can be used in an Access-Request instead of
+      User-Password or CHAP-Password.
+
+      An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type
+      attribute or both unless the type of access being requested does
+      not involve a port or the NAS does not distinguish among its
+      ports.
+
+      An Access-Request MAY contain additional attributes as a hint to
+      the server, but the server is not required to honor the hint.
+
+      When a User-Password is present, it is hidden using a method based
+      on the RSA Message Digest Algorithm MD5 [3].
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 17]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   A summary of the Access-Request packet format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Request Authenticator                     |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      1 for Access-Request.
+
+   Identifier
+
+      The Identifier field MUST be changed whenever the content of the
+      Attributes field changes, and whenever a valid reply has been
+      received for a previous request.  For retransmissions, the
+      Identifier MUST remain unchanged.
+
+   Request Authenticator
+
+      The Request Authenticator value MUST be changed each time a new
+      Identifier is used.
+
+   Attributes
+
+      The Attribute field is variable in length, and contains the list
+      of Attributes that are required for the type of service, as well
+      as any desired optional Attributes.
+
+4.2.  Access-Accept
+
+   Description
+
+      Access-Accept packets are sent by the RADIUS server, and provide
+      specific configuration information necessary to begin delivery of
+      service to the user.  If all Attribute values received in an
+      Access-Request are acceptable then the RADIUS implementation MUST
+      transmit a packet with the Code field set to 2 (Access-Accept).
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 18]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+      On reception of an Access-Accept, the Identifier field is matched
+      with a pending Access-Request.  The Response Authenticator field
+      MUST contain the correct response for the pending Access-Request.
+      Invalid packets are silently discarded.
+
+   A summary of the Access-Accept packet format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Response Authenticator                    |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      2 for Access-Accept.
+
+   Identifier
+
+      The Identifier field is a copy of the Identifier field of the
+      Access-Request which caused this Access-Accept.
+
+   Response Authenticator
+
+      The Response Authenticator value is calculated from the Access-
+      Request value, as described earlier.
+
+   Attributes
+
+      The Attribute field is variable in length, and contains a list of
+      zero or more Attributes.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 19]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+4.3.  Access-Reject
+
+   Description
+
+      If any value of the received Attributes is not acceptable, then
+      the RADIUS server MUST transmit a packet with the Code field set
+      to 3 (Access-Reject).  It MAY include one or more Reply-Message
+      Attributes with a text message which the NAS MAY display to the
+      user.
+
+   A summary of the Access-Reject packet format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Response Authenticator                    |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      3 for Access-Reject.
+
+   Identifier
+
+      The Identifier field is a copy of the Identifier field of the
+      Access-Request which caused this Access-Reject.
+
+   Response Authenticator
+
+      The Response Authenticator value is calculated from the Access-
+      Request value, as described earlier.
+
+   Attributes
+
+      The Attribute field is variable in length, and contains a list of
+      zero or more Attributes.
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 20]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+4.4.  Access-Challenge
+
+   Description
+
+      If the RADIUS server desires to send the user a challenge
+      requiring a response, then the RADIUS server MUST respond to the
+      Access-Request by transmitting a packet with the Code field set to
+      11 (Access-Challenge).
+
+      The Attributes field MAY have one or more Reply-Message
+      Attributes, and MAY have a single State Attribute, or none.
+      Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State
+      attributes MAY also be included.  No other Attributes defined in
+      this document are permitted in an Access-Challenge.
+
+      On receipt of an Access-Challenge, the Identifier field is matched
+      with a pending Access-Request.  Additionally, the Response
+      Authenticator field MUST contain the correct response for the
+      pending Access-Request.  Invalid packets are silently discarded.
+
+      If the NAS does not support challenge/response, it MUST treat an
+      Access-Challenge as though it had received an Access-Reject
+      instead.
+
+      If the NAS supports challenge/response, receipt of a valid
+      Access-Challenge indicates that a new Access-Request SHOULD be
+      sent.  The NAS MAY display the text message, if any, to the user,
+      and then prompt the user for a response.  It then sends its
+      original Access-Request with a new request ID and Request
+      Authenticator, with the User-Password Attribute replaced by the
+      user's response (encrypted), and including the State Attribute
+      from the Access-Challenge, if any.  Only 0 or 1 instances of the
+      State Attribute can be present in an Access-Request.
+
+      A NAS which supports PAP MAY forward the Reply-Message to the
+      dialing client and accept a PAP response which it can use as
+      though the user had entered the response.  If the NAS cannot do
+      so, it MUST treat the Access-Challenge as though it had received
+      an Access-Reject instead.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 21]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   A summary of the Access-Challenge packet format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Response Authenticator                    |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      11 for Access-Challenge.
+
+   Identifier
+
+      The Identifier field is a copy of the Identifier field of the
+      Access-Request which caused this Access-Challenge.
+
+   Response Authenticator
+
+      The Response Authenticator value is calculated from the Access-
+      Request value, as described earlier.
+
+   Attributes
+
+      The Attributes field is variable in length, and contains a list of
+      zero or more Attributes.
+
+5.  Attributes
+
+   RADIUS Attributes carry the specific authentication, authorization,
+   information and configuration details for the request and reply.
+
+   The end of the list of Attributes is indicated by the Length of the
+   RADIUS packet.
+
+   Some Attributes MAY be included more than once.  The effect of this
+   is Attribute specific, and is specified in each Attribute
+   description.  A summary table is provided at the end of the
+   "Attributes" section.
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 22]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   If multiple Attributes with the same Type are present, the order of
+   Attributes with the same Type MUST be preserved by any proxies.  The
+   order of Attributes of different Types is not required to be
+   preserved.  A RADIUS server or client MUST NOT have any dependencies
+   on the order of attributes of different types.  A RADIUS server or
+   client MUST NOT require attributes of the same type to be contiguous.
+
+   Where an Attribute's description limits which kinds of packet it can
+   be contained in, this applies only to the packet types defined in
+   this document, namely Access-Request, Access-Accept, Access-Reject
+   and Access-Challenge (Codes 1, 2, 3, and 11).  Other documents
+   defining other packet types may also use Attributes described here.
+   To determine which Attributes are allowed in Accounting-Request and
+   Accounting-Response packets (Codes 4 and 5) refer to the RADIUS
+   Accounting document [5].
+
+   Likewise where packet types defined here state that only certain
+   Attributes are permissible in them, future memos defining new
+   Attributes should indicate which packet types the new Attributes may
+   be present in.
+
+   A summary of the Attribute format is shown below.  The fields are
+   transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  Value ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      The Type field is one octet.  Up-to-date values of the RADIUS Type
+      field are specified in the most recent "Assigned Numbers" RFC [6].
+      Values 192-223 are reserved for experimental use, values 224-240
+      are reserved for implementation-specific use, and values 241-255
+      are reserved and should not be used.
+
+      A RADIUS server MAY ignore Attributes with an unknown Type.
+
+      A RADIUS client MAY ignore Attributes with an unknown Type.
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 23]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+      This specification concerns the following values:
+
+          1      User-Name
+          2      User-Password
+          3      CHAP-Password
+          4      NAS-IP-Address
+          5      NAS-Port
+          6      Service-Type
+          7      Framed-Protocol
+          8      Framed-IP-Address
+          9      Framed-IP-Netmask
+         10      Framed-Routing
+         11      Filter-Id
+         12      Framed-MTU
+         13      Framed-Compression
+         14      Login-IP-Host
+         15      Login-Service
+         16      Login-TCP-Port
+         17      (unassigned)
+         18      Reply-Message
+         19      Callback-Number
+         20      Callback-Id
+         21      (unassigned)
+         22      Framed-Route
+         23      Framed-IPX-Network
+         24      State
+         25      Class
+         26      Vendor-Specific
+         27      Session-Timeout
+         28      Idle-Timeout
+         29      Termination-Action
+         30      Called-Station-Id
+         31      Calling-Station-Id
+         32      NAS-Identifier
+         33      Proxy-State
+         34      Login-LAT-Service
+         35      Login-LAT-Node
+         36      Login-LAT-Group
+         37      Framed-AppleTalk-Link
+         38      Framed-AppleTalk-Network
+         39      Framed-AppleTalk-Zone
+         40-59   (reserved for accounting)
+         60      CHAP-Challenge
+         61      NAS-Port-Type
+         62      Port-Limit
+         63      Login-LAT-Port
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 24]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Length
+
+      The Length field is one octet, and indicates the length of this
+      Attribute including the Type, Length and Value fields.  If an
+      Attribute is received in an Access-Request but with an invalid
+      Length, an Access-Reject SHOULD be transmitted.  If an Attribute
+      is received in an Access-Accept, Access-Reject or Access-Challenge
+      packet with an invalid length, the packet MUST either be treated
+      as an Access-Reject or else silently discarded.
+
+   Value
+
+      The Value field is zero or more octets and contains information
+      specific to the Attribute.  The format and length of the Value
+      field is determined by the Type and Length fields.
+
+      Note that none of the types in RADIUS terminate with a NUL (hex
+      00).  In particular, types "text" and "string" in RADIUS do not
+      terminate with a NUL (hex 00).  The Attribute has a length field
+      and does not use a terminator.  Text contains UTF-8 encoded 10646
+      [7] characters and String contains 8-bit binary data.  Servers and
+      servers and clients MUST be able to deal with embedded nulls.
+      RADIUS implementers using C are cautioned not to use strcpy() when
+      handling strings.
+
+      The format of the value field is one of five data types.  Note
+      that type "text" is a subset of type "string".
+
+      text      1-253 octets containing UTF-8 encoded 10646 [7]
+                characters.  Text of length zero (0) MUST NOT be sent;
+                omit the entire attribute instead.
+
+      string    1-253 octets containing binary data (values 0 through
+                255 decimal, inclusive).  Strings of length zero (0)
+                MUST NOT be sent; omit the entire attribute instead.
+
+      address   32 bit value, most significant octet first.
+
+      integer   32 bit unsigned value, most significant octet first.
+
+      time      32 bit unsigned value, most significant octet first --
+                seconds since 00:00:00 UTC, January 1, 1970.  The
+                standard Attributes do not use this data type but it is
+                presented here for possible use in future attributes.
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 25]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+5.1.  User-Name
+
+   Description
+
+      This Attribute indicates the name of the user to be authenticated.
+      It MUST be sent in Access-Request packets if available.
+
+      It MAY be sent in an Access-Accept packet, in which case the
+      client SHOULD use the name returned in the Access-Accept packet in
+      all Accounting-Request packets for this session.  If the Access-
+      Accept includes Service-Type = Rlogin and the User-Name attribute,
+      a NAS MAY use the returned User-Name when performing the Rlogin
+      function.
+
+   A summary of the User-Name Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      1 for User-Name.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The NAS may limit the
+      maximum length of the User-Name but the ability to handle at least
+      63 octets is recommended.
+
+      The format of the username MAY be one of several forms:
+
+      text      Consisting only of UTF-8 encoded 10646 [7] characters.
+
+      network access identifier
+                A Network Access Identifier as described in RFC 2486
+                [8].
+
+      distinguished name
+                A name in ASN.1 form used in Public Key authentication
+                systems.
+
+
+
+Rigney, et al.              Standards Track                    [Page 26]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+5.2.  User-Password
+
+   Description
+
+      This Attribute indicates the password of the user to be
+      authenticated, or the user's input following an Access-Challenge.
+      It is only used in Access-Request packets.
+
+      On transmission, the password is hidden.  The password is first
+      padded at the end with nulls to a multiple of 16 octets.  A one-
+      way MD5 hash is calculated over a stream of octets consisting of
+      the shared secret followed by the Request Authenticator.  This
+      value is XORed with the first 16 octet segment of the password and
+      placed in the first 16 octets of the String field of the User-
+      Password Attribute.
+
+      If the password is longer than 16 characters, a second one-way MD5
+      hash is calculated over a stream of octets consisting of the
+      shared secret followed by the result of the first xor.  That hash
+      is XORed with the second 16 octet segment of the password and
+      placed in the second 16 octets of the String field of the User-
+      Password Attribute.
+
+      If necessary, this operation is repeated, with each xor result
+      being used along with the shared secret to generate the next hash
+      to xor the next segment of the password, to no more than 128
+      characters.
+
+      The method is taken from the book "Network Security" by Kaufman,
+      Perlman and Speciner [9] pages 109-110.  A more precise
+      explanation of the method follows:
+
+      Call the shared secret S and the pseudo-random 128-bit Request
+      Authenticator RA.  Break the password into 16-octet chunks p1, p2,
+      etc.  with the last one padded at the end with nulls to a 16-octet
+      boundary.  Call the ciphertext blocks c(1), c(2), etc.  We'll need
+      intermediate values b1, b2, etc.
+
+         b1 = MD5(S + RA)       c(1) = p1 xor b1
+         b2 = MD5(S + c(1))     c(2) = p2 xor b2
+                .                       .
+                .                       .
+                .                       .
+         bi = MD5(S + c(i-1))   c(i) = pi xor bi
+
+      The String will contain c(1)+c(2)+...+c(i) where + denotes
+      concatenation.
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 27]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+      On receipt, the process is reversed to yield the original
+      password.
+
+   A summary of the User-Password Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      2 for User-Password.
+
+   Length
+
+      At least 18 and no larger than 130.
+
+   String
+
+      The String field is between 16 and 128 octets long, inclusive.
+
+5.3.  CHAP-Password
+
+   Description
+
+      This Attribute indicates the response value provided by a PPP
+      Challenge-Handshake Authentication Protocol (CHAP) user in
+      response to the challenge.  It is only used in Access-Request
+      packets.
+
+      The CHAP challenge value is found in the CHAP-Challenge Attribute
+      (60) if present in the packet, otherwise in the Request
+      Authenticator field.
+
+   A summary of the CHAP-Password Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  CHAP Ident   |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 28]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Type
+
+      3 for CHAP-Password.
+
+   Length
+
+      19
+
+   CHAP Ident
+
+      This field is one octet, and contains the CHAP Identifier from the
+      user's CHAP Response.
+
+   String
+
+      The String field is 16 octets, and contains the CHAP Response from
+      the user.
+
+5.4.  NAS-IP-Address
+
+   Description
+
+      This Attribute indicates the identifying IP Address of the NAS
+      which is requesting authentication of the user, and SHOULD be
+      unique to the NAS within the scope of the RADIUS server. NAS-IP-
+      Address is only used in Access-Request packets.  Either NAS-IP-
+      Address or NAS-Identifier MUST be present in an Access-Request
+      packet.
+
+      Note that NAS-IP-Address MUST NOT be used to select the shared
+      secret used to authenticate the request.  The source IP address of
+      the Access-Request packet MUST be used to select the shared
+      secret.
+
+   A summary of the NAS-IP-Address Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |            Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Address (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      4 for NAS-IP-Address.
+
+
+
+Rigney, et al.              Standards Track                    [Page 29]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Length
+
+      6
+
+   Address
+
+      The Address field is four octets.
+
+5.5.  NAS-Port
+
+   Description
+
+      This Attribute indicates the physical port number of the NAS which
+      is authenticating the user.  It is only used in Access-Request
+      packets.  Note that this is using "port" in its sense of a
+      physical connection on the NAS, not in the sense of a TCP or UDP
+      port number.  Either NAS-Port or NAS-Port-Type (61) or both SHOULD
+      be present in an Access-Request packet, if the NAS differentiates
+      among its ports.
+
+   A summary of the NAS-Port Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      5 for NAS-Port.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 30]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+5.6.  Service-Type
+
+   Description
+
+      This Attribute indicates the type of service the user has
+      requested, or the type of service to be provided.  It MAY be used
+      in both Access-Request and Access-Accept packets.  A NAS is not
+      required to implement all of these service types, and MUST treat
+      unknown or unsupported Service-Types as though an Access-Reject
+      had been received instead.
+
+   A summary of the Service-Type Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      6 for Service-Type.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       1      Login
+       2      Framed
+       3      Callback Login
+       4      Callback Framed
+       5      Outbound
+       6      Administrative
+       7      NAS Prompt
+       8      Authenticate Only
+       9      Callback NAS Prompt
+      10      Call Check
+      11      Callback Administrative
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 31]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+      The service types are defined as follows when used in an Access-
+      Accept.  When used in an Access-Request, they MAY be considered to
+      be a hint to the RADIUS server that the NAS has reason to believe
+      the user would prefer the kind of service indicated, but the
+      server is not required to honor the hint.
+
+      Login               The user should be connected to a host.
+
+      Framed              A Framed Protocol should be started for the
+                          User, such as PPP or SLIP.
+
+      Callback Login      The user should be disconnected and called
+                          back, then connected to a host.
+
+      Callback Framed     The user should be disconnected and called
+                          back, then a Framed Protocol should be started
+                          for the User, such as PPP or SLIP.
+
+      Outbound            The user should be granted access to outgoing
+                          devices.
+
+      Administrative      The user should be granted access to the
+                          administrative interface to the NAS from which
+                          privileged commands can be executed.
+
+      NAS Prompt          The user should be provided a command prompt
+                          on the NAS from which non-privileged commands
+                          can be executed.
+
+      Authenticate Only   Only Authentication is requested, and no
+                          authorization information needs to be returned
+                          in the Access-Accept (typically used by proxy
+                          servers rather than the NAS itself).
+
+      Callback NAS Prompt The user should be disconnected and called
+                          back, then provided a command prompt on the
+                          NAS from which non-privileged commands can be
+                          executed.
+
+      Call Check          Used by the NAS in an Access-Request packet to
+                          indicate that a call is being received and
+                          that the RADIUS server should send back an
+                          Access-Accept to answer the call, or an
+                          Access-Reject to not accept the call,
+                          typically based on the Called-Station-Id or
+                          Calling-Station-Id attributes.  It is
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 32]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+                          recommended that such Access-Requests use the
+                          value of Calling-Station-Id as the value of
+                          the User-Name.
+
+      Callback Administrative
+                          The user should be disconnected and called
+                          back, then granted access to the
+                          administrative interface to the NAS from which
+                          privileged commands can be executed.
+
+5.7.  Framed-Protocol
+
+   Description
+
+      This Attribute indicates the framing to be used for framed access.
+      It MAY be used in both Access-Request and Access-Accept packets.
+
+   A summary of the Framed-Protocol Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      7 for Framed-Protocol.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+      1      PPP
+      2      SLIP
+      3      AppleTalk Remote Access Protocol (ARAP)
+      4      Gandalf proprietary SingleLink/MultiLink protocol
+      5      Xylogics proprietary IPX/SLIP
+      6      X.75 Synchronous
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 33]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+5.8.  Framed-IP-Address
+
+   Description
+
+      This Attribute indicates the address to be configured for the
+      user.  It MAY be used in Access-Accept packets.  It MAY be used in
+      an Access-Request packet as a hint by the NAS to the server that
+      it would prefer that address, but the server is not required to
+      honor the hint.
+
+   A summary of the Framed-IP-Address Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |            Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Address (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      8 for Framed-IP-Address.
+
+   Length
+
+      6
+
+   Address
+
+      The Address field is four octets.  The value 0xFFFFFFFF indicates
+      that the NAS Should allow the user to select an address (e.g.
+      Negotiated).  The value 0xFFFFFFFE indicates that the NAS should
+      select an address for the user (e.g. Assigned from a pool of
+      addresses kept by the NAS).  Other valid values indicate that the
+      NAS should use that value as the user's IP address.
+
+5.9.  Framed-IP-Netmask
+
+   Description
+
+      This Attribute indicates the IP netmask to be configured for the
+      user when the user is a router to a network.  It MAY be used in
+      Access-Accept packets.  It MAY be used in an Access-Request packet
+      as a hint by the NAS to the server that it would prefer that
+      netmask, but the server is not required to honor the hint.
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 34]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   A summary of the Framed-IP-Netmask Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |            Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Address (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      9 for Framed-IP-Netmask.
+
+   Length
+
+      6
+
+   Address
+
+      The Address field is four octets specifying the IP netmask of the
+      user.
+
+5.10.  Framed-Routing
+
+   Description
+
+      This Attribute indicates the routing method for the user, when the
+      user is a router to a network.  It is only used in Access-Accept
+      packets.
+
+   A summary of the Framed-Routing Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      10 for Framed-Routing.
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 35]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       0      None
+       1      Send routing packets
+       2      Listen for routing packets
+       3      Send and Listen
+
+5.11.  Filter-Id
+
+   Description
+
+      This Attribute indicates the name of the filter list for this
+      user.  Zero or more Filter-Id attributes MAY be sent in an
+      Access-Accept packet.
+
+      Identifying a filter list by name allows the filter to be used on
+      different NASes without regard to filter-list implementation
+      details.
+
+   A summary of the Filter-Id Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  Text ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      11 for Filter-Id.
+
+   Length
+
+      >= 3
+
+   Text
+
+      The Text field is one or more octets, and its contents are
+      implementation dependent.  It is intended to be human readable and
+      MUST NOT affect operation of the protocol.  It is recommended that
+      the message contain UTF-8 encoded 10646 [7] characters.
+
+
+
+Rigney, et al.              Standards Track                    [Page 36]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+5.12.  Framed-MTU
+
+   Description
+
+      This Attribute indicates the Maximum Transmission Unit to be
+      configured for the user, when it is not negotiated by some other
+      means (such as PPP).  It MAY be used in Access-Accept packets.  It
+      MAY be used in an Access-Request packet as a hint by the NAS to
+      the server that it would prefer that value, but the server is not
+      required to honor the hint.
+
+   A summary of the Framed-MTU Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      12 for Framed-MTU.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  Despite the size of the field,
+      values range from 64 to 65535.
+
+5.13.  Framed-Compression
+
+   Description
+
+      This Attribute indicates a compression protocol to be used for the
+      link.  It MAY be used in Access-Accept packets.  It MAY be used in
+      an Access-Request packet as a hint to the server that the NAS
+      would prefer to use that compression, but the server is not
+      required to honor the hint.
+
+      More than one compression protocol Attribute MAY be sent.  It is
+      the responsibility of the NAS to apply the proper compression
+      protocol to appropriate link traffic.
+
+
+
+Rigney, et al.              Standards Track                    [Page 37]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   A summary of the Framed-Compression Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      13 for Framed-Compression.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       0      None
+       1      VJ TCP/IP header compression [10]
+       2      IPX header compression
+       3      Stac-LZS compression
+
+5.14.  Login-IP-Host
+
+   Description
+
+      This Attribute indicates the system with which to connect the user,
+      when the Login-Service Attribute is included.  It MAY be used in
+      Access-Accept packets.  It MAY be used in an Access-Request packet as
+      a hint to the server that the NAS would prefer to use that host, but
+      the server is not required to honor the hint.
+
+   A summary of the Login-IP-Host Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 38]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |            Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Address (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      14 for Login-IP-Host.
+
+   Length
+
+      6
+
+   Address
+
+      The Address field is four octets.  The value 0xFFFFFFFF indicates
+      that the NAS SHOULD allow the user to select an address.  The
+      value 0 indicates that the NAS SHOULD select a host to connect the
+      user to.  Other values indicate the address the NAS SHOULD connect
+      the user to.
+
+5.15.  Login-Service
+
+   Description
+
+      This Attribute indicates the service to use to connect the user to
+      the login host.  It is only used in Access-Accept packets.
+
+   A summary of the Login-Service Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      15 for Login-Service.
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 39]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       0   Telnet
+       1   Rlogin
+       2   TCP Clear
+       3   PortMaster (proprietary)
+       4   LAT
+       5   X25-PAD
+       6   X25-T3POS
+       8   TCP Clear Quiet (suppresses any NAS-generated connect string)
+
+5.16.  Login-TCP-Port
+
+   Description
+
+      This Attribute indicates the TCP port with which the user is to be
+      connected, when the Login-Service Attribute is also present.  It
+      is only used in Access-Accept packets.
+
+   A summary of the Login-TCP-Port Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      16 for Login-TCP-Port.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  Despite the size of the field,
+      values range from 0 to 65535.
+
+
+
+Rigney, et al.              Standards Track                    [Page 40]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+5.17.  (unassigned)
+
+   Description
+
+      ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
+
+5.18.  Reply-Message
+
+   Description
+
+      This Attribute indicates text which MAY be displayed to the user.
+
+      When used in an Access-Accept, it is the success message.
+
+      When used in an Access-Reject, it is the failure message.  It MAY
+      indicate a dialog message to prompt the user before another
+      Access-Request attempt.
+
+      When used in an Access-Challenge, it MAY indicate a dialog message
+      to prompt the user for a response.
+
+      Multiple Reply-Message's MAY be included and if any are displayed,
+      they MUST be displayed in the same order as they appear in the
+      packet.
+
+   A summary of the Reply-Message Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  Text ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      18 for Reply-Message.
+
+   Length
+
+      >= 3
+
+   Text
+
+      The Text field is one or more octets, and its contents are
+      implementation dependent.  It is intended to be human readable,
+      and MUST NOT affect operation of the protocol.  It is recommended
+      that the message contain UTF-8 encoded 10646 [7] characters.
+
+
+
+Rigney, et al.              Standards Track                    [Page 41]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+5.19.  Callback-Number
+
+   Description
+
+      This Attribute indicates a dialing string to be used for callback.
+      It MAY be used in Access-Accept packets.  It MAY be used in an
+      Access-Request packet as a hint to the server that a Callback
+      service is desired, but the server is not required to honor the
+      hint.
+
+   A summary of the Callback-Number Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      19 for Callback-Number.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.20.  Callback-Id
+
+   Description
+
+      This Attribute indicates the name of a place to be called, to be
+      interpreted by the NAS.  It MAY be used in Access-Accept packets.
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 42]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   A summary of the Callback-Id Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      20 for Callback-Id.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.21.  (unassigned)
+
+   Description
+
+      ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
+
+5.22.  Framed-Route
+
+   Description
+
+      This Attribute provides routing information to be configured for
+      the user on the NAS.  It is used in the Access-Accept packet and
+      can appear multiple times.
+
+   A summary of the Framed-Route Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  Text ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+Rigney, et al.              Standards Track                    [Page 43]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Type
+
+      22 for Framed-Route.
+
+   Length
+
+      >= 3
+
+   Text
+
+      The Text field is one or more octets, and its contents are
+      implementation dependent.  It is intended to be human readable and
+      MUST NOT affect operation of the protocol.  It is recommended that
+      the message contain UTF-8 encoded 10646 [7] characters.
+
+      For IP routes, it SHOULD contain a destination prefix in dotted
+      quad form optionally followed by a slash and a decimal length
+      specifier stating how many high order bits of the prefix to use.
+      That is followed by a space, a gateway address in dotted quad
+      form, a space, and one or more metrics separated by spaces.  For
+      example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
+      specifier may be omitted, in which case it defaults to 8 bits for
+      class A prefixes, 16 bits for class B prefixes, and 24 bits for
+      class C prefixes.  For example, "192.168.1.0 192.168.1.1 1".
+
+      Whenever the gateway address is specified as "0.0.0.0" the IP
+      address of the user SHOULD be used as the gateway address.
+
+5.23.  Framed-IPX-Network
+
+   Description
+
+      This Attribute indicates the IPX Network number to be configured
+      for the user.  It is used in Access-Accept packets.
+
+   A summary of the Framed-IPX-Network Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 44]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Type
+
+      23 for Framed-IPX-Network.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  The value 0xFFFFFFFE indicates
+      that the NAS should select an IPX network for the user (e.g.
+      assigned from a pool of one or more IPX networks kept by the NAS).
+      Other values should be used as the IPX network for the link to the
+      user.
+
+5.24.  State
+
+   Description
+
+      This Attribute is available to be sent by the server to the client
+      in an Access-Challenge and MUST be sent unmodified from the client
+      to the server in the new Access-Request reply to that challenge,
+      if any.
+
+      This Attribute is available to be sent by the server to the client
+      in an Access-Accept that also includes a Termination-Action
+      Attribute with the value of RADIUS-Request.  If the NAS performs
+      the Termination-Action by sending a new Access-Request upon
+      termination of the current session, it MUST include the State
+      attribute unchanged in that Access-Request.
+
+      In either usage, the client MUST NOT interpret the attribute
+      locally.  A packet must have only zero or one State Attribute.
+      Usage of the State Attribute is implementation dependent.
+
+   A summary of the State Attribute format is shown below.  The fields
+   are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      24 for State.
+
+
+
+Rigney, et al.              Standards Track                    [Page 45]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.25.  Class
+
+   Description
+
+      This Attribute is available to be sent by the server to the client
+      in an Access-Accept and SHOULD be sent unmodified by the client to
+      the accounting server as part of the Accounting-Request packet if
+      accounting is supported.  The client MUST NOT interpret the
+      attribute locally.
+
+   A summary of the Class Attribute format is shown below.  The fields
+   are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      25 for Class.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+
+
+Rigney, et al.              Standards Track                    [Page 46]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+5.26.  Vendor-Specific
+
+   Description
+
+      This Attribute is available to allow vendors to support their own
+      extended Attributes not suitable for general usage.  It MUST not
+      affect the operation of the RADIUS protocol.
+
+      Servers not equipped to interpret the vendor-specific information
+      sent by a client MUST ignore it (although it may be reported).
+      Clients which do not receive desired vendor-specific information
+      SHOULD make an attempt to operate without it, although they may do
+      so (and report they are doing so) in a degraded mode.
+
+   A summary of the Vendor-Specific Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |  Length       |            Vendor-Id
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+        Vendor-Id (cont)           |  String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      26 for Vendor-Specific.
+
+   Length
+
+      >= 7
+
+   Vendor-Id
+
+      The high-order octet is 0 and the low-order 3 octets are the SMI
+      Network Management Private Enterprise Code of the Vendor in
+      network byte order, as defined in the "Assigned Numbers" RFC [6].
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 47]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+      It SHOULD be encoded as a sequence of vendor type / vendor length
+      / value fields, as follows.  The Attribute-Specific field is
+      dependent on the vendor's definition of that attribute.  An
+      example encoding of the Vendor-Specific attribute using this
+      method follows:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |  Length       |            Vendor-Id
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+           Vendor-Id (cont)           | Vendor type   | Vendor length |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Attribute-Specific...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+      Multiple subattributes MAY be encoded within a single Vendor-
+      Specific attribute, although they do not have to be.
+
+5.27.  Session-Timeout
+
+   Description
+
+      This Attribute sets the maximum number of seconds of service to be
+      provided to the user before termination of the session or prompt.
+      This Attribute is available to be sent by the server to the client
+      in an Access-Accept or Access-Challenge.
+
+   A summary of the Session-Timeout Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      27 for Session-Timeout.
+
+   Length
+
+      6
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 48]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Value
+
+      The field is 4 octets, containing a 32-bit unsigned integer with
+      the maximum number of seconds this user should be allowed to
+      remain connected by the NAS.
+
+5.28.  Idle-Timeout
+
+   Description
+
+      This Attribute sets the maximum number of consecutive seconds of
+      idle connection allowed to the user before termination of the
+      session or prompt.  This Attribute is available to be sent by the
+      server to the client in an Access-Accept or Access-Challenge.
+
+   A summary of the Idle-Timeout Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      28 for Idle-Timeout.
+
+   Length
+
+      6
+
+   Value
+
+      The field is 4 octets, containing a 32-bit unsigned integer with
+      the maximum number of consecutive seconds of idle time this user
+      should be permitted before being disconnected by the NAS.
+
+5.29.  Termination-Action
+
+   Description
+
+      This Attribute indicates what action the NAS should take when the
+      specified service is completed.  It is only used in Access-Accept
+      packets.
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 49]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   A summary of the Termination-Action Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      29 for Termination-Action.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       0      Default
+       1      RADIUS-Request
+
+      If the Value is set to RADIUS-Request, upon termination of the
+      specified service the NAS MAY send a new Access-Request to the
+      RADIUS server, including the State attribute if any.
+
+5.30.  Called-Station-Id
+
+   Description
+
+      This Attribute allows the NAS to send in the Access-Request packet
+      the phone number that the user called, using Dialed Number
+      Identification (DNIS) or similar technology.  Note that this may
+      be different from the phone number the call comes in on.  It is
+      only used in Access-Request packets.
+
+   A summary of the Called-Station-Id Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+Rigney, et al.              Standards Track                    [Page 50]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Type
+
+      30 for Called-Station-Id.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets, containing the phone
+      number that the user's call came in on.
+
+      The actual format of the information is site or application
+      specific.  UTF-8 encoded 10646 [7] characters are recommended, but
+      a robust implementation SHOULD support the field as
+      undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.31.  Calling-Station-Id
+
+   Description
+
+      This Attribute allows the NAS to send in the Access-Request packet
+      the phone number that the call came from, using Automatic Number
+      Identification (ANI) or similar technology.  It is only used in
+      Access-Request packets.
+
+   A summary of the Calling-Station-Id Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      31 for Calling-Station-Id.
+
+   Length
+
+      >= 3
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 51]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   String
+
+      The String field is one or more octets, containing the phone
+      number that the user placed the call from.
+
+      The actual format of the information is site or application
+      specific.  UTF-8 encoded 10646 [7] characters are recommended, but
+      a robust implementation SHOULD support the field as
+      undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.32.  NAS-Identifier
+
+   Description
+
+      This Attribute contains a string identifying the NAS originating
+      the Access-Request.  It is only used in Access-Request packets.
+      Either NAS-IP-Address or NAS-Identifier MUST be present in an
+      Access-Request packet.
+
+      Note that NAS-Identifier MUST NOT be used to select the shared
+      secret used to authenticate the request.  The source IP address of
+      the Access-Request packet MUST be used to select the shared
+      secret.
+
+   A summary of the NAS-Identifier Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      32 for NAS-Identifier.
+
+   Length
+
+      >= 3
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 52]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   String
+
+      The String field is one or more octets, and should be unique to
+      the NAS within the scope of the RADIUS server.  For example, a
+      fully qualified domain name would be suitable as a NAS-Identifier.
+
+      The actual format of the information is site or application
+      specific, and a robust implementation SHOULD support the field as
+      undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.33.  Proxy-State
+
+   Description
+
+      This Attribute is available to be sent by a proxy server to
+      another server when forwarding an Access-Request and MUST be
+      returned unmodified in the Access-Accept, Access-Reject or
+      Access-Challenge.  When the proxy server receives the response to
+      its request, it MUST remove its own Proxy-State (the last Proxy-
+      State in the packet) before forwarding the response to the NAS.
+
+      If a Proxy-State Attribute is added to a packet when forwarding
+      the packet, the Proxy-State Attribute MUST be added after any
+      existing Proxy-State attributes.
+
+      The content of any Proxy-State other than the one added by the
+      current server should be treated as opaque octets and MUST NOT
+      affect operation of the protocol.
+
+      Usage of the Proxy-State Attribute is implementation dependent.  A
+      description of its function is outside the scope of this
+      specification.
+
+   A summary of the Proxy-State Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      33 for Proxy-State.
+
+
+
+Rigney, et al.              Standards Track                    [Page 53]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.34.  Login-LAT-Service
+
+   Description
+
+      This Attribute indicates the system with which the user is to be
+      connected by LAT.  It MAY be used in Access-Accept packets, but
+      only when LAT is specified as the Login-Service.  It MAY be used
+      in an Access-Request packet as a hint to the server, but the
+      server is not required to honor the hint.
+
+      Administrators use the service attribute when dealing with
+      clustered systems, such as a VAX or Alpha cluster. In such an
+      environment several different time sharing hosts share the same
+      resources (disks, printers, etc.), and administrators often
+      configure each to offer access (service) to each of the shared
+      resources. In this case, each host in the cluster advertises its
+      services through LAT broadcasts.
+
+      Sophisticated users often know which service providers (machines)
+      are faster and tend to use a node name when initiating a LAT
+      connection.  Alternately, some administrators want particular
+      users to use certain machines as a primitive form of load
+      balancing (although LAT knows how to do load balancing itself).
+
+   A summary of the Login-LAT-Service Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 54]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Type
+
+      34 for Login-LAT-Service.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets, and contains the identity
+      of the LAT service to use.  The LAT Architecture allows this
+      string to contain $ (dollar), - (hyphen), . (period), _
+      (underscore), numerics, upper and lower case alphabetics, and the
+      ISO Latin-1 character set extension [11].  All LAT string
+      comparisons are case insensitive.
+
+5.35.  Login-LAT-Node
+
+   Description
+
+      This Attribute indicates the Node with which the user is to be
+      automatically connected by LAT.  It MAY be used in Access-Accept
+      packets, but only when LAT is specified as the Login-Service.  It
+      MAY be used in an Access-Request packet as a hint to the server,
+      but the server is not required to honor the hint.
+
+   A summary of the Login-LAT-Node Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      35 for Login-LAT-Node.
+
+   Length
+
+      >= 3
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 55]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   String
+
+      The String field is one or more octets, and contains the identity
+      of the LAT Node to connect the user to.  The LAT Architecture
+      allows this string to contain $ (dollar), - (hyphen), . (period),
+      _ (underscore), numerics, upper and lower case alphabetics, and
+      the ISO Latin-1 character set extension.  All LAT string
+      comparisons are case insensitive.
+
+5.36.  Login-LAT-Group
+
+   Description
+
+      This Attribute contains a string identifying the LAT group codes
+      which this user is authorized to use.  It MAY be used in Access-
+      Accept packets, but only when LAT is specified as the Login-
+      Service.  It MAY be used in an Access-Request packet as a hint to
+      the server, but the server is not required to honor the hint.
+
+      LAT supports 256 different group codes, which LAT uses as a form
+      of access rights.  LAT encodes the group codes as a 256 bit
+      bitmap.
+
+      Administrators can assign one or more of the group code bits at
+      the LAT service provider; it will only accept LAT connections that
+      have these group codes set in the bit map. The administrators
+      assign a bitmap of authorized group codes to each user; LAT gets
+      these from the operating system, and uses these in its requests to
+      the service providers.
+
+   A summary of the Login-LAT-Group Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      36 for Login-LAT-Group.
+
+   Length
+
+      34
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 56]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   String
+
+      The String field is a 32 octet bit map, most significant octet
+      first.  A robust implementation SHOULD support the field as
+      undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.37.  Framed-AppleTalk-Link
+
+   Description
+
+      This Attribute indicates the AppleTalk network number which should
+      be used for the serial link to the user, which is another
+      AppleTalk router.  It is only used in Access-Accept packets.  It
+      is never used when the user is not another router.
+
+   A summary of the Framed-AppleTalk-Link Attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      37 for Framed-AppleTalk-Link.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  Despite the size of the field,
+      values range from 0 to 65535.  The special value of 0 indicates
+      that this is an unnumbered serial link.  A value of 1-65535 means
+      that the serial line between the NAS and the user should be
+      assigned that value as an AppleTalk network number.
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 57]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+5.38.  Framed-AppleTalk-Network
+
+   Description
+
+      This Attribute indicates the AppleTalk Network number which the
+      NAS should probe to allocate an AppleTalk node for the user.  It
+      is only used in Access-Accept packets.  It is never used when the
+      user is another router.  Multiple instances of this Attribute
+      indicate that the NAS may probe using any of the network numbers
+      specified.
+
+   A summary of the Framed-AppleTalk-Network Attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      38 for Framed-AppleTalk-Network.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  Despite the size of the field,
+      values range from 0 to 65535.  The special value 0 indicates that
+      the NAS should assign a network for the user, using its default
+      cable range.  A value between 1 and 65535 (inclusive) indicates
+      the AppleTalk Network the NAS should probe to find an address for
+      the user.
+
+5.39.  Framed-AppleTalk-Zone
+
+   Description
+
+      This Attribute indicates the AppleTalk Default Zone to be used for
+      this user.  It is only used in Access-Accept packets.  Multiple
+      instances of this attribute in the same packet are not allowed.
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 58]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   A summary of the Framed-AppleTalk-Zone Attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      39 for Framed-AppleTalk-Zone.
+
+   Length
+
+      >= 3
+
+   String
+
+      The name of the Default AppleTalk Zone to be used for this user.
+      A robust implementation SHOULD support the field as
+      undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+5.40.  CHAP-Challenge
+
+   Description
+
+      This Attribute contains the CHAP Challenge sent by the NAS to a
+      PPP Challenge-Handshake Authentication Protocol (CHAP) user.  It
+      is only used in Access-Request packets.
+
+      If the CHAP challenge value is 16 octets long it MAY be placed in
+      the Request Authenticator field instead of using this attribute.
+
+   A summary of the CHAP-Challenge Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |    String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 59]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Type
+
+      60 for CHAP-Challenge.
+
+   Length
+
+      >= 7
+
+   String
+
+      The String field contains the CHAP Challenge.
+
+5.41.  NAS-Port-Type
+
+   Description
+
+      This Attribute indicates the type of the physical port of the NAS
+      which is authenticating the user.  It can be used instead of or in
+      addition to the NAS-Port (5) attribute.  It is only used in
+      Access-Request packets.  Either NAS-Port (5) or NAS-Port-Type or
+      both SHOULD be present in an Access-Request packet, if the NAS
+      differentiates among its ports.
+
+   A summary of the NAS-Port-Type Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      61 for NAS-Port-Type.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.  "Virtual" refers to a connection
+      to the NAS via some transport protocol, instead of through a
+      physical port.  For example, if a user telnetted into a NAS to
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 60]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+      authenticate himself as an Outbound-User, the Access-Request might
+      include NAS-Port-Type = Virtual as a hint to the RADIUS server
+      that the user was not on a physical port.
+
+      0       Async
+      1       Sync
+      2       ISDN Sync
+      3       ISDN Async V.120
+      4       ISDN Async V.110
+      5       Virtual
+      6       PIAFS
+      7       HDLC Clear Channel
+      8       X.25
+      9       X.75
+      10      G.3 Fax
+      11      SDSL - Symmetric DSL
+      12      ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
+              Modulation
+      13      ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
+      14      IDSL - ISDN Digital Subscriber Line
+      15      Ethernet
+      16      xDSL - Digital Subscriber Line of unknown type
+      17      Cable
+      18      Wireless - Other
+      19      Wireless - IEEE 802.11
+
+      PIAFS is a form of wireless ISDN commonly used in Japan, and
+      stands for PHS (Personal Handyphone System) Internet Access Forum
+      Standard (PIAFS).
+
+5.42.  Port-Limit
+
+   Description
+
+      This Attribute sets the maximum number of ports to be provided to
+      the user by the NAS.  This Attribute MAY be sent by the server to
+      the client in an Access-Accept packet.  It is intended for use in
+      conjunction with Multilink PPP [12] or similar uses.  It MAY also
+      be sent by the NAS to the server as a hint that that many ports
+      are desired for use, but the server is not required to honor the
+      hint.
+
+   A summary of the Port-Limit Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 61]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      62 for Port-Limit.
+
+   Length
+
+      6
+
+   Value
+
+      The field is 4 octets, containing a 32-bit unsigned integer with
+      the maximum number of ports this user should be allowed to connect
+      to on the NAS.
+
+5.43.  Login-LAT-Port
+
+   Description
+
+      This Attribute indicates the Port with which the user is to be
+      connected by LAT.  It MAY be used in Access-Accept packets, but
+      only when LAT is specified as the Login-Service.  It MAY be used
+      in an Access-Request packet as a hint to the server, but the
+      server is not required to honor the hint.
+
+   A summary of the Login-LAT-Port Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      63 for Login-LAT-Port.
+
+   Length
+
+      >= 3
+
+
+
+Rigney, et al.              Standards Track                    [Page 62]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   String
+
+      The String field is one or more octets, and contains the identity
+      of the LAT port to use.  The LAT Architecture allows this string
+      to contain $ (dollar), - (hyphen), . (period), _ (underscore),
+      numerics, upper and lower case alphabetics, and the ISO Latin-1
+      character set extension.  All LAT string comparisons are case
+      insensitive.
+
+5.44.  Table of Attributes
+
+   The following table provides a guide to which attributes may be found
+   in which kinds of packets, and in what quantity.
+
+   Request   Accept   Reject   Challenge   #    Attribute
+   0-1       0-1      0        0            1   User-Name
+   0-1       0        0        0            2   User-Password [Note 1]
+   0-1       0        0        0            3   CHAP-Password [Note 1]
+   0-1       0        0        0            4   NAS-IP-Address [Note 2]
+   0-1       0        0        0            5   NAS-Port
+   0-1       0-1      0        0            6   Service-Type
+   0-1       0-1      0        0            7   Framed-Protocol
+   0-1       0-1      0        0            8   Framed-IP-Address
+   0-1       0-1      0        0            9   Framed-IP-Netmask
+   0         0-1      0        0           10   Framed-Routing
+   0         0+       0        0           11   Filter-Id
+   0-1       0-1      0        0           12   Framed-MTU
+   0+        0+       0        0           13   Framed-Compression
+   0+        0+       0        0           14   Login-IP-Host
+   0         0-1      0        0           15   Login-Service
+   0         0-1      0        0           16   Login-TCP-Port
+   0         0+       0+       0+          18   Reply-Message
+   0-1       0-1      0        0           19   Callback-Number
+   0         0-1      0        0           20   Callback-Id
+   0         0+       0        0           22   Framed-Route
+   0         0-1      0        0           23   Framed-IPX-Network
+   0-1       0-1      0        0-1         24   State [Note 1]
+   0         0+       0        0           25   Class
+   0+        0+       0        0+          26   Vendor-Specific
+   0         0-1      0        0-1         27   Session-Timeout
+   0         0-1      0        0-1         28   Idle-Timeout
+   0         0-1      0        0           29   Termination-Action
+   0-1       0        0        0           30   Called-Station-Id
+   0-1       0        0        0           31   Calling-Station-Id
+   0-1       0        0        0           32   NAS-Identifier [Note 2]
+   0+        0+       0+       0+          33   Proxy-State
+   0-1       0-1      0        0           34   Login-LAT-Service
+   0-1       0-1      0        0           35   Login-LAT-Node
+
+
+
+Rigney, et al.              Standards Track                    [Page 63]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   0-1       0-1      0        0           36   Login-LAT-Group
+   0         0-1      0        0           37   Framed-AppleTalk-Link
+   0         0+       0        0           38   Framed-AppleTalk-Network
+   0         0-1      0        0           39   Framed-AppleTalk-Zone
+   0-1       0        0        0           60   CHAP-Challenge
+   0-1       0        0        0           61   NAS-Port-Type
+   0-1       0-1      0        0           62   Port-Limit
+   0-1       0-1      0        0           63   Login-LAT-Port
+   Request   Accept   Reject   Challenge   #    Attribute
+
+   [Note 1] An Access-Request MUST contain either a User-Password or a
+   CHAP-Password or State.  An Access-Request MUST NOT contain both a
+   User-Password and a CHAP-Password.  If future extensions allow other
+   kinds of authentication information to be conveyed, the attribute for
+   that can be used in an Access-Request instead of User-Password or
+   CHAP-Password.
+
+   [Note 2] An Access-Request MUST contain either a NAS-IP-Address or a
+   NAS-Identifier (or both).
+
+   The following table defines the meaning of the above table entries.
+
+0     This attribute MUST NOT be present in packet.
+0+    Zero or more instances of this attribute MAY be present in packet.
+0-1   Zero or one instance of this attribute MAY be present in packet.
+1     Exactly one instance of this attribute MUST be present in packet.
+
+6.  IANA Considerations
+
+   This section provides guidance to the Internet Assigned Numbers
+   Authority (IANA) regarding registration of values related to the
+   RADIUS protocol, in accordance with BCP 26 [13].
+
+   There are three name spaces in RADIUS that require registration:
+   Packet Type Codes, Attribute Types, and Attribute Values (for certain
+   Attributes).
+
+   RADIUS is not intended as a general-purpose Network Access Server
+   (NAS) management protocol, and allocations should not be made for
+   purposes unrelated to Authentication, Authorization or Accounting.
+
+6.1.  Definition of Terms
+
+   The following terms are used here with the meanings defined in
+   BCP 26: "name space", "assigned value", "registration".
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 64]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   The following policies are used here with the meanings defined in
+   BCP 26: "Private Use", "First Come First Served", "Expert Review",
+   "Specification Required", "IETF Consensus", "Standards Action".
+
+6.2.  Recommended Registration Policies
+
+   For registration requests where a Designated Expert should be
+   consulted, the IESG Area Director for Operations should appoint the
+   Designated Expert.
+
+   For registration requests requiring Expert Review, the ietf-radius
+   mailing list should be consulted.
+
+   Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have
+   been allocated.  Because a new Packet Type has considerable impact on
+   interoperability, a new Packet Type Code requires Standards Action,
+   and should be allocated starting at 14.
+
+   Attribute Types have a range from 1 to 255, and are the scarcest
+   resource in RADIUS, thus must be allocated with care.  Attributes
+   1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for
+   re-use.  Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated
+   following Expert Review, with Specification Required.  Release of
+   blocks of Attribute Types (more than 3 at a time for a given purpose)
+   should require IETF Consensus.  It is recommended that attributes 17
+   and 21 be used only after all others are exhausted.
+
+   Note that RADIUS defines a mechanism for Vendor-Specific extensions
+   (Attribute 26) and the use of that should be encouraged instead of
+   allocation of global attribute types, for functions specific only to
+   one vendor's implementation of RADIUS, where no interoperability is
+   deemed useful.
+
+   As stated in the "Attributes" section above:
+
+      "[Attribute Type] Values 192-223 are reserved for experimental
+      use, values 224-240 are reserved for implementation-specific use,
+      and values 241-255 are reserved and should not be used."
+
+   Therefore Attribute values 192-240 are considered Private Use, and
+   values 241-255 require Standards Action.
+
+   Certain attributes (for example, NAS-Port-Type) in RADIUS define a
+   list of values to correspond with various meanings.  There can be 4
+   billion (2^32) values for each attribute. Adding additional values to
+   the list can be done on a First Come, First Served basis by the IANA.
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 65]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+7.  Examples
+
+   A few examples are presented to illustrate the flow of packets and
+   use of typical attributes.  These examples are not intended to be
+   exhaustive, many others are possible.  Hexadecimal dumps of the
+   example packets are given in network byte order, using the shared
+   secret "xyzzy5461".
+
+7.1.  User Telnet to Specified Host
+
+   The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+   RADIUS Server for a user named nemo logging in on port 3 with
+   password "arctangent".
+
+   The Request Authenticator is a 16 octet random number generated by
+   the NAS.
+
+   The User-Password is 16 octets of password padded at end with nulls,
+   XORed with MD5(shared secret|Request Authenticator).
+
+      01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb
+      98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d
+      93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8
+      01 10 05 06 00 00 00 03
+
+       1 Code = Access-Request (1)
+       1 ID = 0
+       2 Length = 56
+      16 Request Authenticator
+
+      Attributes:
+       6  User-Name = "nemo"
+      18  User-Password
+       6  NAS-IP-Address = 192.168.1.16
+       6  NAS-Port = 3
+
+   The RADIUS server authenticates nemo, and sends an Access-Accept UDP
+   packet to the NAS telling it to telnet nemo to host 192.168.1.3.
+
+   The Response Authenticator is a 16-octet MD5 checksum of the code
+   (2), id (0), Length (38), the Request Authenticator from above, the
+   attributes in this reply, and the shared secret.
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 66]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+      02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf
+      9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00
+      0e 06 c0 a8 01 03
+
+       1 Code = Access-Accept (2)
+       1 ID = 0 (same as in Access-Request)
+       2 Length = 38
+      16 Response Authenticator
+
+      Attributes:
+       6  Service-Type (6) = Login (1)
+       6  Login-Service (15) = Telnet (0)
+       6  Login-IP-Host (14) = 192.168.1.3
+
+7.2.  Framed User Authenticating with CHAP
+
+   The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+   RADIUS Server for a user named flopsy logging in on port 20 with PPP,
+   authenticating using CHAP.  The NAS sends along the Service-Type and
+   Framed-Protocol attributes as a hint to the RADIUS server that this
+   user is looking for PPP, although the NAS is not required to do so.
+
+   The Request Authenticator is a 16 octet random number generated by
+   the NAS, and is also used as the CHAP Challenge.
+
+   The CHAP-Password consists of a 1 octet CHAP ID, in this case 22,
+   followed by the 16 octet CHAP response.
+
+      01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e
+      0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9
+      75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04
+      06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00
+      02 07 06 00 00 00 01
+
+       1 Code = 1     (Access-Request)
+       1 ID = 1
+       2 Length = 71
+      16 Request Authenticator
+
+      Attributes:
+       8  User-Name (1) = "flopsy"
+      19  CHAP-Password (3)
+       6  NAS-IP-Address (4) = 192.168.1.16
+       6  NAS-Port (5) = 20
+       6  Service-Type (6) = Framed (2)
+       6  Framed-Protocol (7) = PPP (1)
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 67]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   The RADIUS server authenticates flopsy, and sends an Access-Accept
+   UDP packet to the NAS telling it to start PPP service and assign an
+   address for the user out of its dynamic address pool.
+
+   The Response Authenticator is a 16-octet MD5 checksum of the code
+   (2), id (1), Length (56), the Request Authenticator from above, the
+   attributes in this reply, and the shared secret.
+
+      02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0
+      3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01
+      08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00
+      00 01 0c 06 00 00 05 dc
+
+       1 Code = Access-Accept (2)
+       1 ID = 1 (same as in Access-Request)
+       2 Length = 56
+      16 Response Authenticator
+
+      Attributes:
+       6  Service-Type (6) = Framed (2)
+       6  Framed-Protocol (7) = PPP (1)
+       6  Framed-IP-Address (8) = 255.255.255.254
+       6  Framed-Routing (10) = None (0)
+       6  Framed-Compression (13) = VJ TCP/IP Header Compression (1)
+       6  Framed-MTU (12) = 1500
+
+7.3.  User with Challenge-Response card
+
+   The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
+   RADIUS Server for a user named mopsy logging in on port 7.  The user
+   enters the dummy password "challenge" in this example.  The challenge
+   and response generated by the smart card for this example are
+   "32769430" and "99101462".
+
+   The Request Authenticator is a 16 octet random number generated by
+   the NAS.
+
+   The User-Password is 16 octets of password, in this case "challenge",
+   padded at the end with nulls, XORed with MD5(shared secret|Request
+   Authenticator).
+
+      01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9
+      30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75
+      73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0
+      a8 01 10 05 06 00 00 00 07
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 68]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+       1 Code = Access-Request (1)
+       1 ID = 2
+       2 Length = 57
+      16 Request Authenticator
+
+      Attributes:
+       7 User-Name (1) = "mopsy"
+      18 User-Password (2)
+       6  NAS-IP-Address (4) = 192.168.1.16
+       6  NAS-Port (5) = 7
+
+   The RADIUS server decides to challenge mopsy, sending back a
+   challenge string and looking for a response.  The RADIUS server
+   therefore and sends an Access-Challenge UDP packet to the NAS.
+
+   The Response Authenticator is a 16-octet MD5 checksum of the code
+   (11), id (2), length (78), the Request Authenticator from above, the
+   attributes in this reply, and the shared secret.
+
+   The Reply-Message is "Challenge 32769430.  Enter response at prompt."
+
+   The State is a magic cookie to be returned along with user's
+   response; in this example 8 octets of data (33 32 37 36 39 34 33 30
+   in hex).
+
+      0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c
+      71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20
+      33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72
+      20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f
+      6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30
+
+       1 Code = Access-Challenge (11)
+       1 ID = 2 (same as in Access-Request)
+       2 Length = 78
+      16 Response Authenticator
+
+      Attributes:
+      48  Reply-Message (18)
+      10  State (24)
+
+   The user enters his response, and the NAS send a new Access-Request
+   with that response, and includes the State Attribute.
+
+   The Request Authenticator is a new 16 octet random number.
+
+   The User-Password is 16 octets of the user's response, in this case
+   "99101462", padded at the end with nulls, XORed with MD5(shared
+   secret|Request Authenticator).
+
+
+
+Rigney, et al.              Standards Track                    [Page 69]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   The state is the magic cookie from the Access-Challenge packet,
+   unchanged.
+
+      01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07
+      c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f
+      20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0
+      a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39
+      34 33 30
+
+       1 Code = Access-Request (1)
+       1 ID = 3 (Note that this changes.)
+       2 Length = 67
+      16 Request Authenticator
+
+      Attributes:
+       7  User-Name = "mopsy"
+      18  User-Password
+       6  NAS-IP-Address (4) = 192.168.1.16
+       6  NAS-Port (5) = 7
+      10  State (24)
+
+   The Response was incorrect (for the sake of example), so the RADIUS
+   server tells the NAS to reject the login attempt.
+
+   The Response Authenticator is a 16 octet MD5 checksum of the code
+   (3), id (3), length(20), the Request Authenticator from above, the
+   attributes in this reply (in this case, none), and the shared secret.
+
+      03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f
+      9e 74 6a a0
+
+       1 Code = Access-Reject (3)
+       1 ID = 3 (same as in Access-Request)
+       2 Length = 20
+      16 Response Authenticator
+
+      Attributes:
+         (none, although a Reply-Message could be sent)
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 70]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+8.  Security Considerations
+
+   Security issues are the primary topic of this document.
+
+   In practice, within or associated with each RADIUS server, there is a
+   database which associates "user" names with authentication
+   information ("secrets").  It is not anticipated that a particular
+   named user would be authenticated by multiple methods.  This would
+   make the user vulnerable to attacks which negotiate the least secure
+   method from among a set.  Instead, for each named user there should
+   be an indication of exactly one method used to authenticate that user
+   name.  If a user needs to make use of different authentication
+   methods under different circumstances, then distinct user names
+   SHOULD be employed, each of which identifies exactly one
+   authentication method.
+
+   Passwords and other secrets should be stored at the respective ends
+   such that access to them is as limited as possible.  Ideally, the
+   secrets should only be accessible to the process requiring access in
+   order to perform the authentication.
+
+   The secrets should be distributed with a mechanism that limits the
+   number of entities that handle (and thus gain knowledge of) the
+   secret.  Ideally, no unauthorized person should ever gain knowledge
+   of the secrets.  It is possible to achieve this with SNMP Security
+   Protocols [14], but such a mechanism is outside the scope of this
+   specification.
+
+   Other distribution methods are currently undergoing research and
+   experimentation.  The SNMP Security document [14] also has an
+   excellent overview of threats to network protocols.
+
+   The User-Password hiding mechanism described in Section 5.2 has not
+   been subjected to significant amounts of cryptanalysis in the
+   published literature.  Some in the IETF community are concerned that
+   this method might not provide sufficient confidentiality protection
+   [15] to passwords transmitted using RADIUS.  Users should evaluate
+   their threat environment and consider whether additional security
+   mechanisms should be employed.
+
+9.  Change Log
+
+   The following changes have been made from RFC 2138:
+
+   Strings should use UTF-8 instead of US-ASCII and should be handled as
+   8-bit data.
+
+   Integers and dates are now defined as 32 bit unsigned values.
+
+
+
+Rigney, et al.              Standards Track                    [Page 71]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   Updated list of attributes that can be included in Access-Challenge
+   to be consistent with the table of attributes.
+
+   User-Name mentions Network Access Identifiers.
+
+   User-Name may now be sent in Access-Accept for use with accounting
+   and Rlogin.
+
+   Values added for Service-Type, Login-Service, Framed-Protocol,
+   Framed-Compression, and NAS-Port-Type.
+
+   NAS-Port can now use all 32 bits.
+
+   Examples now include hexadecimal displays of the packets.
+
+   Source UDP port must be used in conjunction with the Request
+   Identifier when identifying duplicates.
+
+   Multiple subattributes may be allowed in a Vendor-Specific attribute.
+
+   An Access-Request is now required to contain either a NAS-IP-Address
+   or NAS-Identifier (or may contain both).
+
+   Added notes under "Operations" with more information on proxy,
+   retransmissions, and keep-alives.
+
+   If multiple Attributes with the same Type are present, the order of
+   Attributes with the same Type MUST be preserved by any proxies.
+
+   Clarified Proxy-State.
+
+   Clarified that Attributes must not depend on position within the
+   packet, as long as Attributes of the same type are kept in order.
+
+   Added IANA Considerations section.
+
+   Updated section on "Proxy" under "Operations".
+
+   Framed-MTU can now be sent in Access-Request as a hint.
+
+   Updated Security Considerations.
+
+   Text strings identified as a subset of string, to clarify use of
+   UTF-8.
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 72]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+10.  References
+
+   [1]   Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
+         Authentication Dial In User Service (RADIUS)", RFC 2138, April
+         1997.
+
+   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March, 1997.
+
+   [3]   Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm",
+         RFC 1321, April 1992.
+
+   [4]   Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+         1980.
+
+   [5]   Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+   [6]   Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
+         1700, October 1994.
+
+   [7]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+         2279, January 1998.
+
+   [8]   Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
+         2486, January 1999.
+
+   [9]   Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
+         Private Communications in a Public World", Prentice Hall, March
+         1995, ISBN 0-13-061466-1.
+
+   [10]  Jacobson, V., "Compressing TCP/IP headers for low-speed serial
+         links", RFC 1144, February 1990.
+
+   [11]  ISO 8859. International Standard -- Information Processing --
+         8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
+         Alphabet No. 1, ISO 8859-1:1987.
+
+   [12]  Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
+         Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August
+         1996.
+
+   [13]  Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+   [14]  Galvin, J., McCloghrie, K. and J. Davin, "SNMP Security
+         Protocols", RFC 1352, July 1992.
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 73]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+   [15]  Dobbertin, H., "The Status of MD5 After a Recent Attack",
+         CryptoBytes Vol.2 No.2, Summer 1996.
+
+11.  Acknowledgements
+
+   RADIUS was originally developed by Steve Willens of Livingston
+   Enterprises for their PortMaster series of Network Access Servers.
+
+12.  Chair's Address
+
+   The working group can be contacted via the current chair:
+
+   Carl Rigney
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   Phone: +1 925 737 2100
+   EMail: cdr@telemancy.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 74]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+13.  Authors' Addresses
+
+   Questions about this memo can also be directed to:
+
+   Carl Rigney
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   Phone: +1 925 737 2100
+   EMail: cdr@telemancy.com
+
+
+   Allan C. Rubens
+   Merit Network, Inc.
+   4251 Plymouth Road
+   Ann Arbor, Michigan  48105-2785
+
+   EMail: acr@merit.edu
+
+
+   William Allen Simpson
+   Daydreamer
+   Computer Systems Consulting Services
+   1384 Fontaine
+   Madison Heights, Michigan  48071
+
+   EMail: wsimpson@greendragon.com
+
+
+   Steve Willens
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   EMail: steve@livingston.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 75]
+
+RFC 2865                         RADIUS                        June 2000
+
+
+14.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.              Standards Track                    [Page 76]
+
diff --git a/doc/rfc2866.txt b/doc/rfc2866.txt
new file mode 100644
index 0000000..82da1dc
--- /dev/null
+++ b/doc/rfc2866.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group                                          C. Rigney
+Request for Comments: 2866                                    Livingston
+Category: Informational                                        June 2000
+Obsoletes: 2139
+
+
+                           RADIUS Accounting
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document describes a protocol for carrying accounting
+   information between a Network Access Server and a shared Accounting
+   Server.
+
+Implementation Note
+
+   This memo documents the RADIUS Accounting protocol.  The early
+   deployment of RADIUS Accounting was done using UDP port number 1646,
+   which conflicts with the "sa-msg-port" service.  The officially
+   assigned port number for RADIUS Accounting is 1813.
+
+Table of Contents
+
+   1.     Introduction ....................................    2
+     1.1    Specification of Requirements .................    3
+     1.2    Terminology ...................................    3
+   2.     Operation .......................................    4
+     2.1    Proxy .........................................    4
+   3.     Packet Format ...................................    5
+   4.     Packet Types ...................................     7
+     4.1    Accounting-Request ............................    8
+     4.2    Accounting-Response ...........................    9
+   5.     Attributes ......................................   10
+     5.1    Acct-Status-Type ..............................   12
+     5.2    Acct-Delay-Time ...............................   13
+     5.3    Acct-Input-Octets .............................   14
+     5.4    Acct-Output-Octets ............................   15
+     5.5    Acct-Session-Id ...............................   15
+
+
+
+Rigney                       Informational                      [Page 1]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+     5.6    Acct-Authentic ................................   16
+     5.7    Acct-Session-Time .............................   17
+     5.8    Acct-Input-Packets ............................   18
+     5.9    Acct-Output-Packets ...........................   18
+     5.10   Acct-Terminate-Cause ..........................   19
+     5.11   Acct-Multi-Session-Id .........................   21
+     5.12   Acct-Link-Count ...............................   22
+     5.13   Table of Attributes ...........................   23
+   6.     IANA Considerations .............................   25
+   7.     Security Considerations .........................   25
+   8.     Change Log ......................................   25
+   9.     References ......................................   26
+   10.    Acknowledgements ................................   26
+   11.    Chair's Address .................................   26
+   12.    Author's Address ................................   27
+   13.    Full Copyright Statement ........................   28
+
+1.  Introduction
+
+   Managing dispersed serial line and modem pools for large numbers of
+   users can create the need for significant administrative support.
+   Since modem pools are by definition a link to the outside world, they
+   require careful attention to security, authorization and accounting.
+   This can be best achieved by managing a single "database" of users,
+   which allows for authentication (verifying user name and password) as
+   well as configuration information detailing the type of service to
+   deliver to the user (for example, SLIP, PPP, telnet, rlogin).
+
+   The RADIUS (Remote Authentication Dial In User Service) document [2]
+   specifies the RADIUS protocol used for Authentication and
+   Authorization.  This memo extends the use of the RADIUS protocol to
+   cover delivery of accounting information from the Network Access
+   Server (NAS) to a RADIUS accounting server.
+
+   This document obsoletes RFC 2139 [1].  A summary of the changes
+   between this document and RFC 2139 is available in the "Change Log"
+   appendix.
+
+   Key features of RADIUS Accounting are:
+
+      Client/Server Model
+
+          A Network Access Server (NAS) operates as a client of the
+          RADIUS accounting server.  The client is responsible for
+          passing user accounting information to a designated RADIUS
+          accounting server.
+
+
+
+
+
+Rigney                       Informational                      [Page 2]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+          The RADIUS accounting server is responsible for receiving the
+          accounting request and returning a response to the client
+          indicating that it has successfully received the request.
+
+          The RADIUS accounting server can act as a proxy client to
+          other kinds of accounting servers.
+
+      Network Security
+
+          Transactions between the client and RADIUS accounting server
+          are authenticated through the use of a shared secret, which is
+          never sent over the network.
+
+      Extensible Protocol
+
+          All transactions are comprised of variable length Attribute-
+          Length-Value 3-tuples.  New attribute values can be added
+          without disturbing existing implementations of the protocol.
+
+1.1.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].  These
+   key words mean the same thing whether capitalized or not.
+
+1.2.  Terminology
+
+   This document uses the following terms:
+
+   service   The NAS provides a service to the dial-in user, such as PPP
+             or Telnet.
+
+   session   Each service provided by the NAS to a dial-in user
+             constitutes a session, with the beginning of the session
+             defined as the point where service is first provided and
+             the end of the session defined as the point where service
+             is ended.  A user may have multiple sessions in parallel or
+             series if the NAS supports that, with each session
+             generating a separate start and stop accounting record with
+             its own Acct-Session-Id.
+
+   silently discard
+             This means the implementation discards the packet without
+             further processing.  The implementation SHOULD provide the
+             capability of logging the error, including the contents of
+             the silently discarded packet, and SHOULD record the event
+             in a statistics counter.
+
+
+
+Rigney                       Informational                      [Page 3]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+2.  Operation
+
+   When a client is configured to use RADIUS Accounting, at the start of
+   service delivery it will generate an Accounting Start packet
+   describing the type of service being delivered and the user it is
+   being delivered to, and will send that to the RADIUS Accounting
+   server, which will send back an acknowledgement that the packet has
+   been received.  At the end of service delivery the client will
+   generate an Accounting Stop packet describing the type of service
+   that was delivered and optionally statistics such as elapsed time,
+   input and output octets, or input and output packets.  It will send
+   that to the RADIUS Accounting server, which will send back an
+   acknowledgement that the packet has been received.
+
+   The Accounting-Request (whether for Start or Stop) is submitted to
+   the RADIUS accounting server via the network. It is recommended that
+   the client continue attempting to send the Accounting-Request packet
+   until it receives an acknowledgement, using some form of backoff.  If
+   no response is returned within a length of time, the request is re-
+   sent a number of times.  The client can also forward requests to an
+   alternate server or servers in the event that the primary server is
+   down or unreachable.  An alternate server can be used either after a
+   number of tries to the primary server fail, or in a round-robin
+   fashion.  Retry and fallback algorithms are the topic of current
+   research and are not specified in detail in this document.
+
+   The RADIUS accounting server MAY make requests of other servers in
+   order to satisfy the request, in which case it acts as a client.
+
+   If the RADIUS accounting server is unable to successfully record the
+   accounting packet it MUST NOT send an Accounting-Response
+   acknowledgment to the client.
+
+2.1.  Proxy
+
+   See the "RADIUS" RFC [2] for information on Proxy RADIUS.  Proxy
+   Accounting RADIUS works the same way, as illustrated by the following
+   example.
+
+   1.    The NAS sends an accounting-request to the forwarding server.
+
+   2.    The forwarding server logs the accounting-request (if desired),
+         adds its Proxy-State (if desired) after any other Proxy-State
+         attributes, updates the Request Authenticator, and forwards the
+         request to the remote server.
+
+
+
+
+
+
+Rigney                       Informational                      [Page 4]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+   3.    The remote server logs the accounting-request (if desired),
+         copies all Proxy-State attributes in order and unmodified from
+         the request to the response packet, and sends the accounting-
+         response to the forwarding server.
+
+   4.    The forwarding server strips the last Proxy-State (if it added
+         one in step 2), updates the Response Authenticator and sends
+         the accounting-response to the NAS.
+
+   A forwarding server MUST not modify existing Proxy-State or Class
+   attributes present in the packet.
+
+   A forwarding server may either perform its forwarding function in a
+   pass through manner, where it sends retransmissions on as soon as it
+   gets them, or it may take responsibility for retransmissions, for
+   example in cases where the network link between forwarding and remote
+   server has very different characteristics than the link between NAS
+   and forwarding server.
+
+   Extreme care should be used when implementing a proxy server that
+   takes responsibility for retransmissions so that its retransmission
+   policy is robust and scalable.
+
+3.  Packet Format
+
+   Exactly one RADIUS Accounting packet is encapsulated in the UDP Data
+   field [4], where the UDP Destination Port field indicates 1813
+   (decimal).
+
+   When a reply is generated, the source and destination ports are
+   reversed.
+
+   This memo documents the RADIUS Accounting protocol.  The early
+   deployment of RADIUS Accounting was done using UDP port number 1646,
+   which conflicts with the "sa-msg-port" service.  The officially
+   assigned port number for RADIUS Accounting is 1813.
+
+   A summary of the RADIUS data format is shown below.  The fields are
+   transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                      [Page 5]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                         Authenticator                         |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+   Code
+
+      The Code field is one octet, and identifies the type of RADIUS
+      packet.  When a packet is received with an invalid Code field, it
+      is silently discarded.
+
+      RADIUS Accounting Codes (decimal) are assigned as follows:
+
+           4       Accounting-Request
+           5       Accounting-Response
+
+   Identifier
+
+      The Identifier field is one octet, and aids in matching requests
+      and replies.  The RADIUS server can detect a duplicate request if
+      it has the same client source IP address and source UDP port and
+      Identifier within a short span of time.
+
+   Length
+
+      The Length field is two octets.  It indicates the length of the
+      packet including the Code, Identifier, Length, Authenticator and
+      Attribute fields.  Octets outside the range of the Length field
+      MUST be treated as padding and ignored on reception.  If the
+      packet is shorter than the Length field indicates, it MUST be
+      silently discarded.  The minimum length is 20 and maximum length
+      is 4095.
+
+   Authenticator
+
+      The Authenticator field is sixteen (16) octets.  The most
+      significant octet is transmitted first.  This value is used to
+      authenticate the messages between the client and RADIUS accounting
+      server.
+
+
+
+Rigney                       Informational                      [Page 6]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+   Request Authenticator
+
+      In Accounting-Request Packets, the Authenticator value is a 16
+      octet MD5 [5] checksum, called the Request Authenticator.
+
+      The NAS and RADIUS accounting server share a secret.  The Request
+      Authenticator field in Accounting-Request packets contains a one-
+      way MD5 hash calculated over a stream of octets consisting of the
+      Code + Identifier + Length + 16 zero octets + request attributes +
+      shared secret (where + indicates concatenation).  The 16 octet MD5
+      hash value is stored in the Authenticator field of the
+      Accounting-Request packet.
+
+      Note that the Request Authenticator of an Accounting-Request can
+      not be done the same way as the Request Authenticator of a RADIUS
+      Access-Request, because there is no User-Password attribute in an
+      Accounting-Request.
+
+   Response Authenticator
+
+      The Authenticator field in an Accounting-Response packet is called
+      the Response Authenticator, and contains a one-way MD5 hash
+      calculated over a stream of octets consisting of the Accounting-
+      Response Code, Identifier, Length, the Request Authenticator field
+      from the Accounting-Request packet being replied to, and the
+      response attributes if any, followed by the shared secret.  The
+      resulting 16 octet MD5 hash value is stored in the Authenticator
+      field of the Accounting-Response packet.
+
+   Attributes
+
+      Attributes may have multiple instances, in such a case the order
+      of attributes of the same type SHOULD be preserved.  The order of
+      attributes of different types is not required to be preserved.
+
+4.  Packet Types
+
+   The RADIUS packet type is determined by the Code field in the first
+   octet of the packet.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                      [Page 7]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+4.1.  Accounting-Request
+
+   Description
+
+      Accounting-Request packets are sent from a client (typically a
+      Network Access Server or its proxy) to a RADIUS accounting server,
+      and convey information used to provide accounting for a service
+      provided to a user.  The client transmits a RADIUS packet with the
+      Code field set to 4 (Accounting-Request).
+
+      Upon receipt of an Accounting-Request, the server MUST transmit an
+      Accounting-Response reply if it successfully records the
+      accounting packet, and MUST NOT transmit any reply if it fails to
+      record the accounting packet.
+
+      Any attribute valid in a RADIUS Access-Request or Access-Accept
+      packet is valid in a RADIUS Accounting-Request packet, except that
+      the following attributes MUST NOT be present in an Accounting-
+      Request:  User-Password, CHAP-Password, Reply-Message, State.
+      Either NAS-IP-Address or NAS-Identifier MUST be present in a
+      RADIUS Accounting-Request.  It SHOULD contain a NAS-Port or NAS-
+      Port-Type attribute or both unless the service does not involve a
+      port or the NAS does not distinguish among its ports.
+
+      If the Accounting-Request packet includes a Framed-IP-Address,
+      that attribute MUST contain the IP address of the user.  If the
+      Access-Accept used the special values for Framed-IP-Address
+      telling the NAS to assign or negotiate an IP address for the user,
+      the Framed-IP-Address (if any) in the Accounting-Request MUST
+      contain the actual IP address assigned or negotiated.
+
+   A summary of the Accounting-Request packet format is shown below.
+
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Request Authenticator                     |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+Rigney                       Informational                      [Page 8]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+   Code
+
+      4 for Accounting-Request.
+
+   Identifier
+
+      The Identifier field MUST be changed whenever the content of the
+      Attributes field changes, and whenever a valid reply has been
+      received for a previous request.  For retransmissions where the
+      contents are identical, the Identifier MUST remain unchanged.
+
+      Note that if Acct-Delay-Time is included in the attributes of an
+      Accounting-Request then the Acct-Delay-Time value will be updated
+      when the packet is retransmitted, changing the content of the
+      Attributes field and requiring a new Identifier and Request
+      Authenticator.
+
+   Request Authenticator
+
+      The Request Authenticator of an Accounting-Request contains a 16-octet
+      MD5 hash value calculated according to the method described in
+      "Request Authenticator" above.
+
+   Attributes
+
+      The Attributes field is variable in length, and contains a list of
+      Attributes.
+
+4.2.  Accounting-Response
+
+   Description
+
+      Accounting-Response packets are sent by the RADIUS accounting
+      server to the client to acknowledge that the Accounting-Request
+      has been received and recorded successfully.  If the Accounting-
+      Request was recorded successfully then the RADIUS accounting
+      server MUST transmit a packet with the Code field set to 5
+      (Accounting-Response).  On reception of an Accounting-Response by
+      the client, the Identifier field is matched with a pending
+      Accounting-Request.  The Response Authenticator field MUST contain
+      the correct response for the pending Accounting-Request.  Invalid
+      packets are silently discarded.
+
+      A RADIUS Accounting-Response is not required to have any
+      attributes in it.
+
+   A summary of the Accounting-Response packet format is shown below.
+   The fields are transmitted from left to right.
+
+
+
+Rigney                       Informational                      [Page 9]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                     Response Authenticator                    |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Attributes ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      5 for Accounting-Response.
+
+   Identifier
+
+      The Identifier field is a copy of the Identifier field of the
+      Accounting-Request which caused this Accounting-Response.
+
+   Response Authenticator
+
+      The Response Authenticator of an Accounting-Response contains a
+      16-octet MD5 hash value calculated according to the method
+      described in "Response Authenticator" above.
+
+   Attributes
+
+      The Attributes field is variable in length, and contains a list of
+      zero or more Attributes.
+
+5.  Attributes
+
+   RADIUS Attributes carry the specific authentication, authorization
+   and accounting details for the request and response.
+
+   Some attributes MAY be included more than once.  The effect of this
+   is attribute specific, and is specified in each attribute
+   description.
+
+   The end of the list of attributes is indicated by the Length of the
+   RADIUS packet.
+
+   A summary of the attribute format is shown below.  The fields are
+   transmitted from left to right.
+
+
+
+
+Rigney                       Informational                     [Page 10]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |  Value ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   Type
+
+      The Type field is one octet.  Up-to-date values of the RADIUS Type
+      field are specified in the most recent "Assigned Numbers" RFC [6].
+      Values 192-223 are reserved for experimental use, values 224-240
+      are reserved for implementation-specific use, and values 241-255
+      are reserved and should not be used.  This specification concerns
+      the following values:
+
+           1-39   (refer to RADIUS document [2])
+          40      Acct-Status-Type
+          41      Acct-Delay-Time
+          42      Acct-Input-Octets
+          43      Acct-Output-Octets
+          44      Acct-Session-Id
+          45      Acct-Authentic
+          46      Acct-Session-Time
+          47      Acct-Input-Packets
+          48      Acct-Output-Packets
+          49      Acct-Terminate-Cause
+          50      Acct-Multi-Session-Id
+          51      Acct-Link-Count
+          60+     (refer to RADIUS document [2])
+
+   Length
+
+      The Length field is one octet, and indicates the length of this
+      attribute including the Type, Length and Value fields.  If an
+      attribute is received in an Accounting-Request with an invalid
+      Length, the entire request MUST be silently discarded.
+
+   Value
+
+      The Value field is zero or more octets and contains information
+      specific to the attribute.  The format and length of the Value
+      field is determined by the Type and Length fields.
+
+      Note that none of the types in RADIUS terminate with a NUL (hex
+      00).  In particular, types "text" and "string" in RADIUS do not
+      terminate with a NUL (hex 00).  The Attribute has a length field
+      and does not use a terminator.  Text contains UTF-8 encoded 10646
+
+
+
+Rigney                       Informational                     [Page 11]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+      [7] characters and String contains 8-bit binary data.  Servers and
+      servers and clients MUST be able to deal with embedded nulls.
+      RADIUS implementers using C are cautioned not to use strcpy() when
+      handling strings.
+
+      The format of the value field is one of five data types.  Note
+      that type "text" is a subset of type "string."
+
+      text     1-253 octets containing UTF-8 encoded 10646 [7]
+               characters.  Text of length zero (0) MUST NOT be sent;
+               omit the entire attribute instead.
+
+      string   1-253 octets containing binary data (values 0 through 255
+               decimal, inclusive).  Strings of length zero (0) MUST NOT
+               be sent; omit the entire attribute instead.
+
+      address  32 bit value, most significant octet first.
+
+      integer  32 bit unsigned value, most significant octet first.
+
+      time     32 bit unsigned value, most significant octet first --
+               seconds since 00:00:00 UTC, January 1, 1970.  The
+               standard Attributes do not use this data type but it is
+               presented here for possible use in future attributes.
+
+5.1.  Acct-Status-Type
+
+   Description
+
+      This attribute indicates whether this Accounting-Request marks the
+      beginning of the user service (Start) or the end (Stop).
+
+      It MAY be used by the client to mark the start of accounting (for
+      example, upon booting) by specifying Accounting-On and to mark the
+      end of accounting (for example, just before a scheduled reboot) by
+      specifying Accounting-Off.
+
+   A summary of the Acct-Status-Type attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Rigney                       Informational                     [Page 12]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+   Type
+
+      40 for Acct-Status-Type.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       1      Start
+       2      Stop
+       3      Interim-Update
+       7      Accounting-On
+       8      Accounting-Off
+       9-14   Reserved for Tunnel Accounting
+      15      Reserved for Failed
+
+5.2.  Acct-Delay-Time
+
+   Description
+
+      This attribute indicates how many seconds the client has been
+      trying to send this record for, and can be subtracted from the
+      time of arrival on the server to find the approximate time of the
+      event generating this Accounting-Request.  (Network transit time
+      is ignored.)
+
+      Note that changing the Acct-Delay-Time causes the Identifier to
+      change; see the discussion under Identifier above.
+
+   A summary of the Acct-Delay-Time attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 13]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+   Type
+
+      41 for Acct-Delay-Time.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+5.3.  Acct-Input-Octets
+
+   Description
+
+      This attribute indicates how many octets have been received from
+      the port over the course of this service being provided, and can
+      only be present in Accounting-Request records where the Acct-
+      Status-Type is set to Stop.
+
+   A summary of the Acct-Input-Octets attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      42 for Acct-Input-Octets.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 14]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+5.4.  Acct-Output-Octets
+
+   Description
+
+      This attribute indicates how many octets have been sent to the
+      port in the course of delivering this service, and can only be
+      present in Accounting-Request records where the Acct-Status-Type
+      is set to Stop.
+
+   A summary of the Acct-Output-Octets attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      43 for Acct-Output-Octets.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+5.5.  Acct-Session-Id
+
+   Description
+
+      This attribute is a unique Accounting ID to make it easy to match
+      start and stop records in a log file.  The start and stop records
+      for a given session MUST have the same Acct-Session-Id.  An
+      Accounting-Request packet MUST have an Acct-Session-Id.  An
+      Access-Request packet MAY have an Acct-Session-Id; if it does,
+      then the NAS MUST use the same Acct-Session-Id in the Accounting-
+      Request packets for that session.
+
+      The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7]
+      characters.
+
+
+
+
+
+Rigney                       Informational                     [Page 15]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+      For example, one implementation uses a string with an 8-digit
+      upper case hexadecimal number, the first two digits increment on
+      each reboot (wrapping every 256 reboots) and the next 6 digits
+      counting from 0 for the first person logging in after a reboot up
+      to 2^24-1, about 16 million.  Other encodings are possible.
+
+   A summary of the Acct-Session-Id attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |  Text ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      44 for Acct-Session-Id.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field SHOULD be a string of UTF-8 encoded 10646 [7]
+      characters.
+
+5.6.  Acct-Authentic
+
+   Description
+
+      This attribute MAY be included in an Accounting-Request to
+      indicate how the user was authenticated, whether by RADIUS, the
+      NAS itself, or another remote authentication protocol.  Users who
+      are delivered service without being authenticated SHOULD NOT
+      generate Accounting records.
+
+   A summary of the Acct-Authentic attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Rigney                       Informational                     [Page 16]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+   Type
+
+      45 for Acct-Authentic.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+      1      RADIUS
+      2      Local
+      3      Remote
+
+5.7.  Acct-Session-Time
+
+   Description
+
+      This attribute indicates how many seconds the user has received
+      service for, and can only be present in Accounting-Request records
+      where the Acct-Status-Type is set to Stop.
+
+   A summary of the Acct-Session-Time attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      46 for Acct-Session-Time.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+
+
+
+
+Rigney                       Informational                     [Page 17]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+5.8.  Acct-Input-Packets
+
+   Description
+
+      This attribute indicates how many packets have been received from
+      the port over the course of this service being provided to a
+      Framed User, and can only be present in Accounting-Request records
+      where the Acct-Status-Type is set to Stop.
+
+   A summary of the Acct-Input-packets attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      47 for Acct-Input-Packets.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+5.9.  Acct-Output-Packets
+
+   Description
+
+      This attribute indicates how many packets have been sent to the
+      port in the course of delivering this service to a Framed User,
+      and can only be present in Accounting-Request records where the
+      Acct-Status-Type is set to Stop.
+
+   A summary of the Acct-Output-Packets attribute format is shown below.
+   The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 18]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      48 for Acct-Output-Packets.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+5.10.  Acct-Terminate-Cause
+
+   Description
+
+      This attribute indicates how the session was terminated, and can
+      only be present in Accounting-Request records where the Acct-
+      Status-Type is set to Stop.
+
+   A summary of the Acct-Terminate-Cause attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 19]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+   Type
+
+      49 for Acct-Terminate-Cause
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets, containing an integer specifying
+      the cause of session termination, as follows:
+
+      1       User Request
+      2       Lost Carrier
+      3       Lost Service
+      4       Idle Timeout
+      5       Session Timeout
+      6       Admin Reset
+      7       Admin Reboot
+      8       Port Error
+      9       NAS Error
+      10      NAS Request
+      11      NAS Reboot
+      12      Port Unneeded
+      13      Port Preempted
+      14      Port Suspended
+      15      Service Unavailable
+      16      Callback
+      17      User Error
+      18      Host Request
+
+      The termination causes are as follows:
+
+      User Request         User requested termination of service, for
+                           example with LCP Terminate or by logging out.
+
+      Lost Carrier         DCD was dropped on the port.
+
+      Lost Service         Service can no longer be provided; for
+                           example, user's connection to a host was
+                           interrupted.
+
+      Idle Timeout         Idle timer expired.
+
+      Session Timeout      Maximum session length timer expired.
+
+      Admin Reset          Administrator reset the port or session.
+
+
+
+Rigney                       Informational                     [Page 20]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+      Admin Reboot         Administrator is ending service on the NAS,
+                           for example prior to rebooting the NAS.
+
+      Port Error           NAS detected an error on the port which
+                           required ending the session.
+
+      NAS Error            NAS detected some error (other than on the
+                           port) which required ending the session.
+
+      NAS Request          NAS ended session for a non-error reason not
+                           otherwise listed here.
+
+      NAS Reboot           The NAS ended the session in order to reboot
+                           non-administratively ("crash").
+
+      Port Unneeded        NAS ended session because resource usage fell
+                           below low-water mark (for example, if a
+                           bandwidth-on-demand algorithm decided that
+                           the port was no longer needed).
+
+      Port Preempted       NAS ended session in order to allocate the
+                           port to a higher priority use.
+
+      Port Suspended       NAS ended session to suspend a virtual
+                           session.
+
+      Service Unavailable  NAS was unable to provide requested service.
+
+      Callback             NAS is terminating current session in order
+                           to perform callback for a new session.
+
+      User Error           Input from user is in error, causing
+                           termination of session.
+
+      Host Request         Login Host terminated session normally.
+
+5.11.  Acct-Multi-Session-Id
+
+   Description
+
+      This attribute is a unique Accounting ID to make it easy to link
+      together multiple related sessions in a log file.  Each session
+      linked together would have a unique Acct-Session-Id but the same
+      Acct-Multi-Session-Id.  It is strongly recommended that the Acct-
+      Multi-Session-Id contain UTF-8 encoded 10646 [7] characters.
+
+   A summary of the Acct-Session-Id attribute format is shown below.
+   The fields are transmitted from left to right.
+
+
+
+Rigney                       Informational                     [Page 21]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+   50 for Acct-Multi-Session-Id.
+
+   Length
+
+   >= 3
+
+   String
+
+   The String field SHOULD contain UTF-8 encoded 10646 [7] characters.
+
+5.12.  Acct-Link-Count
+
+   Description
+
+   This attribute gives the count of links which are known to have been
+   in a given multilink session at the time the accounting record is
+   generated.  The NAS MAY include the Acct-Link-Count attribute in any
+   Accounting-Request which might have multiple links.
+
+   A summary of the Acct-Link-Count attribute format is show below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 22]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+   Type
+
+      51 for Acct-Link-Count.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets, and contains the number of links
+      seen so far in this Multilink Session.
+
+      It may be used to make it easier for an accounting server to know
+      when it has all the records for a given Multilink session.  When
+      the number of Accounting-Requests received with Acct-Status-Type =
+      Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
+      Id's equals the largest value of Acct-Link-Count seen in those
+      Accounting-Requests, all Stop Accounting-Requests for that
+      Multilink Session have been received.
+
+      An example showing 8 Accounting-Requests should make things
+      clearer.  For clarity only the relevant attributes are shown, but
+      additional attributes containing accounting information will also
+      be present in the Accounting-Request.
+
+      Multi-Session-Id   Session-Id   Status-Type   Link-Count
+      "10"               "10"         Start         1
+      "10"               "11"         Start         2
+      "10"               "11"         Stop          2
+      "10"               "12"         Start         3
+      "10"               "13"         Start         4
+      "10"               "12"         Stop          4
+      "10"               "13"         Stop          4
+      "10"               "10"         Stop          4
+
+5.13.  Table of Attributes
+
+   The following table provides a guide to which attributes may be found
+   in Accounting-Request packets.  No attributes should be found in
+   Accounting-Response packets except Proxy-State and possibly Vendor-
+   Specific.
+
+
+                      #     Attribute
+                      0-1   User-Name
+                      0     User-Password
+                      0     CHAP-Password
+
+
+
+Rigney                       Informational                     [Page 23]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+                      0-1   NAS-IP-Address [Note 1]
+                      0-1   NAS-Port
+                      0-1   Service-Type
+                      0-1   Framed-Protocol
+                      0-1   Framed-IP-Address
+                      0-1   Framed-IP-Netmask
+                      0-1   Framed-Routing
+                      0+    Filter-Id
+                      0-1   Framed-MTU
+                      0+    Framed-Compression
+                      0+    Login-IP-Host
+                      0-1   Login-Service
+                      0-1   Login-TCP-Port
+                      0     Reply-Message
+                      0-1   Callback-Number
+                      0-1   Callback-Id
+                      0+    Framed-Route
+                      0-1   Framed-IPX-Network
+                      0     State
+                      0+    Class
+                      0+    Vendor-Specific
+                      0-1   Session-Timeout
+                      0-1   Idle-Timeout
+                      0-1   Termination-Action
+                      0-1   Called-Station-Id
+                      0-1   Calling-Station-Id
+                      0-1   NAS-Identifier [Note 1]
+                      0+    Proxy-State
+                      0-1   Login-LAT-Service
+                      0-1   Login-LAT-Node
+                      0-1   Login-LAT-Group
+                      0-1   Framed-AppleTalk-Link
+                      0-1   Framed-AppleTalk-Network
+                      0-1   Framed-AppleTalk-Zone
+                      1     Acct-Status-Type
+                      0-1   Acct-Delay-Time
+                      0-1   Acct-Input-Octets
+                      0-1   Acct-Output-Octets
+                      1     Acct-Session-Id
+                      0-1   Acct-Authentic
+                      0-1   Acct-Session-Time
+                      0-1   Acct-Input-Packets
+                      0-1   Acct-Output-Packets
+                      0-1   Acct-Terminate-Cause
+                      0+    Acct-Multi-Session-Id
+                      0+    Acct-Link-Count
+                      0     CHAP-Challenge
+
+
+
+
+Rigney                       Informational                     [Page 24]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+                      0-1   NAS-Port-Type
+                      0-1   Port-Limit
+                      0-1   Login-LAT-Port
+
+   [Note 1] An Accounting-Request MUST contain either a NAS-IP-Address
+   or a NAS-Identifier (or both).
+
+   The following table defines the above table entries.
+
+      0     This attribute MUST NOT be present
+      0+    Zero or more instances of this attribute MAY be present.
+      0-1   Zero or one instance of this attribute MAY be present.
+      1     Exactly one instance of this attribute MUST be present.
+
+6.  IANA Considerations
+
+   The Packet Type Codes, Attribute Types, and Attribute Values defined
+   in this document are registered by the Internet Assigned Numbers
+   Authority (IANA) from the RADIUS name spaces as described in the
+   "IANA Considerations" section of RFC 2865 [2], in accordance with BCP
+   26 [8].
+
+7.  Security Considerations
+
+   Security issues are discussed in sections concerning the
+   authenticator included in accounting requests and responses, using a
+   shared secret which is never sent over the network.
+
+8.  Change Log
+
+   US-ASCII replaced by UTF-8.
+
+   Added notes on Proxy.
+
+   Framed-IP-Address should contain the actual IP address of the user.
+
+   If Acct-Session-ID was sent in an access-request, it must be used in
+   the accounting-request for that session.
+
+   New values added to Acct-Status-Type.
+
+   Added an IANA Considerations section.
+
+   Updated references.
+
+   Text strings identified as a subset of string, to clarify use of
+   UTF-8.
+
+
+
+
+Rigney                       Informational                     [Page 25]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+9.  References
+
+   [1]  Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
+
+   [2]  Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
+        Authentication Dial In User Service (RADIUS)", RFC 2865, June
+        2000.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March, 1997.
+
+   [4]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+        1980.
+
+   [5]  Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC
+        1321, April 1992.
+
+   [6]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+        October 1994.
+
+   [7]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+        2279, January 1998.
+
+   [8]  Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+10.  Acknowledgements
+
+   RADIUS and RADIUS Accounting were originally developed by Steve
+   Willens of Livingston Enterprises for their PortMaster series of
+   Network Access Servers.
+
+11.  Chair's Address
+
+   The RADIUS working group can be contacted via the current chair:
+
+   Carl Rigney
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   Phone: +1 925 737 2100
+   EMail: cdr@telemancy.com
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 26]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+12.  Author's Address
+
+   Questions about this memo can also be directed to:
+
+   Carl Rigney
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   EMail: cdr@telemancy.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 27]
+
+RFC 2866                   RADIUS Accounting                   June 2000
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney                       Informational                     [Page 28]
+
diff --git a/doc/rfc2869.txt b/doc/rfc2869.txt
new file mode 100644
index 0000000..74ed7f6
--- /dev/null
+++ b/doc/rfc2869.txt
@@ -0,0 +1,2635 @@
+
+
+
+
+
+
+Network Working Group                                           C. Rigney
+Request for Comments: 2869                                     Livingston
+Category: Informational                                        W. Willats
+                                                        Cyno Technologies
+                                                               P. Calhoun
+                                                         Sun Microsystems
+                                                                June 2000
+
+
+                           RADIUS Extensions
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document describes additional attributes for carrying
+   authentication, authorization and accounting information between a
+   Network Access Server (NAS) and a shared Accounting Server using the
+   Remote Authentication Dial In User Service (RADIUS) protocol
+   described in RFC 2865 [1] and RFC 2866 [2].
+
+Table of Contents
+
+   1.     Introduction ..........................................    2
+      1.1       Specification of Requirements ...................    3
+      1.2       Terminology .....................................    3
+   2.     Operation .............................................    4
+      2.1       RADIUS support for Interim Accounting Updates....    4
+      2.2       RADIUS support for Apple Remote Access
+                Protocol ........................................    5
+      2.3       RADIUS Support for Extensible Authentication
+                Protocol (EAP) ..................................   11
+         2.3.1  Protocol Overview ...............................   11
+         2.3.2  Retransmission ..................................   13
+         2.3.3  Fragmentation ...................................   14
+         2.3.4  Examples ........................................   14
+         2.3.5  Alternative uses ................................   19
+   3.     Packet Format .........................................   19
+   4.     Packet Types ..........................................   19
+   5.     Attributes ............................................   20
+
+
+
+Rigney, et al.               Informational                      [Page 1]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+      5.1       Acct-Input-Gigawords ............................   22
+      5.2       Acct-Output-Gigawords ...........................   23
+      5.3       Event-Timestamp .................................   23
+      5.4       ARAP-Password ...................................   24
+      5.5       ARAP-Features ...................................   25
+      5.6       ARAP-Zone-Access ................................   26
+      5.7       ARAP-Security ...................................   27
+      5.8       ARAP-Security-Data ..............................   28
+      5.9       Password-Retry ..................................   28
+      5.10      Prompt ..........................................   29
+      5.11      Connect-Info ....................................   30
+      5.12      Configuration-Token .............................   31
+      5.13      EAP-Message .....................................   32
+      5.14      Message-Authenticator ...........................   33
+      5.15      ARAP-Challenge-Response .........................   35
+      5.16      Acct-Interim-Interval ...........................   36
+      5.17      NAS-Port-Id .....................................   37
+      5.18      Framed-Pool .....................................   37
+      5.19      Table of Attributes .............................   38
+   6.     IANA Considerations ...................................   39
+   7.     Security Considerations ...............................   39
+      7.1       Message-Authenticator Security ..................   39
+      7.2       EAP Security ....................................   39
+         7.2.1  Separation of EAP server and PPP authenticator ..   40
+         7.2.2  Connection hijacking ............................   41
+         7.2.3  Man in the middle attacks .......................   41
+         7.2.4  Multiple databases ..............................   41
+         7.2.5  Negotiation attacks .............................   42
+   8.     References ............................................   43
+   9.     Acknowledgements ......................................   44
+   10.    Chair's Address .......................................   44
+   11.    Authors' Addresses ....................................   45
+   12.    Full Copyright Statement ..............................   47
+
+1.  Introduction
+
+   RFC 2865 [1] describes the RADIUS Protocol as it is implemented and
+   deployed today, and RFC 2866 [2] describes how Accounting can be
+   performed with RADIUS.
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.               Informational                      [Page 2]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   This memo suggests several additional Attributes that can be added to
+   RADIUS to perform various useful functions.  These Attributes do not
+   have extensive field experience yet and should therefore be
+   considered experimental.
+
+   The Extensible Authentication Protocol (EAP) [3] is a PPP extension
+   that provides support for additional authentication methods within
+   PPP.  This memo describes how the EAP-Message and Message-
+   Authenticator attributes may be used for providing EAP support within
+   RADIUS.
+
+   All attributes are comprised of variable length Type-Length-Value 3-
+   tuples.  New attribute values can be added without disturbing
+   existing implementations of the protocol.
+
+1.1.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [4].
+
+   An implementation is not compliant if it fails to satisfy one or more
+   of the must or must not requirements for the protocols it implements.
+   An implementation that satisfies all the must, must not, should and
+   should not requirements for its protocols is said to be
+   "unconditionally compliant"; one that satisfies all the must and must
+   not requirements but not all the should or should not requirements
+   for its protocols is said to be "conditionally compliant."
+
+   A NAS that does not implement a given service MUST NOT implement the
+   RADIUS attributes for that service.  For example, a NAS that is
+   unable to offer ARAP service MUST NOT implement the RADIUS attributes
+   for ARAP.  A NAS MUST treat a RADIUS access-request requesting an
+   unavailable service as an access-reject instead.
+
+1.2.  Terminology
+
+   This document uses the following terms:
+
+   service   The NAS provides a service to the dial-in user, such as PPP
+             or Telnet.
+
+   session   Each service provided by the NAS to a dial-in user
+             constitutes a session, with the beginning of the session
+             defined as the point where service is first provided and
+             the end of the session defined as the point where service
+
+
+
+
+
+Rigney, et al.               Informational                      [Page 3]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+             is ended.  A user may have multiple sessions in parallel or
+             series if the NAS supports that, with each session
+             generating a separate start and stop accounting record.
+
+   silently discard
+             This means the implementation discards the packet without
+             further processing.  The implementation SHOULD provide the
+             capability of logging the error, including the contents of
+             the silently discarded packet, and SHOULD record the event
+             in a statistics counter.
+
+2.  Operation
+
+   Operation is identical to that defined in RFC 2865 [1] and RFC 2866
+   [2].
+
+2.1.  RADIUS support for Interim Accounting Updates
+
+   When a user is authenticated, a RADIUS server issues an Access-Accept
+   in response to a successful Access-Request. If the server wishes to
+   receive interim accounting messages for the given user it must
+   include the Acct-Interim-Interval RADIUS attribute in the message,
+   which indicates the interval in seconds between interim messages.
+
+   It is also possible to statically configure an interim value on the
+   NAS itself. Note that a locally configured value on the NAS MUST
+   override the value found in an Access-Accept.
+
+   This scheme does not break backward interoperability since a RADIUS
+   server not supporting this extension will simply not add the new
+   Attribute. NASes not supporting this extension will ignore the
+   Attribute.
+
+   Note that all information in an interim message is cumulative (i.e.
+   number of packets sent is the total since the beginning of the
+   session, not since the last interim message).
+
+   It is envisioned that an Interim Accounting record (with Acct-
+   Status-Type = Interim-Update (3)) would contain all of the attributes
+   normally found in an Accounting Stop message with the exception of
+   the Acct-Term-Cause attribute.
+
+   Since all the information is cumulative, a NAS MUST ensure that only
+   a single generation of an interim Accounting message for a given
+   session is present in the retransmission queue at any given time.
+
+
+
+
+
+
+Rigney, et al.               Informational                      [Page 4]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   A NAS MAY use a fudge factor to add a random delay between Interim
+   Accounting messages for separate sessions. This will ensure that a
+   cycle where all messages are sent at once is prevented, such as might
+   otherwise occur if a primary link was recently restored and many
+   dial-up users were directed to the same NAS at once.
+
+   The Network and NAS CPU load of using Interim Updates should be
+   carefully considered, and appropriate values of Acct-Interim-Interval
+   chosen.
+
+2.2.  RADIUS support for Apple Remote Access Protocol
+
+   The RADIUS (Remote Authentication Dial-In User Service) protocol
+   provides a method that allows multiple dial-in Network Access Server
+   (NAS) devices to share a common authentication database.
+
+   The Apple Remote Access Protocol (ARAP) provides a method for sending
+   AppleTalk network traffic over point-to-point links, typically, but
+   not exclusively, asynchronous and ISDN switched-circuit connections.
+   Though Apple is moving toward ATCP on PPP for future remote access
+   services, ARAP is still a common way for the installed base of
+   Macintosh users to make remote network connections, and is likely to
+   remain so for some time.
+
+   ARAP is supported by several NAS vendors who also support PPP, IPX
+   and other protocols in the same NAS. ARAP connections in these
+   multi-protocol devices are often not authenticated with RADIUS, or if
+   they are, each vendor creates an individual solution to the problem.
+
+   This section describes the use of additional RADIUS attributes to
+   support ARAP. RADIUS client and server implementations that implement
+   this specification should be able to authenticate ARAP connections in
+   an interoperable manner.
+
+   This section assumes prior knowledge of RADIUS, and will go into some
+   detail on the operation of ARAP before entering a detailed discussion
+   of the proposed ARAP RADIUS attributes.
+
+   There are two features of ARAP this document does not address:
+
+      1. User initiated password changing. This is not part of RADIUS,
+         but can be implemented through a software process other than
+         RADIUS.
+
+      2. Out-of-Band messages. At any time, the NAS can send messages to
+         an ARA client which appear in a dialog box on the dial-in
+         user's screen.  These are not part of authentication and do not
+         belong here. However, we note that a Reply-Message attribute in
+
+
+
+Rigney, et al.               Informational                      [Page 5]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+         an Access-Accept may be sent down to the user as a sign-on
+         message of the day string using the out-of-band channel.
+
+   We have tried to respect the spirit of the existing RADIUS protocol
+   as much as possible, making design decisions compatible with prior
+   art.  Further, we have tried to strike a balance between flooding the
+   RADIUS world with new attributes, and hiding all of ARAP operation
+   within a single multiplexed ARAP attribute string or within Extended
+   Authentication Protocol (EAP) [3] machinery.
+
+   However, we feel ARAP is enough of a departure from PPP to warrant a
+   small set of similarly named attributes of its own.
+
+   We have assumed that an ARAP-aware RADIUS server will be able to do
+   DES encryption and generate security module challenges.  This is in
+   keeping with the general RADIUS goal of smart server / simple NAS.
+
+   ARAP authenticates a connection in two phases. The first is a "Two-
+   Way DES" random number exchange, using the user's password as a key.
+   We say "Two-Way" because the ARAP NAS challenges the dial-in client
+   to authenticate itself, and the dial-in client challenges the ARAP
+   NAS to authenticate itself.
+
+   Specifically, ARAP does the following:
+
+      1. The NAS sends two 32-bit random numbers to the dial-in client
+         in an ARAP msg_auth_challenge packet.
+
+      2. The dial-in client uses the user's password to DES encrypt the
+         two random numbers sent to it by the NAS. The dial-in client
+         then sends this result, the user's name and two 32-bit random
+         numbers of its own back to the NAS in an ARAP msg_auth_request
+         packet.
+
+      3. The NAS verifies the encrypted random numbers sent by the
+         dial-in client are what it expected. If so, it encrypts the
+         dial-in client's challenge using the password and sends it back
+         to the dial-in client in an ARAP msg_auth_response packet.
+
+   Note that if the dial-in client's response was wrong,  meaning the
+   user has the wrong password, the server can initiate a retry sequence
+   up to the maximum amount of retries allowed by the NAS. In this case,
+   when the dial-in client receives the ARAP msg_auth_response packet it
+   will acknowledge it with an ARAP msg_auth_again packet.
+
+   After this first "DES Phase" the ARAP NAS MAY initiate a secondary
+   authentication phase using what Apple calls "Add-In Security
+   Modules."  Security Modules are small pieces of code which run on
+
+
+
+Rigney, et al.               Informational                      [Page 6]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   both the client and server and are allowed to read and write
+   arbitrary data across the communications link to perform additional
+   authentication functions.  Various security token vendors use this
+   mechanism to authenticate ARA callers.
+
+   Although ARAP allows security modules to read and write anything they
+   like, all existing security modules use simple challenge and response
+   cycles, with perhaps some overall control information.  This document
+   assumes all existing security modules can be supported with one or
+   more challenge/response cycles.
+
+   To complicate RADIUS and ARAP integration, ARAP sends down some
+   profile information after the DES Phase and before the Security
+   Module phase.  This means that besides the responses to challenges,
+   this profile information must also be present, at somewhat unusual
+   times.  Fortunately the information is only a few  pieces of numeric
+   data related to passwords, which this document packs into a single
+   new attribute.
+
+   Presenting an Access-Request to RADIUS on behalf of an ARAP
+   connection is straightforward. The ARAP NAS generates the random
+   number challenge, and then receives the dial-in client's response,
+   the dial-in client's challenge, and the user's name. Assuming the
+   user is not a guest, the following information is forwarded in an
+   Access-Request packet:  User-Name (up to 31 characters long),
+   Framed-Protocol (set to 3, ARAP), ARAP-Password, and any additional
+   attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id,
+   NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc.
+
+   The Request Authenticator is a NAS-generated 16 octet random number.
+   The low-order 8 octets of this number are sent to the dial-in user as
+   the two 4 octet random numbers required in the ARAP
+   msg_auth_challenge packet. Octets 0-3 are the first random number and
+   Octets 4-7 are the second random number.
+
+   The ARAP-Password in the Access-Request contains a 16 octet random
+   number field, and is used to carry the dial-in user's response to the
+   NAS challenge and the client's own challenge to the NAS.  The high-
+   order octets contain the dial-in user's challenge to the NAS (2 32-
+   bit numbers, 8 octets) and the low-order octets contain the dial-in
+   user's response to the NAS challenge (2 32-bit numbers, 8 octets).
+
+   Only one of User-Password, CHAP-Password, or ARAP-Password needs to
+   be present in an Access-Request, or one or more EAP-Messages.
+
+   If the RADIUS server does not support ARAP it SHOULD return an
+   Access-Reject to the NAS.
+
+
+
+
+Rigney, et al.               Informational                      [Page 7]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   If the RADIUS server does support ARAP, it should verify the user's
+   response using the Challenge (from the lower order 8 octets of the
+   Request Authenticator) and the user's response (from the low order 8
+   octets of the ARAP-Password).
+
+   If that authentication fails, the RADIUS server should return an
+   Access-Reject packet to the NAS, with optional Password-Retry and
+   Reply-Messages attributes.  The presence of Password-Retry indicates
+   the ARAP NAS MAY choose to initiate another challenge-response cycle,
+   up to a total number of times equal to the integer value of the
+   Password-Retry attribute.
+
+   If the user is authenticated, the RADIUS server should return an
+   Access-Accept packet (Code 2) to the NAS, with ID and Response
+   Authenticator as usual, and attributes as follows:
+
+      Service-Type of Framed-Protocol.
+
+      Framed-Protocol of ARAP (3).
+
+      Session-Timeout with the maximum connect time for the user in
+      seconds.  If the user is to be given unlimited time,
+      Session-Timeout should not be included in the Access-Accept
+      packet, and ARAP will treat that as an unlimited timeout (-1).
+
+      ARAP-Challenge-Response, containing 8 octets with the response to
+      the dial-in client's challenge. The RADIUS server calculates this
+      value by taking the dial-in client's challenge from the high order
+      8 octets of the ARAP-Password attribute and  performing DES
+      encryption on this value with the authenticating user's password
+      as the key. If the user's password is less than 8 octets in
+      length, the password is padded at the end with NULL octets to a
+      length of 8 before using it as a key. If the user's password is
+      greater than 8 octets in length, an Access-Reject MUST be sent
+      instead.
+
+      ARAP-Features, containing information that the NAS should send to
+      the user in an ARAP "feature flags" packet.
+
+         Octet 0: If zero, user cannot change their password. If non-
+         zero user can.  (RADIUS does not handle the password changing,
+         just the attribute which indicates whether ARAP indicates they
+         can.)
+
+         Octet 1: Minimum acceptable password length (0-8).
+
+
+
+
+
+
+Rigney, et al.               Informational                      [Page 8]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+         Octet 2-5: Password creation date in Macintosh format, defined
+         as 32 bits unsigned representing seconds since Midnight GMT
+         January 1, 1904.
+
+         Octet 6-9 Password Expiration Delta from create date in
+         seconds.
+
+         Octet 10-13: Current RADIUS time in Macintosh format
+
+      Optionally, a single Reply-Message with a text string up to 253
+      characters long which MAY be sent down to the user to be displayed
+      in a sign-on/message of the day dialog.
+
+      Framed-AppleTalk-Network may be included.
+
+      Framed-AppleTalk-Zone, up to 32 characters in length, may be
+      included.
+
+      ARAP defines the notion of a list of zones for a user.  Along with
+      a list of zone names, a Zone Access Flag is defined (and used by
+      the NAS) which says how to use the list of zone names. That is,
+      the dial-in user may only be allowed to see the Default Zone, or
+      only the zones in the zone list (inclusive) or any zone except
+      those in the zone list (exclusive).
+
+      The ARAP NAS handles this by having a named filter which contains
+      (at least) zone names.  This solves the problem where a single
+      RADIUS server is managing disparate NAS clients who may not be
+      able to "see" all of the zone names in a user zone list.  Zone
+      names only have meaning "at the NAS." The disadvantage of this
+      approach is that zone filters must be set up on the NAS somehow,
+      then referenced by the RADIUS Filter-Id.
+
+      ARAP-Zone-Access contains an integer which specifies how the "zone
+      list" for this user should be used.  If this attribute is present
+      and the value is 2 or 4 then a Filter-Id must also be present to
+      name a zone list filter to apply the access flag to.
+
+      The inclusion of a Callback-Number or Callback-Id attribute in the
+      Access-Accept MAY cause the ARAP NAS to disconnect after sending
+      the Feature Flags to begin callback processing in an ARAP specific
+      way.
+
+
+
+
+
+
+
+
+
+Rigney, et al.               Informational                      [Page 9]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   Other attributes may be present in the Access-Accept packet as well.
+
+   An ARAP NAS will need other information to finish bringing up the
+   connection to the dial in client, but this information can be
+   provided by the ARAP NAS without any help from RADIUS, either through
+   configuration by SNMP, a NAS administration program, or deduced by
+   the AppleTalk stack in the NAS. Specifically:
+
+      1. AppearAsNet and AppearAsNode values, sent to the client to tell
+         it what network and node numbers it should use in its datagram
+         packets.  AppearAsNet can be taken from the Framed-AppleTalk-
+         Network attribute or from the configuration or AppleTalk stack
+         onthe NAS.
+
+      2. The "default" zone - that is the name of the AppleTalk zone in
+         which the dial-in client will appear.  (Or can be specified
+         with the Framed-AppleTalk-Zone attribute.)
+
+      3. Other very NAS specific stuff such as the name of the NAS, and
+         smartbuffering information.  (Smartbuffering is an ARAP
+         mechanism for replacing common AppleTalk datagrams with small
+         tokens, to improve slow link performance in a few common
+         traffic situations.)
+
+      4. "Zone List" information for this user.  The ARAP specification
+         defines a "zone count" field which is actually unused.
+
+   RADIUS supports ARAP Security Modules in the following manner.
+
+   After DES authentication has been completed, the RADIUS server may
+   instruct the ARAP NAS to run one or more security modules for the
+   dial-in user. Although the underlying protocol supports executing
+   multiple security modules in series, in practice all current
+   implementations only allow executing one.  Through the use of
+   multiple Access-Challenge requests, multiple modules can be
+   supported, but this facility will probably never be used.
+
+   We also assume that, even though ARAP allows a free-form dialog
+   between security modules on each end of the point-to-point link, in
+   actual practice all security modules can be reduced to a simple
+   challenge/response cycle.
+
+   If the RADIUS server wishes to instruct the ARAP NAS to run a
+   security module, it should send an Access-Challenge packet to the NAS
+   with (optionally) the State attribute, plus the ARAP-Challenge-
+   Response, ARAP-Features, and two more attributes:
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 10]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   ARAP-Security: a four octet security module signature, containing a
+   Macintosh OSType.
+
+   ARAP-Security-Data, a string to carry the actual security module
+   challenge and response.
+
+   When the security module finishes executing, the security module
+   response is passed  in an ARAP-Security-Data attribute from the NAS
+   to the RADIUS server in a second Access-Request, also including the
+   State from the Access-Challenge.  The authenticator field contains no
+   special information in this case, and this can be discerned by the
+   presence of the State attribute.
+
+2.3.  RADIUS Support for Extensible Authentication Protocol (EAP)
+
+   The Extensible Authentication Protocol (EAP), described in [3],
+   provides a standard mechanism for support of additional
+   authentication methods within PPP.  Through the use of EAP, support
+   for a number of authentication schemes may be added, including smart
+   cards, Kerberos, Public Key, One Time Passwords, and others.  In
+   order to provide for support of EAP within RADIUS, two new
+   attributes, EAP-Message and Message-Authenticator, are introduced in
+   this document. This section describes how these new attributes may be
+   used for providing EAP support within RADIUS.
+
+   In the proposed scheme, the RADIUS server is used to shuttle RADIUS-
+   encapsulated EAP Packets between the NAS and a backend security
+   server. While the conversation between the RADIUS server and the
+   backend security server will typically occur using a proprietary
+   protocol developed by the backend security server vendor, it is also
+   possible to use RADIUS-encapsulated EAP via the EAP-Message
+   attribute.  This has the advantage of allowing the RADIUS server to
+   support EAP without the need for authentication-specific code, which
+   can instead reside on the backend security server.
+
+2.3.1.  Protocol Overview
+
+   The EAP conversation between the authenticating peer (dial-in user)
+   and the NAS begins with the negotiation of EAP within LCP.  Once EAP
+   has been negotiated, the NAS MUST send an EAP-Request/Identity
+   message to the authenticating peer, unless identity is determined via
+   some other means such as Called-Station-Id or Calling-Station-Id.
+   The peer will then respond with an EAP-Response/Identity which the
+   the NAS will then forward to the RADIUS server in the EAP-Message
+   attribute of a RADIUS Access-Request packet. The RADIUS Server will
+   typically use the EAP-Response/Identity to determine which EAP type
+   is to be applied to the user.
+
+
+
+
+Rigney, et al.               Informational                     [Page 11]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   In order to permit non-EAP aware RADIUS proxies to forward the
+   Access-Request packet, if the NAS sends the EAP-Request/Identity, the
+   NAS MUST copy the contents of the EAP-Response/Identity into the
+   User-Name attribute and MUST include the EAP-Response/Identity in the
+   User-Name attribute in every subsequent Access-Request. NAS-Port or
+   NAS-Port-Id SHOULD be included in the attributes issued by the NAS in
+   the Access-Request packet, and either NAS-Identifier or NAS-IP-
+   Address MUST be included.  In order to permit forwarding of the
+   Access-Reply by EAP-unaware proxies, if a User-Name attribute was
+   included in an Access-Request, the RADIUS Server MUST include the
+   User-Name attribute in subsequent Access-Accept packets. Without the
+   User-Name attribute, accounting and billing becomes very difficult to
+   manage.
+
+   If identity is determined via another means such as Called-Station-Id
+   or Calling-Station-Id, the NAS MUST include these identifying
+   attributes in every Access-Request.
+
+   While this approach will save a round-trip, it cannot be universally
+   employed.  There are circumstances in which the user's identity may
+   not be needed (such as when authentication and accounting is handled
+   based on Called-Station-Id or Calling-Station-Id), and therefore an
+   EAP-Request/Identity packet may not necessarily be issued by the NAS
+   to the authenticating peer. In cases where an EAP-Request/Identity
+   packet will not be sent, the NAS will send to the RADIUS server a
+   RADIUS Access-Request packet containing an EAP-Message attribute
+   signifying EAP-Start. EAP-Start is indicated by sending an EAP-
+   Message attribute with a length of 2 (no data). However, it should be
+   noted that since no User-Name attribute is included in the Access-
+   Request, this approach is not compatible with RADIUS as specified in
+   [1], nor can it easily be applied in situations where proxies are
+   deployed, such as roaming or shared use networks.
+
+   If the RADIUS server supports EAP, it MUST respond with an Access-
+   Challenge packet containing an EAP-Message attribute. If the RADIUS
+   server does not support EAP, it MUST respond with an Access-Reject.
+   The EAP-Message attribute includes an encapsulated EAP packet which
+   is then passed on to the authenticating peer.  In the case where the
+   NAS does not initially send an EAP-Request/Identity message to the
+   peer, the Access-Challenge typically will contain an EAP-Message
+   attribute encapsulating an EAP-Request/Identity message, requesting
+   the dial-in user to identify themself. The NAS will then respond with
+   a RADIUS Access-Request packet containing an EAP-Message attribute
+   encapsulating an EAP-Response.  The conversation continues until
+   either a RADIUS Access-Reject or Access-Accept packet is received.
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 12]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   Reception of a RADIUS Access-Reject packet, with or without an EAP-
+   Message attribute encapsulating EAP-Failure, MUST result in the NAS
+   issuing an LCP Terminate Request to the authenticating peer.  A
+   RADIUS Access-Accept packet with an EAP-Message attribute
+   encapsulating EAP-Success successfully ends the authentication phase.
+   The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain
+   all of the expected attributes which are currently returned in an
+   Access-Accept packet.
+
+   The above scenario creates a situation in which the NAS never needs
+   to manipulate an EAP packet.  An alternative may be used in
+   situations where an EAP-Request/Identity message will always be sent
+   by the NAS to the authenticating peer.
+
+   For proxied RADIUS requests there are two methods of processing.  If
+   the domain is determined based on the Called-Station-Id, the RADIUS
+   Server may proxy the initial RADIUS Access-Request/EAP-Start. If the
+   domain is determined based on the user's identity, the local RADIUS
+   Server MUST respond with a RADIUS Access-Challenge/EAP-Identity
+   packet.  The response from the authenticating peer MUST be proxied to
+   the final authentication server.
+
+   For proxied RADIUS requests, the NAS may receive an Access-Reject
+   packet in response to its Access-Request/EAP-Identity packet.  This
+   would occur if the message was proxied to a RADIUS Server which does
+   not support the EAP-Message extension. On receiving an Access-Reject,
+   the NAS MUST send an LCP Terminate Request to the authenticating
+   peer, and disconnect.
+
+2.3.2.  Retransmission
+
+   As noted in [3], the EAP authenticator (NAS) is responsible for
+   retransmission of packets between the authenticating peer and the
+   NAS.  Thus if an EAP packet is lost in transit between the
+   authenticating peer and the NAS (or vice versa), the NAS will
+   retransmit. As in RADIUS [1], the RADIUS client is responsible for
+   retransmission of packets between the RADIUS client and the RADIUS
+   server.
+
+   Note that it may be necessary to adjust retransmission strategies and
+   authentication timeouts in certain cases. For example, when a token
+   card is used additional time may be required to allow the user to
+   find the card and enter the token. Since the NAS will typically not
+   have knowledge of the required parameters, these need to be provided
+   by the RADIUS server. This can be accomplished by inclusion of
+   Session-Timeout and Password-Retry attributes within the Access-
+   Challenge packet.
+
+
+
+
+Rigney, et al.               Informational                     [Page 13]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   If Session-Timeout is present in an Access-Challenge packet that also
+   contains an EAP-Message, the value of the Session-Timeout provides
+   the NAS with the maximum number of seconds the NAS should wait for an
+   EAP-Response before retransmitting the EAP-Message to the dial-in
+   user.
+
+2.3.3.  Fragmentation
+
+   Using the EAP-Message attribute, it is possible for the RADIUS server
+   to encapsulate an EAP packet that is larger than the MTU on the link
+   between the NAS and the peer. Since it is not possible for the RADIUS
+   server to use MTU discovery to ascertain the link MTU, the Framed-MTU
+   attribute may be included in an Access-Request packet containing an
+   EAP-Message attribute so as to provide the RADIUS server with this
+   information.
+
+2.3.4.  Examples
+
+   The example below shows the conversation between the authenticating
+   peer, NAS, and RADIUS server, for the case of a One Time Password
+   (OTP) authentication. OTP is used only for illustrative purposes;
+   other authentication protocols could also have been used, although
+   they might show somewhat different behavior.
+
+Authenticating Peer     NAS                    RADIUS Server
+-------------------     ---                    -------------
+
+                        <- PPP LCP Request-EAP
+                        auth
+PPP LCP ACK-EAP
+auth ->
+                        <- PPP EAP-Request/
+                        Identity
+PPP EAP-Response/
+Identity (MyID) ->
+                        RADIUS
+                        Access-Request/
+                        EAP-Message/
+                        EAP-Response/
+                        (MyID) ->
+                                                <- RADIUS
+                                                Access-Challenge/
+                                                EAP-Message/EAP-Request
+                                                OTP/OTP Challenge
+                        <- PPP EAP-Request/
+                        OTP/OTP Challenge
+PPP EAP-Response/
+OTP, OTPpw ->
+
+
+
+Rigney, et al.               Informational                     [Page 14]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+                        RADIUS
+                        Access-Request/
+                        EAP-Message/
+                        EAP-Response/
+                        OTP, OTPpw ->
+                                                 <- RADIUS
+                                                 Access-Accept/
+                                                 EAP-Message/EAP-Success
+                                                 (other attributes)
+                        <- PPP EAP-Success
+PPP Authentication
+Phase complete,
+NCP Phase starts
+
+In the case where the NAS first sends an EAP-Start packet to the
+RADIUS server,  the conversation would appear as follows:
+
+Authenticating Peer     NAS                    RADIUS Server
+-------------------     ---                    -------------
+
+                        <- PPP LCP Request-EAP
+                        auth
+PPP LCP ACK-EAP
+auth ->
+                        RADIUS
+                        Access-Request/
+                       EAP-Message/Start ->
+                                               <- RADIUS
+                                               Access-Challenge/
+                                               EAP-Message/Identity
+                        <- PPP EA-Request/
+                        Identity
+PPP EAP-Response/
+Identity (MyID) ->
+                        RADIUS
+                        Access-Request/
+                        EAP-Message/
+                        EAP-Response/
+                        (MyID) ->
+                                                <- RADIUS
+                                                Access-Challenge/
+                                                EAP-Message/EAP-Request
+                                                OTP/OTP Challenge
+                        <- PPP EAP-Request/
+                        OTP/OTP Challenge
+PPP EAP-Response/
+OTP, OTPpw ->
+
+
+
+
+Rigney, et al.               Informational                     [Page 15]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+                        RADIUS
+                        Access-Request/
+                        EAP-Message/
+                        EAP-Response/
+                        OTP, OTPpw ->
+                                                 <- RADIUS
+                                                 Access-Accept/
+                                                 EAP-Message/EAP-Success
+                                                 (other attributes)
+                        <- PPP EAP-Success
+PPP Authentication
+Phase complete,
+NCP Phase starts
+
+In the case where the client fails EAP authentication, the
+conversation would appear as follows:
+
+Authenticating Peer     NAS                    RADIUS Server
+-------------------     ---                    -------------
+
+                        <- PPP LCP Request-EAP
+                        auth
+PPP LCP ACK-EAP
+auth ->
+                        Access-Request/
+                        EAP-Message/Start ->
+                                               <- RADIUS
+                                               Access-Challenge/
+                                               EAP-Message/Identity
+                        <- PPP EAP-Request/
+                        Identity
+PPP EAP-Response/
+Identity (MyID) ->
+                        RADIUS
+                        Access-Request/
+                        EAP-Message/
+                        EAP-Response/
+                        (MyID) ->
+                                                <- RADIUS
+                                                Access-Challenge/
+                                                EAP-Message/EAP-Request
+                                                OTP/OTP Challenge
+                        <- PPP EAP-Request/
+                        OTP/OTP Challenge
+PPP EAP-Response/
+OTP, OTPpw ->
+                        RADIUS
+                        Access-Request/
+
+
+
+Rigney, et al.               Informational                     [Page 16]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+                        EAP-Message/
+                        EAP-Response/
+                        OTP, OTPpw ->
+                                                 <- RADIUS
+                                                 Access-Reject/
+                                                 EAP-Message/EAP-Failure
+
+                        <- PPP EAP-Failure
+                        (client disconnected)
+
+In the case that the RADIUS server or proxy does not support
+EAP-Message, the conversation would appear as follows:
+
+Authenticating Peer     NAS                       RADIUS Server
+-------------------     ---                       -------------
+
+                        <- PPP LCP Request-EAP
+                        auth
+PPP LCP ACK-EAP
+auth ->
+                        RADIUS
+                        Access-Request/
+                        EAP-Message/Start ->
+                                                  <- RADIUS
+                                                  Access-Reject
+                        <- PPP LCP Terminate
+                        (User Disconnected)
+
+In the case where the local RADIUS Server does support EAP-Message,
+but the remote RADIUS Server does not, the conversation would appear
+as follows:
+
+Authenticating Peer     NAS                       RADIUS Server
+-------------------     ---                       -------------
+
+                        <- PPP LCP Request-EAP
+                        auth
+PPP LCP ACK-EAP
+auth ->
+                        RADIUS
+                        Access-Request/
+                        EAP-Message/Start ->
+                                                  <- RADIUS
+                                                  Access-Challenge/
+                                                  EAP-Message/Identity
+                        <- PPP EAP-Request/
+                        Identity
+
+
+
+
+Rigney, et al.               Informational                     [Page 17]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+PPP EAP-Response/
+Identity
+(MyID) ->
+                        RADIUS
+                        Access-Request/
+                        EAP-Message/EAP-Response/
+                        (MyID) ->
+                                                  <- RADIUS
+                                                  Access-Reject
+                                                  (proxied from remote
+                                                   RADIUS Server)
+                        <- PPP LCP Terminate
+                        (User Disconnected)
+
+In the case where the authenticating peer does not support EAP, but
+where EAP is required for that user, the conversation would appear as
+follows:
+
+Authenticating Peer     NAS                       RADIUS Server
+-------------------     ---                       -------------
+
+                        <- PPP LCP Request-EAP
+                        auth
+PPP LCP NAK-EAP
+auth ->
+                        <- PPP LCP Request-CHAP
+                        auth
+PPP LCP ACK-CHAP
+auth ->
+                        <- PPP CHAP Challenge
+PPP CHAP Response ->
+                        RADIUS
+                        Access-Request/
+                        User-Name,
+                        CHAP-Password ->
+                                                  <- RADIUS
+                                                  Access-Reject
+                        <-  PPP LCP Terminate
+                        (User Disconnected)
+
+In the case where the NAS does not support EAP, but where EAP is
+required for that user, the conversation would appear as follows:
+
+Authenticating Peer     NAS                       RADIUS Server
+-------------------     ---                       -------------
+
+                        <- PPP LCP Request-CHAP
+                        auth
+
+
+
+Rigney, et al.               Informational                     [Page 18]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+PP LCP ACK-CHAP
+auth ->
+                        <- PPP CHAP Challenge
+PPP CHAP Response ->
+                        RADIUS
+                        Access-Request/
+                        User-Name,
+                        CHAP-Password ->
+
+                                                 <- RADIUS
+                                                 Access-Reject
+                        <-  PPP LCP Terminate
+                        (User Disconnected)
+
+2.3.5.  Alternative uses
+
+   Currently the conversation between the backend security server and
+   the RADIUS server is proprietary because of lack of standardization.
+   In order to increase standardization and provide interoperability
+   between Radius vendors and backend security vendors, it is
+   recommended that RADIUS-encapsulated EAP be used for this
+   conversation.
+
+   This has the advantage of allowing the RADIUS server to support EAP
+   without the need for authentication-specific  code within the RADIUS
+   server. Authentication-specific code can then reside on a backend
+   security server instead.
+
+   In the case where RADIUS-encapsulated EAP is used in a conversation
+   between a RADIUS server and a backend security server, the security
+   server will typically return an Access-Accept/EAP-Success message
+   without inclusion of the expected attributes currently returned in an
+   Access-Accept. This means that the RADIUS server MUST add these
+   attributes prior to sending an Access-Accept/EAP-Success message to
+   the NAS.
+
+3.  Packet Format
+
+   Packet Format is identical to that defined in RFC 2865 [1] and 2866
+   [2].
+
+4.  Packet Types
+
+   Packet types are identical to those defined in RFC 2865 [1] and 2866
+   [2].
+
+   See "Table of Attributes" below to determine which types of packets
+   can contain which attributes defined here.
+
+
+
+Rigney, et al.               Informational                     [Page 19]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+5.  Attributes
+
+   RADIUS Attributes carry the specific authentication, authorization
+   and accounting details for the request and response.
+
+   Some attributes MAY be included more than once.  The effect of this
+   is attribute specific, and is specified in each attribute
+   description.  The order of attributes of the same type SHOULD be
+   preserved.  The order of attributes of different types is not
+   required to be preserved.
+
+   The end of the list of attributes is indicated by the Length of the
+   RADIUS packet.
+
+   A summary of the attribute format is the same as in RFC 2865 [1] but
+   is included here for ease of reference.  The fields are transmitted
+   from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |  Value ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   Type
+
+      The Type field is one octet.  Up-to-date values of the RADIUS Type
+      field are specified in the most recent "Assigned Numbers" RFC [5].
+      Values 192-223 are reserved for experimental use, values 224-240
+      are reserved for implementation-specific use, and values 241-255
+      are reserved and should not be used.  This specification concerns
+      the following values:
+
+           1-39   (refer to RFC 2865 [1], "RADIUS")
+          40-51   (refer to RFC 2866 [2], "RADIUS Accounting")
+          52      Acct-Input-Gigawords
+          53      Acct-Output-Gigawords
+          54      Unused
+          55      Event-Timestamp
+          56-59   Unused
+          60-63   (refer to RFC 2865 [1], "RADIUS")
+          64-67   (refer to [6])
+          68      (refer to [7])
+          69      (refer to [6])
+          70      ARAP-Password
+          71      ARAP-Features
+          72      ARAP-Zone-Access
+
+
+
+Rigney, et al.               Informational                     [Page 20]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+          73      ARAP-Security
+          74      ARAP-Security-Data
+          75      Password-Retry
+          76      Prompt
+          77      Connect-Info
+          78      Configuration-Token
+          79      EAP-Message
+          80      Message-Authenticator
+          81-83   (refer to [6])
+          84      ARAP-Challenge-Response
+          85      Acct-Interim-Interval
+          86      (refer to [7])
+          87      NAS-Port-Id
+          88      Framed-Pool
+          89      Unused
+          90-91   (refer to [6])
+          92-191  Unused
+
+   Length
+
+      The Length field is one octet, and indicates the length of this
+      attribute including the Type, Length and Value fields.  If an
+      attribute is received in a packet with an invalid Length, the
+      entire request should be silently discarded.
+
+   Value
+
+      The Value field is zero or more octets and contains information
+      specific to the attribute.  The format and length of the Value
+      field is determined by the Type and Length fields.
+
+      Note that none of the types in RADIUS terminate with a NUL (hex
+      00).  In particular, types "text" and "string" in RADIUS do not
+      terminate with a NUL (hex 00).  The Attribute has a length field
+      and does not use a terminator.  Text contains UTF-8 encoded 10646
+      [8] characters and String contains 8-bit binary data.  Servers and
+      servers and clients MUST be able to deal with embedded nulls.
+      RADIUS implementers using C are cautioned not to use strcpy() when
+      handling strings.
+
+      The format of the value field is one of five data types.  Note
+      that type "text" is a subset of type "string."
+
+      text      1-253 octets containing UTF-8 encoded 10646 [8]
+                characters. Text of length zero (0) MUST NOT be sent;
+                omit the entire attribute instead.
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 21]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+      string    1-253 octets containing binary data (values 0 through
+                255 decimal, inclusive). Strings of length zero (0) MUST
+                NOT be sent; omit the entire attribute instead.
+
+      address   32 bit unsigned value, most significant octet first.
+
+      integer   32 bit unsigned value, most significant octet first.
+
+      time      32 bit unsigned value, most significant octet first --
+                   seconds since 00:00:00 UTC, January 1, 1970.
+
+5.1.  Acct-Input-Gigawords
+
+   Description
+
+      This attribute indicates how many times the Acct-Input-Octets
+      counter has wrapped around 2^32 over the course of this service
+      being provided, and can only be present in Accounting-Request
+      records where the Acct-Status-Type is set to Stop or Interim-
+      Update.
+
+   A summary of the Acct-Input-Gigawords attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      52 for Acct-Input-Gigawords.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 22]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+5.2.  Acct-Output-Gigawords
+
+   Description
+
+      This attribute indicates how many times the Acct-Output-Octets
+      counter has wrapped around 2^32 in the course of delivering this
+      service, and can only be present in Accounting-Request records
+      where the Acct-Status-Type is set to Stop or Interim-Update.
+
+   A summary of the Acct-Output-Gigawords attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      53 for Acct-Output-Gigawords.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+5.3.  Event-Timestamp
+
+   Description
+
+      This attribute is included in an Accounting-Request packet to
+      record the time that this event occurred on the NAS, in seconds
+      since January 1, 1970 00:00 UTC.
+
+   A summary of the Event-Timestamp attribute format is shown below.
+   The fields are transmitted from left to right.
+
+
+
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 23]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      55 for Event-Timestamp
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets encoding an unsigned integer with
+      the number of seconds since January 1, 1970 00:00 UTC.
+
+5.4.  ARAP-Password
+
+   Description
+
+      This attribute is only present in an Access-Request packet
+      containing a Framed-Protocol of ARAP.
+
+      Only one of User-Password, CHAP-Password, or ARAP-Password needs
+      to be present in an Access-Request, or one or more EAP-Messages.
+
+   A summary of the ARAP-Password attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                   |             Value2
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                   |             Value3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                   |             Value4
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Rigney, et al.               Informational                     [Page 24]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   Type
+
+      70 for ARAP-Password.
+
+   Length
+
+      18
+
+   Value
+
+      This attribute contains a 16 octet string, used to carry the
+      dial-in user's response to the NAS challenge and the client's own
+      challenge to the NAS.  The high-order octets (Value1 and Value2)
+      contain the dial-in user's challenge to the NAS (2 32-bit numbers,
+      8 octets) and the low-order octets (Value3 and Value4) contain the
+      dial-in user's response to the NAS challenge (2 32-bit numbers, 8
+      octets).
+
+5.5.  ARAP-Features
+
+   Description
+
+      This attribute is sent in an Access-Accept packet with Framed-
+      Protocol of ARAP, and includes password information that the NAS
+      should sent to the user in an ARAP "feature flags" packet.
+
+   A summary of the ARAP-Features attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     Value1    |    Value2     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Value3                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Value4                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           Value5                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      71 for ARAP-Features.
+
+   Length
+
+      16
+
+
+
+Rigney, et al.               Informational                     [Page 25]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   Value
+
+      The Value field is a compound string containing information the
+      NAS should send to the user in the ARAP "feature flags" packet.
+
+         Value1: If zero, user cannot change their password. If non-zero
+         user can.  (RADIUS does not handle the password changing, just
+         the attribute which indicates whether ARAP indicates they can.)
+
+         Value2: Minimum acceptable password length, from 0 to 8.
+
+         Value3: Password creation date in Macintosh format, defined as
+         32 unsigned bits representing seconds since Midnight GMT
+         January 1, 1904.
+
+         Value4: Password Expiration Delta from create date in seconds.
+
+         Value5: Current RADIUS time in Macintosh format.
+
+5.6.  ARAP-Zone-Access
+
+   Description
+
+      This attribute is included in an Access-Accept packet with
+      Framed-Protocol of ARAP to indicate how the ARAP zone list for the
+      user should be used.
+
+   A summary of the ARAP-Zone-Access attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   Type
+
+      72 for ARAP-Zone-Access.
+
+   Length
+
+      6
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 26]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   Value
+
+      The Value field is four octets encoding an integer with one of the
+      following values:
+
+      1      Only allow access to default zone
+      2      Use zone filter inclusively
+      4      Use zone filter exclusively
+
+
+      The value 3 is skipped, not because these are bit flags, but
+      because 3 in some ARAP implementations means "all zones" which is
+      the same as not specifying a list at all under RADIUS.
+
+      If this attribute is present and the value is 2 or 4 then a
+      Filter-Id must also be present to name a zone list filter to apply
+      the access flag to.
+
+5.7.  ARAP-Security
+
+   Description
+
+      This attribute identifies the ARAP Security Module to be used in
+      an Access-Challenge packet.
+
+   A summary of the ARAP-Security attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      73 for ARAP-Security.
+
+   Length
+
+      6
+
+
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 27]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   Value
+
+      The Value field is four octets, containing an integer specifying
+      the security module signature, which is a Macintosh OSType.
+      (Macintosh OSTypes are 4 ascii characters cast as a 32-bit
+      integer)
+
+5.8.  ARAP-Security-Data
+
+   Description
+
+      This attribute contains the actual security module challenge or
+      response, and can be found in Access-Challenge and Access-Request
+      packets.
+
+   A summary of the ARAP-Security-Data attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      74 for ARAP-Security-Data.
+
+   Length
+
+      >=3
+
+   String
+
+      The String field contains the security module challenge or
+      response associated with the ARAP Security Module specified in
+      ARAP-Security.
+
+5.9.  Password-Retry
+
+   Description
+
+      This attribute MAY be included in an Access-Reject to indicate how
+      many authentication attempts a user may be allowed to attempt
+      before being disconnected.
+
+      It is primarily intended for use with ARAP authentication.
+
+
+
+
+Rigney, et al.               Informational                     [Page 28]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   A summary of the Password-Retry attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      75 for Password-Retry.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets, containing an integer specifying
+      the number of password retry attempts to permit the user.
+
+5.10.  Prompt
+
+   Description
+
+      This attribute is used only in Access-Challenge packets, and
+      indicates to the NAS whether it should echo the user's response as
+      it is entered, or not echo it.
+
+
+   A summary of the Prompt attribute format is shown below.  The fields
+   are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      76 for Prompt.
+
+
+
+
+Rigney, et al.               Informational                     [Page 29]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets.
+
+       0      No Echo
+       1      Echo
+
+5.11.  Connect-Info
+
+   Description
+
+      This attribute is sent from the NAS to indicate the nature of the
+      user's connection.
+
+      The NAS MAY send this attribute in an Access-Request or
+      Accounting-Request to indicate the nature of the user's
+      connection.
+
+   A summary of the Connect-Info attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     Text...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      77 for Connect-Info.
+
+   Length
+
+      >= 3
+
+   Text
+
+      The Text field consists of UTF-8 encoded 10646 [8] characters.
+      The connection speed SHOULD be included at the beginning of the
+      first Connect-Info attribute in the packet.  If the transmit and
+      receive connection speeds differ, they may both be included in the
+      first attribute with the transmit speed first (the speed the NAS
+      modem transmits at), a slash (/), the receive speed, then
+      optionally other information.
+
+
+
+Rigney, et al.               Informational                     [Page 30]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+      For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
+
+      More than one Connect-Info attribute may be present in an
+      Accounting-Request packet to accommodate expected efforts by ITU
+      to have modems report more connection information in a standard
+      format that might exceed 252 octets.
+
+5.12.  Configuration-Token
+
+   Description
+
+      This attribute is for use in large distributed authentication
+      networks based on proxy.  It is sent from a RADIUS Proxy Server to
+      a RADIUS Proxy Client in an Access-Accept to indicate a type of
+      user profile to be used.  It should not be sent to a NAS.
+
+   A summary of the Configuration-Token attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |  String ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      78 for Configuration-Token.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field is one or more octets.  The actual format of the
+      information is site or application specific, and a robust
+      implementation SHOULD support the field as undistinguished octets.
+
+      The codification of the range of allowed usage of this field is
+      outside the scope of this specification.
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 31]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+5.13.  EAP-Message
+
+   Description
+
+      This attribute encapsulates Extended Access Protocol [3] packets
+      so as to allow the NAS to authenticate dial-in users via EAP
+      without having to understand the EAP protocol.
+
+      The NAS places any EAP messages received from the user into one or
+      more EAP attributes and forwards them to the RADIUS Server as part
+      of the Access-Request, which can return EAP messages in Access-
+      Challenge, Access-Accept and Access-Reject packets.
+
+      A RADIUS Server receiving EAP messages that it does not understand
+      SHOULD return an Access-Reject.
+
+      The NAS places EAP messages received from the authenticating peer
+      into one or more EAP-Message attributes and forwards them to the
+      RADIUS Server within an Access-Request message.  If multiple EAP-
+      Messages are contained within an Access-Request or Access-
+      Challenge packet, they MUST be in order and they MUST be
+      consecutive attributes in the Access-Request or Access-Challenge
+      packet.  Access-Accept and Access-Reject packets SHOULD only have
+      ONE EAP-Message attribute in them, containing EAP-Success or EAP-
+      Failure.
+
+      It is expected that EAP will be used to implement a variety of
+      authentication methods, including methods involving strong
+      cryptography. In order to prevent attackers from subverting EAP by
+      attacking RADIUS/EAP, (for example, by modifying the EAP-Success
+      or EAP-Failure packets) it is necessary that RADIUS/EAP provide
+      integrity protection at least as strong as those used in the EAP
+      methods themselves.
+
+      Therefore the Message-Authenticator attribute MUST be used to
+      protect all Access-Request, Access-Challenge, Access-Accept, and
+      Access-Reject packets containing an EAP-Message attribute.
+
+      Access-Request packets including an EAP-Message attribute without
+      a Message-Authenticator attribute SHOULD be silently discarded by
+      the RADIUS server.  A RADIUS Server supporting EAP-Message MUST
+      calculate the correct value of the Message-Authenticator and
+      silently discard the packet if it does not match the value sent.
+      A RADIUS Server not supporting EAP-Message MUST return an Access-
+      Reject if it receives an Access-Request containing an EAP-Message
+      attribute. A RADIUS Server receiving an EAP-Message attribute that
+      it does not understand MUST return an Access-Reject.
+
+
+
+
+Rigney, et al.               Informational                     [Page 32]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+      Access-Challenge, Access-Accept, or Access-Reject packets
+      including an EAP-Message attribute without a Message-Authenticator
+      attribute SHOULD be silently discarded by the NAS. A NAS
+      supporting EAP-Message MUST calculate the correct value of the
+      Message-Authenticator and silently discard the packet if it does
+      not match the value sent.
+
+   A summary of the EAP-Message attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      79 for EAP-Message.
+
+   Length
+
+      >= 3
+
+   String
+
+      The String field contains EAP packets, as defined in [3].  If
+      multiple EAP-Message attributes are present in a packet their
+      values should be concatenated; this allows EAP packets longer than
+      253 octets to be passed by RADIUS.
+
+5.14.  Message-Authenticator
+
+   Description
+
+      This attribute MAY be used to sign Access-Requests to prevent
+      spoofing Access-Requests using CHAP, ARAP or EAP authentication
+      methods.  It MAY be used in any Access-Request.  It MUST be used
+      in any Access-Request, Access-Accept, Access-Reject or Access-
+      Challenge that includes an EAP-Message attribute.
+
+      A RADIUS Server receiving an Access-Request with a Message-
+      Authenticator Attribute present MUST calculate the correct value
+      of the Message-Authenticator and silently discard the packet if it
+      does not match the value sent.
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 33]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+      A RADIUS Client receiving an Access-Accept, Access-Reject or
+      Access-Challenge with a Message-Authenticator Attribute present
+      MUST calculate the correct value of the Message-Authenticator and
+      silently discard the packet if it does not match the value sent.
+
+      Earlier drafts of this memo used "Signature" as the name of this
+      attribute, but Message-Authenticator is more precise.  Its
+      operation has not changed, just the name.
+
+   A summary of the Message-Authenticator attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      80 for Message-Authenticator
+
+   Length
+
+      18
+
+   String
+
+      When present in an Access-Request packet, Message-Authenticator is
+      an HMAC-MD5 [9] checksum of the entire Access-Request packet,
+      including Type, ID, Length and authenticator, using the shared
+      secret as the key, as follows.
+
+      Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
+      Request Authenticator, Attributes)
+
+      When the checksum is calculated the signature string should be
+      considered to be sixteen octets of zero.
+
+      For Access-Challenge, Access-Accept, and Access-Reject packets,
+      the Message-Authenticator is calculated as follows, using the
+      Request-Authenticator from the Access-Request this packet is in
+      reply to:
+
+      Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
+      Request Authenticator, Attributes)
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 34]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+      When the checksum is calculated the signature string should be
+      considered to be sixteen octets of zero.  The shared secret is
+      used as the key for the HMAC-MD5 hash.  The is calculated and
+      inserted in the packet before the Response Authenticator is
+      calculated.
+
+      This attribute is not needed if the User-Password attribute is
+      present, but is useful for preventing attacks on other types of
+      authentication.  This attribute is intended to thwart attempts by
+      an attacker to setup a "rogue" NAS, and perform online dictionary
+      attacks against the RADIUS server.  It does not afford protection
+      against "offline" attacks where the attacker intercepts packets
+      containing (for example) CHAP challenge and response, and performs
+      a dictionary attack against those packets offline.
+
+      IP Security will eventually make this attribute unnecessary, so it
+      should be considered an interim measure.
+
+5.15.  ARAP-Challenge-Response
+
+   Description
+
+      This attribute is sent in an Access-Accept packet with Framed-
+      Protocol of ARAP, and contains the response to the dial-in
+      client's challenge.
+
+   A summary of the ARAP-Challenge-Response attribute format is shown
+   below.  The fields are transmitted from left to right.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     Value...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      84 for ARAP-Challenge-Response.
+
+   Length
+
+      10
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 35]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   Value
+
+      The Value field contains an 8 octet response to the dial-in
+      client's challenge. The RADIUS server calculates this value by
+      taking the dial-in client's challenge from the high order 8 octets
+      of the ARAP-Password attribute and  performing DES encryption on
+      this value with the authenticating user's password as the key. If
+      the user's password is less than 8 octets in length, the password
+      is padded at the end with NULL octets to a length of 8 before
+      using it as a key.
+
+5.16.  Acct-Interim-Interval
+
+   Description
+
+      This attribute indicates the number of seconds between each
+      interim update in seconds  for this specific session. This value
+      can only appear in the Access-Accept message.
+
+   A summary of the Acct-Interim-Interval attribute  format  is  shown
+   below. The fields are transmitted from left to right.
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |             Value
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Value (cont)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      85 for Acct-Interim-Interval.
+
+   Length
+
+      6
+
+   Value
+
+      The Value field contains the number of seconds between each
+      interim update to be sent from the NAS for this session. The value
+      MUST NOT be smaller than 60.  The value SHOULD NOT be smaller than
+      600, and careful consideration should be given to its impact on
+      network traffic.
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 36]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+5.17.  NAS-Port-Id
+
+   Description
+
+      This Attribute contains a text string which identifies the port of
+      the NAS which is authenticating the user.  It is only used in
+      Access-Request and Accounting-Request packets.  Note that this is
+      using "port" in its sense of a physical connection on the NAS, not
+      in the sense of a TCP or UDP port number.
+
+      Either NAS-Port or NAS-Port-Id SHOULD be present in an Access-
+      Request packet, if the NAS differentiates among its ports.  NAS-
+      Port-Id is intended for use by NASes which cannot conveniently
+      number their ports.
+
+   A summary of the NAS-Port-Id Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     Text...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   Type
+
+      87 for NAS-Port-Id.
+
+   Length
+
+      >= 3
+
+   Text
+
+      The Text field contains the name of the port using UTF-8 encoded
+      10646 [8] characters.
+
+5.18.  Framed-Pool
+
+   Description
+
+      This Attribute contains the name of an assigned address pool that
+      SHOULD be used to assign an address for the user.  If a NAS does
+      not support multiple address pools, the NAS should ignore this
+      Attribute.  Address pools are usually used for IP addresses, but
+      can be used for other protocols if the NAS supports pools for
+      those protocols.
+
+
+
+Rigney, et al.               Informational                     [Page 37]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   A summary of the Framed-Pool Attribute format is shown below.  The
+   fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      88 for Framed-Pool
+
+   Length
+
+      >= 3
+
+   String
+
+      The string field contains the name of an assigned address pool
+      configured on the NAS.
+
+5.19.  Table of Attributes
+
+   The following table provides a guide to which attributes may be found
+   in which kind of packets.  Acct-Input-Gigawords, Acct-Output-
+   Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in
+   an Accounting-Request packet.  Connect-Info may have 0+ instances in
+   an Accounting-Request packet.  The other attributes added in this
+   document must not be present in an Accounting-Request.
+
+Request  Accept  Reject  Challenge   #    Attribute
+0-1      0       0       0           70   ARAP-Password [Note 1]
+0        0-1     0       0-1         71   ARAP-Features
+0        0-1     0       0           72   ARAP-Zone-Access
+0-1      0       0       0-1         73   ARAP-Security
+0+       0       0       0+          74   ARAP-Security-Data
+0        0       0-1     0           75   Password-Retry
+0        0       0       0-1         76   Prompt
+0-1      0       0       0           77   Connect-Info
+0        0+      0       0           78   Configuration-Token
+0+       0+      0+      0+          79   EAP-Message [Note 1]
+0-1      0-1     0-1     0-1         80   Message-Authenticator [Note 1]
+0        0-1     0       0-1         84   ARAP-Challenge-Response
+0        0-1     0       0           85   Acct-Interim-Interval
+0-1      0       0       0           87   NAS-Port-Id
+0        0-1     0       0           88   Framed-Pool
+Request  Accept  Reject  Challenge   #    Attribute
+
+
+
+Rigney, et al.               Informational                     [Page 38]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   [Note 1] An Access-Request that contains either a User-Password or
+   CHAP-Password or ARAP-Password or one or more EAP-Message attributes
+   MUST NOT contain more than one type of those four attributes.  If it
+   does not contain any of those four attributes, it SHOULD contain a
+   Message-Authenticator.  If any packet type contains an EAP-Message
+   attribute it MUST also contain a Message-Authenticator.
+
+   The following table defines the above table entries.
+
+      0     This attribute MUST NOT be present
+      0+    Zero or more instances of this attribute MAY be present.
+      0-1   Zero or one instance of this attribute MAY be present.
+      1     Exactly one instance of this attribute MUST be present.
+
+6.  IANA Considerations
+
+   The Packet Type Codes, Attribute Types, and Attribute Values defined
+   in this document are registered by the Internet Assigned Numbers
+   Authority (IANA) from the RADIUS name spaces as described in the
+   "IANA Considerations" section of [1], in accordance with BCP 26 [10].
+
+7.  Security Considerations
+
+   The attributes other than Message-Authenticator and EAP-Message in
+   this document have no additional security considerations beyond those
+   already identified in [1].
+
+7.1.  Message-Authenticator Security
+
+   Access-Request packets with a User-Password establish the identity of
+   both the user and the NAS sending the Access-Request, because of the
+   way the shared secret between NAS and RADIUS server is used.
+   Access-Request packets with CHAP-Password or EAP-Message do not have
+   a User-Password attribute, so the Message-Authenticator attribute
+   should be used in access-request packets that do not have a User-
+   Password, in order to establish the identity of the NAS sending the
+   request.
+
+7.2.  EAP Security
+
+   Since the purpose of EAP is to provide enhanced security for PPP
+   authentication, it is critical that RADIUS support for EAP be secure.
+   In particular, the following issues must be addressed:
+
+      Separation of EAP server and PPP authenticator
+      Connection hijacking
+      Man in the middle attacks
+      Multiple databases
+
+
+
+Rigney, et al.               Informational                     [Page 39]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+      Negotiation attacks
+
+7.2.1.  Separation of EAP server and PPP authenticator
+
+   It is possible for the EAP endpoints to mutually authenticate,
+   negotiate a ciphersuite, and derive a session key for subsequent use
+   in PPP encryption.
+
+   This does not present an issue on the peer, since the peer and EAP
+   client reside on the same machine; all that is required is for the
+   EAP client module to pass the session key to the PPP encryption
+   module.
+
+   The situation is more complex when EAP is used with RADIUS, since the
+   PPP authenticator will typically not reside on the same machine as
+   the EAP server. For example, the EAP server may be a backend security
+   server, or a module residing on the RADIUS server.
+
+   In the case where the EAP server and PPP authenticator reside on
+   different machines, there are several implications for security.
+   Firstly, mutual authentication will occur between the peer and the
+   EAP server, not between the peer and the authenticator. This means
+   that it is not possible for the peer to validate the identity of the
+   NAS or tunnel server that it is speaking to.
+
+   As described earlier, when EAP/RADIUS is used to encapsulate EAP
+   packets, the Message-Authenticator attribute is required in
+   EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the
+   RADIUS server. Since the Message-Authenticator attribute involves a
+   HMAC-MD5 hash, it is possible for the RADIUS server to verify the
+   integrity of the Access-Request as well as the NAS or tunnel server's
+   identity.  Similarly, Access-Challenge packets sent from the RADIUS
+   server to the NAS are also authenticated and integrity protected
+   using an HMAC-MD5 hash, enabling the NAS or tunnel server to
+   determine the integrity of the packet and verify the identity of the
+   RADIUS server.  Moreover, EAP packets sent via methods that contain
+   their own integrity protection cannot be successfully modified by a
+   rogue NAS or tunnel server.
+
+   The second issue that arises in the case of an EAP server and PPP
+   authenticator residing on different machines is that the session key
+   negotiated between the peer and EAP server will need to be
+   transmitted to the authenticator.  Therefore a mechanism needs to be
+   provided to transmit the session key from the EAP server to the
+   authenticator or tunnel server that needs to use the key. The
+   specification of this transit mechanism is outside the scope of this
+   document.
+
+
+
+
+Rigney, et al.               Informational                     [Page 40]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+7.2.2.  Connection hijacking
+
+   In this form of attack, the attacker attempts to inject packets into
+   the conversation between the NAS and the RADIUS server, or between
+   the RADIUS server and the backend security server. RADIUS does not
+   support encryption, and as described in [1], only Access-Reply and
+   Access-Challenge packets are integrity protected. Moreover, the
+   integrity protection mechanism described in [1] is weaker than that
+   likely to be used by some EAP methods, making it possible to subvert
+   those methods by attacking EAP/RADIUS.
+
+   In order to provide for authentication of all packets in the EAP
+   exchange, all EAP/RADIUS packets MUST be authenticated using the
+   Message-Authenticator attribute, as described previously.
+
+7.2.3.  Man in the middle attacks
+
+   Since RADIUS security is based on shared secrets, end-to-end security
+   is not provided in the case where authentication or accounting
+   packets are forwarded along a proxy chain.  As a result, attackers
+   gaining control of a RADIUS proxy will be able to modify EAP packets
+   in transit.
+
+7.2.4.  Multiple databases
+
+   In many cases a backend security server will be deployed along with a
+   RADIUS server in order to provide EAP services. Unless the backend
+   security server also functions as a RADIUS server, two separate user
+   databases will exist, each containing information about the security
+   requirements for the user. This represents a weakness, since security
+   may be compromised by a successful attack on either of the servers,
+   or their backend databases. With multiple user databases, adding a
+   new user may require multiple operations, increasing the chances for
+   error.  The problems are further magnified in the case where user
+   information is also being kept in an LDAP server. In this case, three
+   stores of user information may exist.
+
+   In order to address these threats, consolidation of databases is
+   recommended.  This can be achieved by having both the RADIUS server
+   and backend security server store information in the same backend
+   database; by having the backend security server provide a full RADIUS
+   implementation; or by consolidating both the backend security server
+   and the RADIUS server onto the same machine.
+
+
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 41]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+7.2.5.  Negotiation attacks
+
+   In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or
+   RADIUS server causes the authenticating peer to choose a less secure
+   authentication method so as to make it easier to obtain the user's
+   password. For example, a session that would normally be authenticated
+   with EAP would instead authenticated via CHAP or PAP; alternatively,
+   a connection that would normally be authenticated via one EAP type
+   occurs via a less secure EAP type, such as MD5. The threat posed by
+   rogue devices, once thought to be remote, has gained currency given
+   compromises of telephone company switching systems, such as those
+   described in [11].
+
+   Protection against negotiation attacks requires the elimination of
+   downward negotiations. This can be achieved via implementation of
+   per-connection policy on the part of the authenticating peer, and
+   per-user policy on the part of the RADIUS server.
+
+   For the authenticating peer, authentication policy should be set on a
+   per-connection basis. Per-connection policy allows an authenticating
+   peer to negotiate EAP when calling one service, while negotiating
+   CHAP for another service, even if both services are accessible via
+   the same phone number.
+
+   With per-connection policy, an authenticating peer will only attempt
+   to negotiate EAP for a session in which EAP support is expected. As a
+   result, there is a presumption that an authenticating peer selecting
+   EAP requires that level of security. If it cannot be provided, it is
+   likely that there is some kind of misconfiguration, or even that the
+   authenticating peer is contacting the wrong server. Should the NAS
+   not be able to negotiate EAP, or should the EAP-Request sent by the
+   NAS be of a different EAP type than what is expected, the
+   authenticating peer MUST disconnect. An authenticating peer expecting
+   EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP.
+
+   For a NAS, it may not be possible to determine whether a user is
+   required to authenticate with EAP until the user's identity is known.
+   For example, for shared-uses NASes it is possible for one reseller to
+   implement EAP while another does not. In such cases, if any users of
+   the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for
+   every call. This avoids forcing an EAP-capable client to do more than
+   one authentication, which weakens security.
+
+   If CHAP is negotiated, the NAS will pass the User-Name and CHAP-
+   Password attributes to the RADIUS Server in an Access-Request packet.
+   If the user is not required to use EAP, then the RADIUS Server will
+   respond with an Access-Accept or Access-Reject packet as appropriate.
+   However, if CHAP has been negotiated but EAP is required, the RADIUS
+
+
+
+Rigney, et al.               Informational                     [Page 42]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   server MUST respond with an Access-Reject, rather than an Access-
+   Challenge/EAP-Message/EAP-Request packet.  The authenticating peer
+   MUST refuse to renegotiate authentication, even if the renegotiation
+   is from CHAP to EAP.
+
+   If EAP is negotiated but is not supported by the RADIUS proxy or
+   server, then the server or proxy MUST respond with an Access-Reject.
+   In these cases, the NAS MUST send an LCP-Terminate and disconnect the
+   user.  This is the correct behavior since the authenticating peer is
+   expecting EAP to be negotiated, and that expectation cannot be
+   fulfilled. An EAP-capable authenticating peer MUST refuse to
+   renegotiate the authentication protocol if EAP had initially been
+   negotiated.  Note that problems with a non-EAP capable RADIUS proxy
+   could prove difficult to diagnose, since a user dialing in from one
+   location (with an EAP-capable proxy) might be able to successfully
+   authenticate via EAP, while the same user dialing into another
+   location (and encountering an EAP-incapable proxy) might be
+   consistently disconnected.
+
+8.  References
+
+   [1]  Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
+        Authentication Dial In User Service (RADIUS)", RFC 2865, June
+        2000.
+
+   [2]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+   [3]  Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
+        Protocol (EAP)", RFC 2284, March 1998.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March, 1997.
+
+   [5]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+        October 1994.
+
+   [6]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.  and
+        I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
+        2868, June 2000.
+
+   [7]  Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
+        Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
+
+   [8]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+        2279, January 1998.
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 43]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   [9]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
+        for Message Authentication", RFC 2104, February 1997.
+
+   [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [11] Slatalla, M., and  Quittner, J., "Masters of Deception."
+        HarperCollins, New York, 1995.
+
+9.  Acknowledgements
+
+   RADIUS and RADIUS Accounting were originally developed by Livingston
+   Enterprises (now part of Lucent Technologies) for their PortMaster
+   series of Network Access Servers.
+
+   The section on ARAP is adopted with permission from "Using RADIUS to
+   Authenticate Apple Remote Access Connections" by Ward Willats of Cyno
+   Technologies (ward@cyno.com).
+
+   The section on Acct-Interim-Interval is adopted with permission from
+   an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark
+   Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies.
+
+   The section on EAP is adopted with permission from an earlier work in
+   progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit
+   Network, and Bernard Aboba of Microsoft.  Thanks also to Dave Dawson
+   and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of
+   Microsoft for useful discussions of this problem space.
+
+10.  Chair's Address
+
+   The RADIUS working group can be contacted via the current chair:
+
+   Carl Rigney
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   Phone: +1 925 737 2100
+   EMail: cdr@telemancy.com
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 44]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+11.  Authors' Addresses
+
+   Questions about this memo can also be directed to:
+
+   Carl Rigney
+   Livingston Enterprises
+   4464 Willow Road
+   Pleasanton, California  94588
+
+   EMail: cdr@telemancy.com
+
+   Questions on ARAP and RADIUS may be directed to:
+
+   Ward Willats
+   Cyno Technologies
+   1082 Glen Echo Ave
+   San Jose, CA 95125
+
+   Phone: +1 408 297 7766
+   EMail: ward@cyno.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 45]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+   Questions on EAP and RADIUS may be directed to any of the following:
+
+   Pat R. Calhoun
+   Network and Security Research Center
+   Sun Microsystems, Inc.
+   15 Network Circle
+   Menlo Park, CA 94025
+
+   Phone: +1 650 786 7733
+   EMail: pcalhoun@eng.sun.com
+
+
+   Allan C. Rubens
+   Tut Systems, Inc.
+   220 E. Huron, Suite 260
+   Ann Arbor, MI 48104
+
+   Phone: +1 734 995 1697
+   EMail: arubens@tutsys.com
+
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 936 6605
+   EMail: bernarda@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 46]
+
+RFC 2869                   RADIUS Extensions                   June 2000
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rigney, et al.               Informational                     [Page 47]
+
diff --git a/doc/rfc3580.txt b/doc/rfc3580.txt
new file mode 100644
index 0000000..b87235c
--- /dev/null
+++ b/doc/rfc3580.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group                                         P. Congdon
+Request for Comments: 3580                       Hewlett Packard Company
+Category: Informational                                         B. Aboba
+                                                               Microsoft
+                                                                A. Smith
+                                                        Trapeze Networks
+                                                                 G. Zorn
+                                                           Cisco Systems
+                                                                J. Roese
+                                                               Enterasys
+                                                          September 2003
+
+
+    IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)
+                            Usage Guidelines
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document provides suggestions on Remote Authentication Dial In
+   User Service (RADIUS) usage by IEEE 802.1X Authenticators.  The
+   material in this document is also included within a non-normative
+   Appendix within the IEEE 802.1X specification, and is being presented
+   as an IETF RFC for informational purposes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Congdon, et al.              Informational                      [Page 1]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  3
+       1.2.  Requirements Language. . . . . . . . . . . . . . . . . .  4
+   2.  RADIUS Accounting Attributes . . . . . . . . . . . . . . . . .  5
+       2.1.  Acct-Terminate-Cause . . . . . . . . . . . . . . . . . .  5
+       2.2.  Acct-Multi-Session-Id. . . . . . . . . . . . . . . . . .  6
+       2.3.  Acct-Link-Count. . . . . . . . . . . . . . . . . . . . .  7
+   3.  RADIUS Authentication. . . . . . . . . . . . . . . . . . . . .  7
+       3.1.  User-Name. . . . . . . . . . . . . . . . . . . . . . . .  8
+       3.2.  User-Password, CHAP-Password, CHAP-Challenge . . . . . .  8
+       3.3.  NAS-IP-Address, NAS-IPv6-Address . . . . . . . . . . . .  8
+       3.4.  NAS-Port . . . . . . . . . . . . . . . . . . . . . . . .  8
+       3.5.  Service-Type . . . . . . . . . . . . . . . . . . . . . .  8
+       3.6.  Framed-Protocol. . . . . . . . . . . . . . . . . . . . .  9
+       3.7.  Framed-IP-Address, Framed-IP-Netmask . . . . . . . . . .  9
+       3.8.  Framed-Routing . . . . . . . . . . . . . . . . . . . . .  9
+       3.9.  Filter-ID. . . . . . . . . . . . . . . . . . . . . . . .  9
+       3.10. Framed-MTU . . . . . . . . . . . . . . . . . . . . . . .  9
+       3.11. Framed-Compression . . . . . . . . . . . . . . . . . . . 10
+       3.12. Displayable Messages . . . . . . . . . . . . . . . . . . 10
+       3.13. Callback-Number, Callback-ID . . . . . . . . . . . . . . 10
+       3.14. Framed-Route, Framed-IPv6-Route. . . . . . . . . . . . . 11
+       3.15. State, Class, Proxy-State. . . . . . . . . . . . . . . . 11
+       3.16. Vendor-Specific. . . . . . . . . . . . . . . . . . . . . 11
+       3.17. Session-Timeout. . . . . . . . . . . . . . . . . . . . . 11
+       3.18. Idle-Timeout . . . . . . . . . . . . . . . . . . . . . . 12
+       3.19. Termination-Action . . . . . . . . . . . . . . . . . . . 12
+       3.20. Called-Station-Id. . . . . . . . . . . . . . . . . . . . 12
+       3.21. Calling-Station-Id . . . . . . . . . . . . . . . . . . . 12
+       3.22. NAS-Identifier . . . . . . . . . . . . . . . . . . . . . 12
+       3.23. NAS-Port-Type. . . . . . . . . . . . . . . . . . . . . . 12
+       3.24. Port-Limit . . . . . . . . . . . . . . . . . . . . . . . 13
+       3.25. Password-Retry . . . . . . . . . . . . . . . . . . . . . 13
+       3.26. Connect-Info . . . . . . . . . . . . . . . . . . . . . . 13
+       3.27. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 13
+       3.28. Message-Authenticator. . . . . . . . . . . . . . . . . . 13
+       3.29. NAS-Port-Id. . . . . . . . . . . . . . . . . . . . . . . 13
+       3.30. Framed-Pool, Framed-IPv6-Pool. . . . . . . . . . . . . . 14
+       3.31. Tunnel Attributes. . . . . . . . . . . . . . . . . . . . 14
+   4.  RC4 EAPOL-Key Descriptor . . . . . . . . . . . . . . . . . . . 15
+   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 18
+       5.1.  Packet Modification or Forgery . . . . . . . . . . . . . 18
+       5.2.  Dictionary Attacks . . . . . . . . . . . . . . . . . . . 19
+       5.3.  Known Plaintext Attacks. . . . . . . . . . . . . . . . . 19
+       5.4.  Replay . . . . . . . . . . . . . . . . . . . . . . . . . 20
+       5.5.  Outcome Mismatches . . . . . . . . . . . . . . . . . . . 20
+
+
+
+Congdon, et al.              Informational                      [Page 2]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+       5.6.  802.11 Integration . . . . . . . . . . . . . . . . . . . 20
+       5.7.  Key Management Issues. . . . . . . . . . . . . . . . . . 21
+   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+       7.1.  Normative References . . . . . . . . . . . . . . . . . . 22
+       7.2.  Informative References . . . . . . . . . . . . . . . . . 23
+   8.  Table of Attributes. . . . . . . . . . . . . . . . . . . . . . 25
+   9.  Intellectual Property Statement  . . . . . . . . . . . . . . . 28
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
+   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
+
+1.  Introduction
+
+   IEEE 802.1X enables authenticated access to IEEE 802 media, including
+   Ethernet, Token Ring, and 802.11 wireless LANs.  Although Remote
+   Authentication Dial In User Service (RADIUS) support is optional
+   within IEEE 802.1X, it is expected that many IEEE 802.1X
+   Authenticators will function as RADIUS clients.
+
+   IEEE 802.1X [IEEE8021X] provides "network port authentication" for
+   IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring
+   and 802.11 [IEEE80211] wireless LANS.
+
+   IEEE 802.1X does not require use of a backend Authentication Server,
+   and thus can be deployed with stand-alone bridges or Access Points,
+   as well as in centrally managed scenarios.
+
+   In situations where it is desirable to centrally manage
+   authentication, authorization and accounting (AAA) for IEEE 802
+   networks, deployment of a backend authentication and accounting
+   server is desirable.  In such situations, it is expected that IEEE
+   802.1X Authenticators will function as AAA clients.
+
+   This document provides suggestions on RADIUS usage by IEEE 802.1X
+   Authenticators.  Support for any AAA protocol is optional for IEEE
+   802.1X Authenticators, and therefore this specification has been
+   incorporated into a non-normative Appendix within the IEEE 802.1X
+   specification.
+
+1.1.  Terminology
+
+   This document uses the following terms:
+
+   Access Point (AP)
+         A Station that provides access to the distribution services via
+         the wireless medium for associated Stations.
+
+
+
+
+Congdon, et al.              Informational                      [Page 3]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   Association
+         The service used to establish Access Point/Station mapping and
+         enable Station invocation of the distribution system services.
+
+   Authenticator
+         An Authenticator is an entity that requires authentication from
+         the Supplicant.  The Authenticator may be connected to the
+         Supplicant at the other end of a point-to-point LAN segment or
+         802.11 wireless link.
+
+   Authentication Server
+         An Authentication Server is an entity that provides an
+         Authentication Service to an Authenticator.  This service
+         verifies, from the credentials provided by the Supplicant, the
+         claim of identity made by the Supplicant.
+
+   Port Access Entity (PAE)
+         The protocol entity associated with a physical or virtual
+         (802.11) Port.  A given PAE may support the protocol
+         functionality associated with the Authenticator, Supplicant or
+         both.
+
+   Station (STA)
+         Any device that contains an IEEE 802.11 conformant medium
+         access control (MAC) and physical layer (PHY) interface to the
+         wireless medium (WM).
+
+   Supplicant
+         A Supplicant is an entity that is being authenticated by an
+         Authenticator.  The Supplicant may be connected to the
+         Authenticator at one end of a point-to-point LAN segment or
+         802.11 wireless link.
+
+1.2.  Requirements Language
+
+   In this document, several words are used to signify the requirements
+   of the specification.  These words are often capitalized.  The key
+   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+   "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document
+   are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+Congdon, et al.              Informational                      [Page 4]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+2.  RADIUS Accounting Attributes
+
+   With a few exceptions, the RADIUS accounting attributes defined in
+   [RFC2866], [RFC2867], and [RFC2869] have the same meaning within IEEE
+   802.1X sessions as they do in dialup sessions and therefore no
+   additional commentary is needed.
+
+   Attributes requiring more discussion include:
+
+      Acct-Terminate-Cause
+      Acct-Multi-Session-Id
+      Acct-Link-Count
+
+2.1.  Acct-Terminate-Cause
+
+   This attribute indicates how the session was terminated, as described
+   in [RFC2866].  [IEEE8021X] defines the following termination cause
+   values, which are shown with their RADIUS equivalents in the table on
+   the next page.
+
+   IEEE 802.1X                       RADIUS
+   dot1xAuthSessionTerminateCause    Acct-Terminate-Cause
+   Value                             Value
+   -------------                     --------------------
+   SupplicantLogoff(1)               User Request (1)
+   portFailure(2)                    Lost Carrier (2)
+   SupplicantRestart(3)              Supplicant Restart (19)
+   reauthFailed(4)                   Reauthentication Failure (20)
+   authControlForceUnauth(5)         Admin Reset (6)
+   portReInit(6)                     Port Reinitialized (21)
+   portAdminDisabled(7)              Port Administratively Disabled (22)
+   notTerminatedYet(999)             N/A
+
+   When using this attribute, the User Request (1) termination cause
+   corresponds to the situation in which the session terminated due to
+   an EAPOL-Logoff received from the Supplicant.  When a session is
+   moved due to roaming, the EAPOL state machines will treat this as a
+   Supplicant Logoff.
+
+   A Lost Carrier (2) termination cause indicates session termination
+   due to loss of physical connectivity for reasons other than roaming
+   between Access Points.  For example, if the Supplicant disconnects a
+   point-to-point LAN connection, or moves out of range of an Access
+   Point, this termination cause is used.  Lost Carrier (2) therefore
+   equates to a Port Disabled condition in the EAPOL state machines.
+
+   A Supplicant Restart (19) termination cause indicates
+   re-initialization of the Supplicant state machines.
+
+
+
+Congdon, et al.              Informational                      [Page 5]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   A Reauthentication Failure (20) termination cause indicates that a
+   previously authenticated Supplicant has failed to re-authenticate
+   successfully following expiry of the re-authentication timer or
+   explicit re-authentication request by management action.
+
+   Within [IEEE80211], periodic re-authentication may be useful in
+   preventing reuse of an initialization vector with a given key.  Since
+   successful re-authentication does not result in termination of the
+   session, accounting packets are not sent as a result of
+   re-authentication unless the status of the session changes.  For
+   example:
+
+   a. The session is terminated due to re-authentication failure.  In
+      this case the Reauthentication Failure (20) termination cause is
+      used.
+
+   b. The authorizations are changed as a result of a successful
+      re-authentication.  In this case, the Service Unavailable (15)
+      termination cause is used.  For accounting purposes, the portion
+      of the session after the authorization change is treated as a
+      separate session.
+
+   Where IEEE 802.1X authentication occurs prior to association,
+   accounting packets are not sent until an association occurs.
+
+   An Admin Reset (6) termination cause indicates that the Port has been
+   administratively forced into the unauthorized state.
+
+   A Port Reinitialized (21) termination cause indicates that the Port's
+   MAC has been reinitialized.
+
+   A Port Administratively Disabled (22) termination cause indicates
+   that the Port has been administratively disabled.
+
+2.2.  Acct-Multi-Session-Id
+
+   The purpose of this attribute is to make it possible to link together
+   multiple related sessions.  While [IEEE8021X] does not act on
+   aggregated ports, it is possible for a Supplicant roaming between
+   Access Points to cause multiple RADIUS accounting packets to be sent
+   by different Access Points.
+
+   Where supported by the Access Points, the Acct-Multi-Session-Id
+   attribute can be used to link together the multiple related sessions
+   of a roaming Supplicant.  In such a situation, if the session context
+   is transferred between Access Points, accounting packets MAY be sent
+   without a corresponding authentication and authorization exchange,
+
+
+
+
+Congdon, et al.              Informational                      [Page 6]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   provided that Association has occurred.  However, in such a situation
+   it is assumed that the Acct-Multi-Session-Id is transferred between
+   the Access Points as part of the Inter-Access Point Protocol (IAPP).
+
+   If the Acct-Multi-Session-Id were not unique between Access Points,
+   then it is possible that the chosen Acct-Multi-Session-Id will
+   overlap with an existing value allocated on that Access Point, and
+   the Accounting Server would therefore be unable to distinguish a
+   roaming session from a multi-link session.
+
+   As a result, the Acct-Multi-Session-Id attribute is unique among all
+   the bridges or Access Points, Supplicants and sessions.  In order to
+   provide this uniqueness, it is suggested that the Acct-Multi-
+   Session-Id be of the form:
+
+   Original AP MAC Address | Supplicant MAC Address | NTP Timestamp
+
+   Here "|" represents concatenation, the original AP MAC Address is the
+   MAC address of the bridge or Access Point at which the session
+   started, and the 64-bit NTP timestamp indicates the beginning of the
+   original session.  In order to provide for consistency of the Acct-
+   Multi-Session-Id between roaming sessions, the Acct-Multi-Session-Id
+   may be moved between Access Points as part of IAPP or another handoff
+   scheme.
+
+   The use of an Acct-Multi-Session-Id of this form guarantees
+   uniqueness among all Access Points, Supplicants and sessions.  Since
+   the NTP timestamp does not wrap on reboot, there is no possibility
+   that a rebooted Access Point could choose an Acct-Multi-Session-Id
+   that could be confused with that of a previous session.
+
+   Since the Acct-Multi-Session-Id is of type String as defined in
+   [RFC2866], for use with IEEE 802.1X, it is encoded as an ASCII string
+   of Hex digits.  Example:  "00-10-A4-23-19-C0-00-12-B2-
+   14-23-DE-AF-23-83-C0-76-B8-44-E8"
+
+2.3.  Acct-Link-Count
+
+   The Acct-Link-Count attribute may be used to account for the number
+   of ports that have been aggregated.
+
+3.  RADIUS Authentication
+
+   This section describes how attributes defined in [RFC2865],
+   [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] are used in
+   IEEE 802.1X authentication.
+
+
+
+
+
+Congdon, et al.              Informational                      [Page 7]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+3.1.  User-Name
+
+   In IEEE 802.1X, the Supplicant typically provides its identity via an
+   EAP-Response/Identity message.  Where available, the Supplicant
+   identity is included in the User-Name attribute, and included in the
+   RADIUS Access-Request and Access-Reply messages as specified in
+   [RFC2865] and [RFC3579].
+
+   Alternatively, as discussed in [RFC3579] Section 2.1., the User-Name
+   attribute may contain the Calling-Station-ID value, which is set to
+   the Supplicant MAC address.
+
+3.2.  User-Password, CHAP-Password, CHAP-Challenge
+
+   Since IEEE 802.1X does not support PAP or CHAP authentication, the
+   User-Password, CHAP-Password or CHAP-Challenge attributes are not
+   used by IEEE 802.1X Authenticators acting as RADIUS clients.
+
+3.3.  NAS-IP-Address, NAS-IPv6-Address
+
+   For use with IEEE 802.1X, the NAS-IP-Address contains the IPv4
+   address of the bridge or Access Point acting as an Authenticator, and
+   the NAS-IPv6-Address contains the IPv6 address.  If the IEEE 802.1X
+   Authenticator has more than one interface, it may be desirable to use
+   a loopback address for this purpose so that the Authenticator will
+   still be reachable even if one of the interfaces were to fail.
+
+3.4.  NAS-Port
+
+   For use with IEEE 802.1X the NAS-Port will contain the port number of
+   the bridge, if this is available.  While an Access Point does not
+   have physical ports, a unique "association ID" is assigned to every
+   mobile Station upon a successful association exchange.  As a result,
+   for an Access Point, if the association exchange has been completed
+   prior to authentication, the NAS-Port attribute will contain the
+   association ID, which is a 16-bit unsigned integer.  Where IEEE
+   802.1X authentication occurs prior to association, a unique NAS-Port
+   value may not be available.
+
+3.5.  Service-Type
+
+   For use with IEEE 802.1X, the Framed (2), Authenticate Only (8), and
+   Call Check (10) values are most commonly used.
+
+   A Service-Type of Framed indicates that appropriate 802 framing
+   should be used for the connection.  A Service-Type of Authenticate
+   Only (8) indicates that no authorization information needs to be
+   returned in the Access-Accept.  As described in [RFC2865], a
+
+
+
+Congdon, et al.              Informational                      [Page 8]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   Service-Type of Call Check is included in an Access-Request packet to
+   request that the RADIUS server accept or reject the connection
+   attempt, typically based on the Called-Station-ID (set to the bridge
+   or Access Point MAC address) or Calling-Station-ID attributes (set to
+   the Supplicant MAC address).  As noted in [RFC2865], it is
+   recommended that in this case, the User-Name attribute be given the
+   value of Calling-Station-Id.
+
+3.6.  Framed-Protocol
+
+   Since there is no value for IEEE 802 media, the Framed-Protocol
+   attribute is not used by IEEE 802.1X Authenticators.
+
+3.7.  Framed-IP-Address, Framed-IP-Netmask
+
+   IEEE 802.1X does not provide a mechanism for IP address assignment.
+   Therefore the Framed-IP-Address and Framed-IP-Netmask attributes can
+   only be used by IEEE 802.1X Authenticators that support IP address
+   assignment mechanisms.  Typically this capability is supported by
+   layer 3 devices.
+
+3.8.  Framed-Routing
+
+   The Framed-Routing attribute indicates the routing method for the
+   Supplicant.  It is therefore only relevant for IEEE 802.1X
+   Authenticators that act as layer 3 devices, and cannot be used by a
+   bridge or Access Point.
+
+3.9.  Filter-ID
+
+   This attribute indicates the name of the filter list to be applied to
+   the Supplicant's session.  For use with an IEEE 802.1X Authenticator,
+   it may be used to indicate either layer 2 or layer 3 filters.  Layer
+   3 filters are typically only supported on IEEE 802.1X Authenticators
+   that act as layer 3 devices.
+
+3.10.  Framed-MTU
+
+   This attribute indicates the maximum size of an IP packet that may be
+   transmitted over the wire between the Supplicant and the
+   Authenticator.  IEEE 802.1X Authenticators set this to the value
+   corresponding to the relevant 802 medium, and include it in the
+   RADIUS Access-Request.  The RADIUS server may send an EAP packet as
+   large as Framed-MTU minus four (4) octets, taking into account the
+   additional overhead for the IEEE 802.1X Version (1), Type (1) and
+   Body Length (2) fields.  For EAP over IEEE 802 media, the Framed-MTU
+   values (which do not include LLC/SNAP overhead) and maximum frame
+   length values (not including the preamble) are as follows:
+
+
+
+Congdon, et al.              Informational                      [Page 9]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+                                        Maximum Frame
+   Media             Framed-MTU            Length
+   =========        ===============     ==============
+   Ethernet              1500              1522
+   802.3                 1500              1522
+   802.4                 8174              8193
+   802.5 (4 Mbps)        4528              4550
+   802.5 (16 Mbps)      18173             18200
+   802.5 (100 Mb/s)     18173             18200
+   802.6                 9191              9240
+   802.9a                1500              1518
+   802.11                2304              2346
+   802.12 (Ethernet)     1500              1518
+   802.12 (Token Ring)   4502              4528
+   FDDI                  4479              4500
+
+   NOTE - the Framed-MTU size for IEEE 802.11 media may change as a
+   result of ongoing work being undertaken in the IEEE 802.11 Working
+   Group.  Since some 802.11 stations cannot handle an MTU larger than
+   1500 octets, it is recommended that RADIUS servers encountering a
+   NAS-Port-Type value of 802.11 send EAP packets no larger than 1496
+   octets.
+
+3.11.  Framed-Compression
+
+   [IEEE8021X] does not include compression support.  Therefore this
+   attribute is not understood by [IEEE8021X] Authenticators.
+
+3.12.  Displayable Messages
+
+   The Reply-Message attribute, defined in section 5.18 of [RFC2865],
+   indicates text which may be displayed to the user.  This is similar
+   in concept to the EAP Notification Type, defined in [RFC2284].  As
+   noted in [RFC3579], Section 2.6.5, when sending a displayable message
+   to an [IEEE8021X] Authenticator, displayable messages are best sent
+   within EAP-Message/EAP-Request/Notification attribute(s), and not
+   within Reply-Message attribute(s).
+
+3.13.  Callback-Number, Callback-ID
+
+   These attributes are not understood by IEEE 802.1X Authenticators.
+
+
+
+
+
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 10]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+3.14.  Framed-Route, Framed-IPv6-Route
+
+   The Framed-Route and Framed-IPv6-Route attributes provide routes that
+   are to be configured for the Supplicant.  These attributes are
+   therefore only relevant for IEEE 802.1X Authenticators that act as
+   layer 3 devices, and cannot be understood by a bridge or Access
+   Point.
+
+3.15.  State, Class, Proxy-State
+
+   These attributes are used for the same purposes as described in
+   [RFC2865].
+
+3.16.  Vendor-Specific
+
+   Vendor-specific attributes are used for the same purposes as
+   described in [RFC2865].  The MS-MPPE-Send-Key and MS-MPPE-Recv-Key
+   attributes, described in section 2.4 of [RFC2548], MAY be used to
+   encrypt and authenticate the RC4 EAPOL-Key descriptor [IEEE8021X,
+   Section 7.6].  Examples of the derivation of the MS-MPPE-Send-Key and
+   MS-MPPE-Recv-Key attributes from the master key negotiated by an EAP
+   method are given in [RFC2716].  Details of the EAPOL-Key descriptor
+   are provided in Section 4.
+
+3.17.  Session-Timeout
+
+   When sent along in an Access-Accept without a Termination-Action
+   attribute or with a Termination-Action attribute set to Default, the
+   Session-Timeout attribute specifies the maximum number of seconds of
+   service provided prior to session termination.
+
+   When sent in an Access-Accept along with a Termination-Action value
+   of RADIUS-Request, the Session-Timeout attribute specifies the
+   maximum number of seconds of service provided prior to re-
+   authentication.  In this case, the Session-Timeout attribute is used
+   to load the reAuthPeriod constant within the Reauthentication Timer
+   state machine of 802.1X.  When sent with a Termination-Action value
+   of RADIUS-Request, a Session-Timeout value of zero indicates the
+   desire to perform another authentication (possibly of a different
+   type) immediately after the first authentication has successfully
+   completed.
+
+   When sent in an Access-Challenge, this attribute represents the
+   maximum number of seconds that an IEEE 802.1X Authenticator should
+   wait for an EAP-Response before retransmitting.  In this case, the
+   Session-Timeout attribute is used to load the suppTimeout constant
+   within the backend state machine of IEEE 802.1X.
+
+
+
+
+Congdon, et al.              Informational                     [Page 11]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+3.18.  Idle-Timeout
+
+   The Idle-Timeout attribute is described in [RFC2865].  For IEEE 802
+   media other than 802.11 the media are always on.  As a result the
+   Idle-Timeout attribute is typically only used with wireless media
+   such as IEEE 802.11.  It is possible for a wireless device to wander
+   out of range of all Access Points.  In this case, the Idle-Timeout
+   attribute indicates the maximum time that a wireless device may
+   remain idle.
+
+3.19.  Termination-Action
+
+   This attribute indicates what action should be taken when the service
+   is completed.  The value RADIUS-Request (1) indicates that re-
+   authentication should occur on expiration of the Session-Time.  The
+   value Default (0) indicates that the session should terminate.
+
+3.20.  Called-Station-Id
+
+   For IEEE 802.1X Authenticators, this attribute is used to store the
+   bridge or Access Point MAC address in ASCII format (upper case only),
+   with octet values separated by a "-".  Example: "00-10-A4-23-19-C0".
+   In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
+   Access Point MAC address, separated from the MAC address with a ":".
+   Example "00-10-A4-23-19-C0:AP1".
+
+3.21.  Calling-Station-Id
+
+   For IEEE 802.1X Authenticators, this attribute is used to store the
+   Supplicant MAC address in ASCII format (upper case only), with octet
+   values separated by a "-".  Example: "00-10-A4-23-19-C0".
+
+3.22.  NAS-Identifier
+
+   This attribute contains a string identifying the IEEE 802.1X
+   Authenticator originating the Access-Request.
+
+3.23.  NAS-Port-Type
+
+   For use with IEEE 802.1X, NAS-Port-Type values of Ethernet (15)
+   Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be
+   used.
+
+
+
+
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 12]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+3.24.  Port-Limit
+
+   This attribute has no meaning when sent to an [IEEE8021X]
+   Authenticator.
+
+3.25.  Password-Retry
+
+   In IEEE 802.1X, the Authenticator always transitions to the HELD
+   state after an authentication failure.  Thus this attribute does not
+   make sense for IEEE 802.1X.
+
+3.26.  Connect-Info
+
+   This attribute is sent by a bridge or Access Point to indicate the
+   nature of the Supplicant's connection.  When sent in the Access-
+   Request it is recommended that this attribute contain information on
+   the speed of the Supplicant's connection.  For 802.11, the following
+   format is recommended: "CONNECT 11Mbps 802.11b".  If sent in the
+   Accounting STOP, this attribute may be used to summarize statistics
+   relating to session quality.  For example, in IEEE 802.11, the
+   Connect-Info attribute may contain information on the number of link
+   layer retransmissions.  The exact format of this attribute is
+   implementation specific.
+
+3.27.  EAP-Message
+
+   Since IEEE 802.1X provides for encapsulation of EAP as described in
+   [RFC2284] and [IEEE8021X], the EAP-Message attribute defined in
+   [RFC3579] is used to encapsulate EAP packets for transmission from
+   the IEEE 802.1X Authenticator to the Authentication Server. [RFC3579]
+   Section 2.2. describes how the Authentication Server handles invalid
+   EAP packets passed to it by the Authenticator.
+
+3.28.  Message-Authenticator
+
+   As noted in [RFC3579] Section 3.1., the Message-Authenticator
+   attribute MUST be used to protect packets within a RADIUS/EAP
+   conversation.
+
+3.29.  NAS-Port-Id
+
+   This attribute is used to identify the IEEE 802.1X Authenticator port
+   which authenticates the Supplicant.  The NAS-Port-Id differs from the
+   NAS-Port in that it is a string of variable length whereas the NAS-
+   Port is a 4 octet value.
+
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 13]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+3.30.  Framed-Pool, Framed-IPv6-Pool
+
+   IEEE 802.1X does not provide a mechanism for IP address assignment.
+   Therefore the Framed-Pool and Framed-IPv6-Pool attributes can only be
+   used by IEEE 802.1X Authenticators that support IP address assignment
+   mechanisms.  Typically this capability is supported by layer 3
+   devices.
+
+3.31.  Tunnel Attributes
+
+   Reference [RFC2868] defines RADIUS tunnel attributes used for
+   authentication and authorization, and [RFC2867] defines tunnel
+   attributes used for accounting.  Where the IEEE 802.1X Authenticator
+   supports tunneling, a compulsory tunnel may be set up for the
+   Supplicant as a result of the authentication.
+
+   In particular, it may be desirable to allow a port to be placed into
+   a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the
+   result of the authentication.  This can be used, for example, to
+   allow a wireless host to remain on the same VLAN as it moves within a
+   campus network.
+
+   The RADIUS server typically indicates the desired VLAN by including
+   tunnel attributes within the Access-Accept.  However, the IEEE 802.1X
+   Authenticator may also provide a hint as to the VLAN to be assigned
+   to the Supplicant by including Tunnel attributes within the Access-
+   Request.
+
+   For use in VLAN assignment, the following tunnel attributes are used:
+
+   Tunnel-Type=VLAN (13)
+   Tunnel-Medium-Type=802
+   Tunnel-Private-Group-ID=VLANID
+
+   Note that the VLANID is 12-bits, taking a value between 1 and 4094,
+   inclusive.  Since the Tunnel-Private-Group-ID is of type String as
+   defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer
+   value is encoded as a string.
+
+   When Tunnel attributes are sent, it is necessary to fill in the Tag
+   field.  As noted in [RFC2868], section 3.1:
+
+      The Tag field is one octet in length and is intended to provide a
+      means of grouping attributes in the same packet which refer to the
+      same tunnel.  Valid values for this field are 0x01 through 0x1F,
+      inclusive.  If the Tag field is unused, it MUST be zero (0x00).
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 14]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel-
+   Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or
+   Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel-
+   Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of
+   greater than 0x1F is interpreted as the first octet of the following
+   field.
+
+   Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X
+   Authenticators that may support tunneling but not VLANs), it is only
+   necessary for tunnel attributes to specify a single tunnel.  As a
+   result, where it is only desired to specify the VLANID, the tag field
+   SHOULD be set to zero (0x00) in all tunnel attributes.  Where
+   alternative tunnel types are to be provided, tag values between 0x01
+   and 0x1F SHOULD be chosen.
+
+4.  RC4 EAPOL-Key Frame
+
+   The RC4 EAPOL-Key frame is created and transmitted by the
+   Authenticator in order to provide media specific key information.
+   For example, within 802.11 the RC4 EAPOL-Key frame can be used to
+   distribute multicast/broadcast ("default") keys, or unicast ("key
+   mapping") keys.  The "default" key is the same for all Stations
+   within a broadcast domain.
+
+   The RC4 EAPOL-Key frame is not acknowledged and therefore the
+   Authenticator does not know whether the Supplicant has received it.
+   If it is lost, then the Supplicant and Authenticator will not have
+   the same keying material, and communication will fail.  If this
+   occurs, the problem is typically addressed by re-running the
+   authentication.
+
+   The RC4 EAPOL-Key frame is sent from the Authenticator to the
+   Supplicant in order to provision the "default" key, and subsequently
+   in order to refresh the "default" key.  It may also be used to
+   refresh the key-mapping key.  Rekey is typically only required with
+   weak ciphersuites such as WEP, defined in [IEEE80211].
+
+   Where keys are required, an EAP method that derives keys is typically
+   selected.  Therefore the initial "key mapping" keys can be derived
+   from EAP keying material, without requiring the Authenticator to send
+   an RC4 EAPOL-Key frame to the Supplicant.  An example of how EAP
+   keying material can be derived and used is presented in [RFC2716].
+
+
+
+
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 15]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more
+   complete description is provided on the next page.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Version    |  Packet Type  |  Packet Body Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |          Key  Length          |Replay Counter...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Replay Counter...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Replay Counter    |   Key IV...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Key IV...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Key IV...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Key IV...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Key IV...         |F| Key Index   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Key Signature...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Key Signature...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Key Signature...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Key Signature...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Key...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Version
+      The Version field is one octet.  For IEEE 802.1X, it contains the
+      value 0x01.
+
+   Packet Type
+      The Packet Type field is one octet, and determines the type of
+      packet being transmitted.  For an EAPOL-Key Descriptor, the Packet
+      Type field contains 0x03.
+
+   Packet Body Length
+      The Packet Body Length is two octets, and contains the length of
+      the EAPOL-Key descriptor in octets, not including the Version,
+      Packet Type and Packet Body Length fields.
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 16]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   Type
+      The Type field is a single octet.  The Key descriptor is defined
+      differently for each Type; this specification documents only the
+      RC4 Key Descriptor (Type = 0x01).
+
+   Key Length
+      The Key Length field is two octets.  If Packet Body Length = 44 +
+      Key Length, then the Key Field contains the key in encrypted form,
+      of length Key Length.  This is 5 octets (40 bits) for WEP, and 13
+      octets (104 bits) for WEP-128.  If Packet Body Length = 44, then
+      the Key field is absent, and Key Length represents the number of
+      least significant octets from the MS-MPPE-Send-Key attribute
+      [RFC2548] to be used as the keying material.  Note that the MS-
+      MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the
+      point of view of the Authenticator.  From the Supplicant point of
+      reference, the terms are reversed.  Thus the MS-MPPE-Recv-Key on
+      the Supplicant corresponds to the MS-MPPE-Send-Key on the
+      Authenticator, and the MS-MPPE-Send-Key on the Supplicant
+      corresponds to the MS-MPPE-Recv-Key on the Authenticator.
+
+   Replay Counter
+      The Replay Counter field is 8 octets.  It does not repeat within
+      the life of the keying material used to encrypt the Key field and
+      compute the Key Signature field.  A 64-bit NTP timestamp MAY be
+      used as the Replay Counter.
+
+   Key IV
+      The Key IV field is 16 octets and includes a 128-bit
+      cryptographically random number.
+
+   F
+      The Key flag (F) is a single bit, describing the type of key that
+      is included in the Key field.  Values are:
+
+      0 = for broadcast (default key)
+      1 = for unicast (key mapping key)
+
+   Key Index
+      The Key Index is 7 bits.
+
+   Key Signature
+      The Key Signature field is 16 octets.  It contains an HMAC-MD5
+      message integrity check computed over the EAPOL-Key descriptor,
+      starting from the Version field, with the Key field filled in if
+      present, but with the Key Signature field set to zero.  For the
+      computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is
+      used as the HMAC-MD5 key.
+
+
+
+
+Congdon, et al.              Informational                     [Page 17]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   Key
+      If Packet Body Length = 44 + Key Length, then the Key Field
+      contains the key in encrypted form, of length Key Length.  If
+      Packet Body Length = 44, then the Key field is absent, and the
+      least significant Key Length octets from the MS-MPPE-Send-Key
+      attribute is used as the keying material.  Where the Key field is
+      encrypted using RC4, the RC4 encryption key used to encrypt this
+      field is formed by concatenating the 16 octet (128 bit) Key-IV
+      field with the 32 octet MS-MPPE-Recv-Key attribute.  This yields a
+      48 octet RC4 key (384 bits).
+
+5.  Security Considerations
+
+   Since this document describes the use of RADIUS for purposes of
+   authentication, authorization, and accounting in IEEE 802.1X-enabled
+   networks, it is vulnerable to all of the threats that are present in
+   other RADIUS applications.  For a discussion of these threats, see
+   [RFC2607], [RFC2865], [RFC3162], [RFC3579], and [RFC3576].
+
+   Vulnerabilities include:
+
+      Packet modification or forgery
+      Dictionary attacks
+      Known plaintext attacks
+      Replay
+      Outcome mismatches
+      802.11 integration
+      Key management issues
+
+5.1.  Packet Modification or Forgery
+
+   RADIUS, defined in [RFC2865], does not require all Access-Requests to
+   be authenticated or integrity protected.  However, IEEE 802.1X is
+   based on EAP.  As described in [3579], Section 3.1.:
+
+      The Message-Authenticator attribute MUST be used to protect all
+      Access-Request, Access-Challenge, Access-Accept, and Access-Reject
+      packets containing an EAP-Message attribute.
+
+   As a result, when used with IEEE 802.1X, all RADIUS packets MUST be
+   authenticated and integrity protected.  In addition, as described in
+   [3579], Section 4.2.:
+
+      To address the security vulnerabilities of RADIUS/EAP,
+      implementations of this specification SHOULD support IPsec
+      [RFC2401] along with IKE [RFC2409] for key management.  IPsec ESP
+      [RFC2406] with non-null transform SHOULD be supported, and IPsec
+      ESP with a non-null encryption transform and authentication
+
+
+
+Congdon, et al.              Informational                     [Page 18]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+      support SHOULD be used to provide per-packet confidentiality,
+      authentication, integrity and replay protection.  IKE SHOULD be
+      used for key management.
+
+5.2.  Dictionary Attacks
+
+   As discussed in [RFC3579] Section 4.3.3., the RADIUS shared secret is
+   vulnerable to offline dictionary attack, based on capture of the
+   Response Authenticator or Message-Authenticator attribute.  In order
+   to decrease the level of vulnerability, [RFC2865], Section 3
+   recommends:
+
+      The secret (password shared between the client and the RADIUS
+      server) SHOULD be at least as large and unguessable as a well-
+      chosen password.  It is preferred that the secret be at least 16
+      octets.
+
+   In addition, the risk of an offline dictionary attack can be further
+   mitigated by employing IPsec ESP with a non-null transform in order
+   to encrypt the RADIUS conversation, as described in [RFC3579],
+   Section 4.2.
+
+5.3.  Known Plaintext Attacks
+
+   Since IEEE 802.1X is based on EAP, which does not support PAP, the
+   RADIUS User-Password attribute is not used to carry hidden user
+   passwords.  The hiding mechanism utilizes MD5, defined in [RFC1321],
+   in order to generate a key stream based on the RADIUS shared secret
+   and the Request Authenticator.  Where PAP is in use, it is possible
+   to collect key streams corresponding to a given Request Authenticator
+   value, by capturing RADIUS conversations corresponding to a PAP
+   authentication attempt using a known password.  Since the User-
+   Password is known, the key stream corresponding to a given Request
+   Authenticator can be determined and stored.
+
+   The vulnerability is described in detail in [RFC3579], Section 4.3.4.
+   Even though IEEE 802.1X Authenticators do not support PAP
+   authentication, a security vulnerability can still exist where the
+   same RADIUS shared secret is used for hiding User-Password as well as
+   other attributes.  This can occur, for example, if the same RADIUS
+   proxy handles authentication requests for both IEEE 802.1X (which may
+   hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key
+   attributes) and GPRS (which may hide the User-Password attribute).
+
+   The threat can be mitigated by protecting RADIUS with IPsec ESP with
+   a non-null transform, as described in [RFC3579], Section 4.2.  In
+   addition, the same RADIUS shared secret MUST NOT be used for both
+   IEEE 802.1X authentication and PAP authentication.
+
+
+
+Congdon, et al.              Informational                     [Page 19]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+5.4.  Replay
+
+   As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides
+   only limited support for replay protection.  Replay protection for
+   RADIUS authentication and accounting can be provided by enabling
+   IPsec replay protection with RADIUS, as described in [RFC3579],
+   Section 4.2.
+
+   As with the Request Authenticator, for use with IEEE 802.1X
+   Authenticators, the Acct-Session-Id SHOULD be globally and temporally
+   unique.
+
+5.5.  Outcome Mismatches
+
+   [RFC3579] Section 2.6.3. discusses the issues that arise when the EAP
+   packet encapsulated in an EAP-Message attribute does not agree with
+   the RADIUS Packet Type.  For example, an EAP Success packet might be
+   encapsulated within an Access-Reject; an EAP Failure might be sent
+   within an Access-Accept; or an EAP Success or Failure might be sent
+   within an Access-Challenge.
+
+   As described in [RFC3579] Section 2.6.3., these conflicting messages
+   are likely to cause confusion.  To ensure that access decisions made
+   by IEEE 802.1X Authenticators conform to the wishes of the RADIUS
+   server, it is necessary for the Authenticator to make the decision
+   solely based on the authentication result (Access-Accept/Reject) and
+   not based on the contents of EAP-Message attributes, if present.
+
+5.6.  802.11 Integration
+
+   [IEEE8021X] was developed for use on wired IEEE 802 networks such as
+   Ethernet, and therefore does not describe how to securely adapt IEEE
+   802.1X for use with 802.11.  This is left to an enhanced security
+   specification under development within IEEE 802.11.
+
+   For example, [IEEE8021X] does not specify whether authentication
+   occurs prior to, or after association, nor how the derived keys are
+   used within various ciphersuites.  It also does not specify
+   ciphersuites addressing the vulnerabilities discovered in WEP,
+   described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl].
+   [IEEE8021X] only defines an authentication framework, leaving the
+   definition of the authentication methods to other documents, such as
+   [RFC2716].
+
+   Since [IEEE8021X] does not address 802.11 integration issues,
+   implementors are strongly advised to consult additional IEEE 802.11
+   security specifications for guidance on how to adapt IEEE 802.1X for
+   use with 802.11.  For example, it is likely that the IEEE 802.11
+
+
+
+Congdon, et al.              Informational                     [Page 20]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   enhanced security specification will define its own IEEE 802.11 key
+   hierarchy as well as new EAPOL-Key descriptors.
+
+5.7.  Key Management Issues
+
+   The EAPOL-Key descriptor described in Section 4. is likely to be
+   deprecated in the future, when the IEEE 802.11 enhanced security
+   group completes its work.  Known security issues include:
+
+   [1]  Default key-only support.  IEEE 802.1X enables the derivation of
+        per-Station unicast keys, known in [IEEE80211] as "key mapping
+        keys."  Keys used to encrypt multicast/broadcast traffic are
+        known as "default keys".  However, in some 802.11
+        implementations, the unicast keys, derived as part of the EAP
+        authentication process, are used solely in order to encrypt,
+        authenticate and integrity protect the EAPOL-Key descriptor, as
+        described in Section 4.  These implementations only support use
+        of default keys (ordinarily only used with multicast/broadcast
+        traffic) to secure all traffic, unicast or multicast/broadcast,
+        resulting in inherent security weaknesses.
+
+        Where per-Station key-mapping keys (e.g. unicast keys) are
+        unsupported, any Station possessing the default key can decrypt
+        traffic from other Stations or impersonate them.  When used
+        along with a weak cipher (e.g. WEP), implementations supporting
+        only default keys provide more material for attacks such as
+        those described in [Fluhrer] and [Stubbl].  If in addition, the
+        default key is not refreshed periodically, IEEE 802.1X dynamic
+        key derivation provides little or no security benefit.  For an
+        understanding of the issues with WEP, see [Berkeley], [Arbaugh],
+        [Fluhrer], and [Stubbl].
+
+   [2]  Reuse of keying material.  The EAPOL-Key descriptor specified in
+        section 4 uses the same keying material (MS-MPPE-Recv-Key) both
+        to encrypt the Key field within the EAPOL-Key descriptor, and to
+        encrypt data passed between the Station and Access Point.
+        Multi-purpose keying material is frowned upon, since multiple
+        uses can leak information helpful to an attacker.
+
+   [3]  Weak algorithms.  The algorithm used to encrypt the Key field
+        within the EAPOL-Key descriptor is similar to the algorithm used
+        in WEP, and as a result, shares some of the same weaknesses.  As
+        with WEP, the RC4 stream cipher is used to encrypt the key.  As
+        input to the RC4 engine, the IV and key are concatenated rather
+        than being combined within a mixing function.  As with WEP, the
+        IV is not a counter, and therefore there is little protection
+        against reuse.
+
+
+
+
+Congdon, et al.              Informational                     [Page 21]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   As a result of these vulnerabilities, implementors intending to use
+   the EAPOL-Key descriptor described in this document are urged to
+   consult the 802.11 enhanced security specification for a more secure
+   alternative.  It is also advisable to consult the evolving literature
+   on WEP vulnerabilities, in order to better understand the risks, as
+   well as to obtain guidance on setting an appropriate re-keying
+   interval.
+
+6.  IANA Considerations
+
+   This specification does not create any RADIUS attributes nor any new
+   number spaces for IANA administration.  However, it does require
+   assignment of new values to existing RADIUS attributes.  These
+   include:
+
+   Attribute              Values Required
+   =========              ===============
+   NAS-Port-Type          Token-Ring (20), FDDI (21)
+   Tunnel-Type            VLAN (13)
+   Acct-Terminate-Cause   Supplicant Restart (19)
+                          Reauthentication Failure (20)
+                          Port Reinitialized (21)
+                          Port Administratively Disabled (22)
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC
+                  1321, April 1992.
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2284]      Blunk, L. and J. Vollbrecht, "PPP Extensible
+                  Authentication Protocol (EAP)", RFC 2284, March 1998.
+
+   [RFC2865]      Rigney, C., Willens, S., Rubens, A. and W. Simpson,
+                  "Remote Authentication Dial In User Service (RADIUS)",
+                  RFC 2865, June 2000.
+
+   [RFC2866]      Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+   [RFC2867]      Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
+                  Modifications for Tunnel Protocol Support", RFC 2867,
+                  June 2000.
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 22]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   [RFC2868]      Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
+                  Holdrege, M. and I. Goyret, "RADIUS Attributes for
+                  Tunnel Protocol Support", RFC 2868, June 2000.
+
+   [RFC2869]      Rigney, C., Willats, W. and P. Calhoun, "RADIUS
+                  Extensions", RFC 2869, June 2000.
+
+   [RFC3162]      Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
+                  RFC 3162, August 2001.
+
+   [RFC3280]      Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+                  X.509 Public Key Infrastructure Certificate and
+                  Certificate Revocation List (CRL) Profile", RFC 3280,
+                  April 2002.
+
+   [RFC3576]      Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
+                  Aboba, "Dynamic Authorization Extensions to Remote
+                  Authentication Dial In User Service (RADIUS)", RFC
+                  3576, July 2003.
+
+   [RFC3579]      Aboba, B. and P. Calhoun, "RADIUS (Remote
+                  Authentication Dial In User Service) Support For
+                  Extensible Authentication Protocol (EAP)", RFC 3579,
+                  September 2003.
+
+   [IEEE8021X]    IEEE Standards for Local and Metropolitan Area
+                  Networks:  Port based Network Access Control, IEEE Std
+                  802.1X-2001, June 2001.
+
+7.2.  Informative References
+
+   [RFC2104]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
+                  Keyed-Hashing for Message Authentication", RFC 2104,
+                  February 1997.
+
+   [RFC2434]      Narten, T. and H. Alvestrand, "Guidelines for Writing
+                  an IANA Considerations Section in RFCs", BCP 26, RFC
+                  2434, October 1998.
+
+   [RFC2548]      Zorn, G., "Microsoft Vendor-specific RADIUS
+                  Attributes", RFC 2548, March 1999.
+
+   [RFC2607]      Aboba, B. and J. Vollbrecht, "Proxy Chaining and
+                  Policy Implementation in Roaming", RFC 2607, June
+                  1999.
+
+   [RFC2716]      Aboba, B. and D. Simon, "PPP EAP TLS Authentication
+                  Protocol", RFC 2716, October 1999.
+
+
+
+Congdon, et al.              Informational                     [Page 23]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   [MD5Attack]    Dobbertin, H., "The Status of MD5 After a Recent
+                  Attack."  CryptoBytes Vol.2 No.2, Summer 1996.
+
+   [IEEE802]      IEEE Standards for Local and Metropolitan Area
+                  Networks:  Overview and Architecture, ANSI/IEEE Std
+                  802, 1990.
+
+   [IEEE8021Q]    IEEE Standards for Local and Metropolitan Area
+                  Networks:  Draft Standard for Virtual Bridged Local
+                  Area Networks, P802.1Q, January 1998.
+
+   [IEEE8023]     ISO/IEC 8802-3 Information technology -
+                  Telecommunications and information exchange between
+                  systems - Local and metropolitan area networks -
+                  Common specifications - Part 3:  Carrier Sense
+                  Multiple Access with Collision Detection (CSMA/CD)
+                  Access Method and Physical Layer Specifications, (also
+                  ANSI/IEEE Std 802.3- 1996), 1996.
+
+   [IEEE80211]    Information technology - Telecommunications and
+                  information exchange between systems - Local and
+                  metropolitan area networks - Specific Requirements
+                  Part 11:  Wireless LAN Medium Access Control (MAC) and
+                  Physical Layer (PHY) Specifications, IEEE Std.
+                  802.11-1999, 1999.
+
+   [Berkeley]     Borisov, N., Goldberg, I. and D. Wagner, "Intercepting
+                  Mobile Communications: The Insecurity of 802.11", ACM
+                  SIGMOBILE, Seventh Annual International Conference on
+                  Mobile Computing and Networking, July 2001, Rome,
+                  Italy.
+
+   [Arbaugh]      Arbaugh, W., Shankar, N. and J.Y.C. Wan, "Your 802.11
+                  Wireless Network has No Clothes", Department of
+                  Computer Science, University of Maryland, College
+                  Park, March 2001.
+
+   [Fluhrer]      Fluhrer, S., Mantin, I. and A. Shamir, "Weaknesses in
+                  the Key Scheduling Algorithm of RC4", Eighth Annual
+                  Workshop on Selected Areas in Cryptography, Toronto,
+                  Canada, August 2001.
+
+   [Stubbl]       Stubblefield, A., Ioannidis, J. and A. Rubin, "Using
+                  the Fluhrer, Mantin and Shamir Attack to Break WEP",
+                  2002 NDSS Conference.
+
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 24]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+8.  Table of Attributes
+
+   The following table provides a guide to which attributes MAY be sent
+   and received as part of IEEE 802.1X authentication.  L3 denotes
+   attributes that require layer 3 capabilities, and thus may not be
+   supported by all Authenticators.  For each attribute, the reference
+   provides the definitive information on usage.
+
+   802.1X        #   Attribute
+     X           1   User-Name [RFC2865]
+                 2   User-Password [RFC2865]
+                 3   CHAP-Password [RFC2865]
+     X           4   NAS-IP-Address [RFC2865]
+     X           5   NAS-Port [RFC2865]
+     X           6   Service-Type [RFC2865]
+                 7   Framed-Protocol [RFC2865]
+     L3          8   Framed-IP-Address [RFC2865]
+     L3          9   Framed-IP-Netmask [RFC2865]
+     L3         10   Framed-Routing [RFC2865]
+     X          11   Filter-Id [RFC2865]
+     X          12   Framed-MTU [RFC2865]
+                13   Framed-Compression [RFC2865]
+     L3         14   Login-IP-Host [RFC2865]
+     L3         15   Login-Service [RFC2865]
+     L3         16   Login-TCP-Port [RFC2865]
+                18   Reply-Message [RFC2865]
+                19   Callback-Number [RFC2865]
+                20   Callback-Id [RFC2865]
+     L3         22   Framed-Route [RFC2865]
+     L3         23   Framed-IPX-Network [RFC2865]
+     X          24   State [RFC2865]
+     X          25   Class [RFC2865]
+     X          26   Vendor-Specific [RFC2865]
+     X          27   Session-Timeout [RFC2865]
+     X          28   Idle-Timeout [RFC2865]
+     X          29   Termination-Action [RFC2865]
+     X          30   Called-Station-Id [RFC2865]
+     X          31   Calling-Station-Id [RFC2865]
+     X          32   NAS-Identifier [RFC2865]
+     X          33   Proxy-State [RFC2865]
+                34   Login-LAT-Service [RFC2865]
+                35   Login-LAT-Node [RFC2865]
+                36   Login-LAT-Group [RFC2865]
+   802.1X        #   Attribute
+
+
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 25]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   802.1X        #   Attribute
+     L3         37   Framed-AppleTalk-Link [RFC2865]
+     L3         38   Framed-AppleTalk-Network [RFC2865]
+     L3         39   Framed-AppleTalk-Zone [RFC2865]
+     X          40   Acct-Status-Type [RFC2866]
+     X          41   Acct-Delay-Time [RFC2866]
+     X          42   Acct-Input-Octets [RFC2866]
+     X          43   Acct-Output-Octets [RFC2866]
+     X          44   Acct-Session-Id [RFC2866]
+     X          45   Acct-Authentic [RFC2866]
+     X          46   Acct-Session-Time [RFC2866]
+     X          47   Acct-Input-Packets [RFC2866]
+     X          48   Acct-Output-Packets [RFC2866]
+     X          49   Acct-Terminate-Cause [RFC2866]
+     X          50   Acct-Multi-Session-Id [RFC2866]
+     X          51   Acct-Link-Count [RFC2866]
+     X          52   Acct-Input-Gigawords [RFC2869]
+     X          53   Acct-Output-Gigawords [RFC2869]
+     X          55   Event-Timestamp [RFC2869]
+                60   CHAP-Challenge [RFC2865]
+     X          61   NAS-Port-Type [RFC2865]
+                62   Port-Limit [RFC2865]
+                63   Login-LAT-Port [RFC2865]
+     X          64   Tunnel-Type [RFC2868]
+     X          65   Tunnel-Medium-Type [RFC2868]
+     L3         66   Tunnel-Client-Endpoint [RFC2868]
+     L3         67   Tunnel-Server-Endpoint [RFC2868]
+     L3         68   Acct-Tunnel-Connection [RFC2867]
+     L3         69   Tunnel-Password [RFC2868]
+                70   ARAP-Password [RFC2869]
+                71   ARAP-Features [RFC2869]
+                72   ARAP-Zone-Access [RFC2869]
+                73   ARAP-Security [RFC2869]
+                74   ARAP-Security-Data [RFC2869]
+                75   Password-Retry [RFC2869]
+                76   Prompt [RFC2869]
+     X          77   Connect-Info [RFC2869]
+     X          78   Configuration-Token [RFC2869]
+     X          79   EAP-Message [RFC3579]
+     X          80   Message-Authenticator [RFC3579]
+     X          81   Tunnel-Private-Group-ID [RFC2868]
+     L3         82   Tunnel-Assignment-ID [RFC2868]
+     X          83   Tunnel-Preference [RFC2868]
+                84   ARAP-Challenge-Response [RFC2869]
+   802.1X        #   Attribute
+
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 26]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+   802.1X        #   Attribute
+     X          85   Acct-Interim-Interval [RFC2869]
+     X          86   Acct-Tunnel-Packets-Lost [RFC2867]
+     X          87   NAS-Port-Id [RFC2869]
+     L3         88   Framed-Pool [RFC2869]
+     L3         90   Tunnel-Client-Auth-ID [RFC2868]
+     L3         91   Tunnel-Server-Auth-ID [RFC2868]
+     X          95   NAS-IPv6-Address [RFC3162]
+                96   Framed-Interface-Id [RFC3162]
+     L3         97   Framed-IPv6-Prefix [RFC3162]
+     L3         98   Login-IPv6-Host [RFC3162]
+     L3         99   Framed-IPv6-Route [RFC3162]
+     L3        100   Framed-IPv6-Pool [RFC3162]
+     X         101   Error-Cause [RFC3576]
+   802.1X        #   Attribute
+
+   Key
+   ===
+   X         = May be used with IEEE 802.1X authentication
+   L3        = Implemented only by Authenticators with Layer 3
+               capabilities
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 27]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+9.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards- related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+10.  Acknowledgments
+
+   The authors would like to acknowledge Bob O'Hara of Airespace, David
+   Halasz of Cisco, Tim Moore, Sachin Seth and Ashwin Palekar of
+   Microsoft, Andrea Li, Albert Young and Dave Bagby of 3Com for
+   contributions to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 28]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+11.  Authors' Addresses
+
+   Paul Congdon
+   Hewlett Packard Company
+   HP ProCurve Networking
+   8000 Foothills Blvd, M/S 5662
+   Roseville, CA  95747
+
+   Phone: +1 916 785 5753
+   Fax:   +1 916 785 8478
+   EMail: paul_congdon@hp.com
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 706 6605
+   Fax:   +1 425 936 7329
+   EMail: bernarda@microsoft.com
+
+   Andrew Smith
+   Trapeze Networks
+   5753 W. Las Positas Blvd.
+   Pleasanton, CA 94588-4084
+
+   Fax: +1 415 345 1827
+   EMail: ah_smith@acm.org
+
+   John Roese
+   Enterasys
+
+   Phone: +1 603 337 1506
+   EMail: jjr@enterasys.com
+
+   Glen Zorn
+   Cisco Systems, Inc.
+   500 108th Avenue N.E., Suite 500
+   Bellevue, WA 98004
+
+   Phone: +1 425 438 8218
+   Fax:   +1 425 438 1848
+   EMail: gwz@cisco.com
+
+
+
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 29]
+
+RFC 3580                   IEEE 802.1X RADIUS             September 2003
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Congdon, et al.              Informational                     [Page 30]
+