added RADIUS, RADIUS-EAP and EAP-MD5 (CHAP) RFCs

diff --git a/doc/standards/rfc1994.txt b/doc/standards/rfc1994.txt
new file mode 100644 (file)
index 0000000..e4a553e
--- /dev/null
+++ b/doc/standards/rfc1994.txt
@@ -0,0 +1,732 @@
+
+
+
+
+
+
+Network Working Group                                         W. Simpson
+Request for Comments: 1994                                    DayDreamer
+Obsoletes: 1334                                              August 1996
+Category: Standards Track
+
+
+         PPP Challenge Handshake Authentication Protocol (CHAP)
+
+
+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
+
+   The Point-to-Point Protocol (PPP) [1] provides a standard method for
+   transporting multi-protocol datagrams over point-to-point links.
+
+   PPP also defines an extensible Link Control Protocol, which allows
+   negotiation of an Authentication Protocol for authenticating its peer
+   before allowing Network Layer protocols to transmit over the link.
+
+   This document defines a method for Authentication using PPP, which
+   uses a random Challenge, with a cryptographically hashed Response
+   which depends upon the Challenge and a secret key.
+
+Table of Contents
+
+     1.     Introduction ..........................................    1
+        1.1       Specification of Requirements ...................    1
+        1.2       Terminology .....................................    2
+     2.     Challenge-Handshake Authentication Protocol ...........    2
+        2.1       Advantages ......................................    3
+        2.2       Disadvantages ...................................    3
+        2.3       Design Requirements .............................    4
+     3.     Configuration Option Format ...........................    5
+     4.     Packet Format .........................................    6
+        4.1       Challenge and Response ..........................    7
+        4.2       Success and Failure .............................    9
+     SECURITY CONSIDERATIONS ......................................   10
+     ACKNOWLEDGEMENTS .............................................   11
+     REFERENCES ...................................................   12
+     CONTACTS .....................................................   12
+
+
+
+
+Simpson                                                         [Page i]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+1.  Introduction
+
+   In order to establish communications over a point-to-point link, each
+   end of the PPP link must first send LCP packets to configure the data
+   link during Link Establishment phase.  After the link has been
+   established, PPP provides for an optional Authentication phase before
+   proceeding to the Network-Layer Protocol phase.
+
+   By default, authentication is not mandatory.  If authentication of
+   the link is desired, an implementation MUST specify the
+   Authentication-Protocol Configuration Option during Link
+   Establishment phase.
+
+   These authentication protocols are intended for use primarily by
+   hosts and routers that connect to a PPP network server via switched
+   circuits or dial-up lines, but might be applied to dedicated links as
+   well.  The server can use the identification of the connecting host
+   or router in the selection of options for network layer negotiations.
+
+   This document defines a PPP authentication protocol.  The Link
+   Establishment and Authentication phases, and the Authentication-
+   Protocol Configuration Option, are defined in The Point-to-Point
+   Protocol (PPP) [1].
+
+
+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.
+
+
+
+
+Simpson                                                         [Page 1]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+1.2.  Terminology
+
+   This document frequently uses the following terms:
+
+   authenticator
+             The end of the link requiring the authentication.  The
+             authenticator specifies the authentication protocol to be
+             used in the Configure-Request during Link Establishment
+             phase.
+
+   peer      The other end of the point-to-point link; the end which is
+             being authenticated by the authenticator.
+
+   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.  Challenge-Handshake Authentication Protocol
+
+   The Challenge-Handshake Authentication Protocol (CHAP) is used to
+   periodically verify the identity of the peer using a 3-way handshake.
+   This is done upon initial link establishment, and MAY be repeated
+   anytime after the link has been established.
+
+   1.    After the Link Establishment phase is complete, the
+         authenticator sends a "challenge" message to the peer.
+
+   2.    The peer responds with a value calculated using a "one-way
+         hash" function.
+
+   3.    The authenticator checks the response against its own
+         calculation of the expected hash value.  If the values match,
+         the authentication is acknowledged; otherwise the connection
+         SHOULD be terminated.
+
+   4.    At random intervals, the authenticator sends a new challenge to
+         the peer, and repeats steps 1 to 3.
+
+
+
+
+
+
+
+
+Simpson                                                         [Page 2]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+2.1.  Advantages
+
+   CHAP provides protection against playback attack by the peer through
+   the use of an incrementally changing identifier and a variable
+   challenge value.  The use of repeated challenges is intended to limit
+   the time of exposure to any single attack.  The authenticator is in
+   control of the frequency and timing of the challenges.
+
+   This authentication method depends upon a "secret" known only to the
+   authenticator and that peer.  The secret is not sent over the link.
+
+   Although the authentication is only one-way, by negotiating CHAP in
+   both directions the same secret set may easily be used for mutual
+   authentication.
+
+   Since CHAP may be used to authenticate many different systems, name
+   fields may be used as an index to locate the proper secret in a large
+   table of secrets.  This also makes it possible to support more than
+   one name/secret pair per system, and to change the secret in use at
+   any time during the session.
+
+
+2.2.  Disadvantages
+
+   CHAP requires that the secret be available in plaintext form.
+   Irreversably encrypted password databases commonly available cannot
+   be used.
+
+   It is not as useful for large installations, since every possible
+   secret is maintained at both ends of the link.
+
+      Implementation Note: To avoid sending the secret over other links
+      in the network, it is recommended that the challenge and response
+      values be examined at a central server, rather than each network
+      access server.  Otherwise, the secret SHOULD be sent to such
+      servers in a reversably encrypted form.  Either case requires a
+      trusted relationship, which is outside the scope of this
+      specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson                                                         [Page 3]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+2.3.  Design Requirements
+
+   The CHAP algorithm requires that the length of the secret MUST be at
+   least 1 octet.  The secret SHOULD be at least as large and
+   unguessable as a well-chosen password.  It is preferred that the
+   secret be at least the length of the hash value for the hashing
+   algorithm chosen (16 octets for MD5).  This is to ensure a
+   sufficiently large range for the secret to provide protection against
+   exhaustive search attacks.
+
+   The one-way hash algorithm is chosen such that it is computationally
+   infeasible to determine the secret from the known challenge and
+   response values.
+
+   Each challenge value SHOULD be unique, since repetition of a
+   challenge 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 challenge SHOULD exhibit
+   global and temporal uniqueness.
+
+   Each challenge value SHOULD also be unpredictable, least an attacker
+   trick a peer into responding to a predicted future challenge, and
+   then use the response to masquerade as that peer to an authenticator.
+
+   Although protocols such as CHAP are incapable of protecting against
+   realtime active wiretapping attacks, generation of unique
+   unpredictable challenges can protect against a wide range of active
+   attacks.
+
+   A discussion of sources of uniqueness and probability of divergence
+   is included in the Magic-Number Configuration Option [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson                                                         [Page 4]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+3.  Configuration Option Format
+
+   A summary of the Authentication-Protocol Configuration Option format
+   to negotiate the Challenge-Handshake Authentication Protocol is shown
+   below.  The fields are transmitted from left to right.
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     Authentication-Protocol   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Algorithm   |
+   +-+-+-+-+-+-+-+-+
+
+   Type
+
+      3
+
+   Length
+
+      5
+
+   Authentication-Protocol
+
+      c223 (hex) for Challenge-Handshake Authentication Protocol.
+
+   Algorithm
+
+      The Algorithm field is one octet and indicates the authentication
+      method to be used.  Up-to-date values are specified in the most
+      recent "Assigned Numbers" [2].  One value is required to be
+      implemented:
+
+         5       CHAP with MD5 [3]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson                                                         [Page 5]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+4.  Packet Format
+
+   Exactly one Challenge-Handshake Authentication Protocol packet is
+   encapsulated in the Information field of a PPP Data Link Layer frame
+   where the protocol field indicates type hex c223 (Challenge-Handshake
+   Authentication Protocol).  A summary of the CHAP packet format is
+   shown below.  The fields are transmitted from left to right.
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |    Data ...
+   +-+-+-+-+
+
+   Code
+
+      The Code field is one octet and identifies the type of CHAP
+      packet.  CHAP Codes are assigned as follows:
+
+         1       Challenge
+         2       Response
+         3       Success
+         4       Failure
+
+   Identifier
+
+      The Identifier field is one octet and aids in matching challenges,
+      responses and replies.
+
+   Length
+
+      The Length field is two octets and indicates the length of the
+      CHAP packet including the Code, Identifier, Length and Data
+      fields.  Octets outside the range of the Length field should be
+      treated as Data Link Layer padding and should be ignored on
+      reception.
+
+   Data
+
+      The Data field is zero or more octets.  The format of the Data
+      field is determined by the Code field.
+
+
+
+
+
+
+
+
+
+
+Simpson                                                         [Page 6]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+4.1.  Challenge and Response
+
+   Description
+
+      The Challenge packet is used to begin the Challenge-Handshake
+      Authentication Protocol.  The authenticator MUST transmit a CHAP
+      packet with the Code field set to 1 (Challenge).  Additional
+      Challenge packets MUST be sent until a valid Response packet is
+      received, or an optional retry counter expires.
+
+      A Challenge packet MAY also be transmitted at any time during the
+      Network-Layer Protocol phase to ensure that the connection has not
+      been altered.
+
+      The peer SHOULD expect Challenge packets during the Authentication
+      phase and the Network-Layer Protocol phase.  Whenever a Challenge
+      packet is received, the peer MUST transmit a CHAP packet with the
+      Code field set to 2 (Response).
+
+      Whenever a Response packet is received, the authenticator compares
+      the Response Value with its own calculation of the expected value.
+      Based on this comparison, the authenticator MUST send a Success or
+      Failure packet (described below).
+
+         Implementation Notes: Because the Success might be lost, the
+         authenticator MUST allow repeated Response packets during the
+         Network-Layer Protocol phase after completing the
+         Authentication phase.  To prevent discovery of alternative
+         Names and Secrets, any Response packets received having the
+         current Challenge Identifier MUST return the same reply Code
+         previously returned for that specific Challenge (the message
+         portion MAY be different).  Any Response packets received
+         during any other phase MUST be silently discarded.
+
+         When the Failure is lost, and the authenticator terminates the
+         link, the LCP Terminate-Request and Terminate-Ack provide an
+         alternative indication that authentication failed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson                                                         [Page 7]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+   A summary of the Challenge and Response packet format is shown below.
+   The fields are transmitted from left to right.
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Value-Size   |  Value ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Name ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Code
+
+      1 for Challenge;
+
+      2 for Response.
+
+   Identifier
+
+      The Identifier field is one octet.  The Identifier field MUST be
+      changed each time a Challenge is sent.
+
+      The Response Identifier MUST be copied from the Identifier field
+      of the Challenge which caused the Response.
+
+   Value-Size
+
+      This field is one octet and indicates the length of the Value
+      field.
+
+   Value
+
+      The Value field is one or more octets.  The most significant octet
+      is transmitted first.
+
+      The Challenge Value is a variable stream of octets.  The
+      importance of the uniqueness of the Challenge Value and its
+      relationship to the secret is described above.  The Challenge
+      Value MUST be changed each time a Challenge is sent.  The length
+      of the Challenge Value depends upon the method used to generate
+      the octets, and is independent of the hash algorithm used.
+
+      The Response Value is the one-way hash calculated over a stream of
+      octets consisting of the Identifier, followed by (concatenated
+      with) the "secret", followed by (concatenated with) the Challenge
+      Value.  The length of the Response Value depends upon the hash
+      algorithm used (16 octets for MD5).
+
+
+
+
+Simpson                                                         [Page 8]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+   Name
+
+      The Name field is one or more octets representing the
+      identification of the system transmitting the packet.  There are
+      no limitations on the content of this field.  For example, it MAY
+      contain ASCII character strings or globally unique identifiers in
+      ASN.1 syntax.  The Name should not be NUL or CR/LF terminated.
+      The size is determined from the Length field.
+
+
+4.2.  Success and Failure
+
+   Description
+
+      If the Value received in a Response is equal to the expected
+      value, then the implementation MUST transmit a CHAP packet with
+      the Code field set to 3 (Success).
+
+      If the Value received in a Response is not equal to the expected
+      value, then the implementation MUST transmit a CHAP packet with
+      the Code field set to 4 (Failure), and SHOULD take action to
+      terminate the link.
+
+   A summary of the Success and Failure packet format is shown below.
+   The fields are transmitted from left to right.
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Code      |  Identifier   |            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Message  ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Code
+
+      3 for Success;
+
+      4 for Failure.
+
+   Identifier
+
+      The Identifier field is one octet and aids in matching requests
+      and replies.  The Identifier field MUST be copied from the
+      Identifier field of the Response which caused this reply.
+
+
+
+
+
+
+
+
+Simpson                                                         [Page 9]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+   Message
+
+      The Message field is zero 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 32 through
+      126 decimal.  Mechanisms for extension to other character sets are
+      the topic of future research.  The size is determined from the
+      Length field.
+
+
+
+Security Considerations
+
+   Security issues are the primary topic of this RFC.
+
+   The interaction of the authentication protocols within PPP are highly
+   implementation dependent.  This is indicated by the use of SHOULD
+   throughout the document.
+
+   For example, upon failure of authentication, some implementations do
+   not terminate the link.  Instead, the implementation limits the kind
+   of traffic in the Network-Layer Protocols to a filtered subset, which
+   in turn allows the user opportunity to update secrets or send mail to
+   the network administrator indicating a problem.
+
+   There is no provision for re-tries of failed authentication.
+   However, the LCP state machine can renegotiate the authentication
+   protocol at any time, thus allowing a new attempt.  It is recommended
+   that any counters used for authentication failure not be reset until
+   after successful authentication, or subsequent termination of the
+   failed link.
+
+   There is no requirement that authentication be full duplex or that
+   the same protocol be used in both directions.  It is perfectly
+   acceptable for different protocols to be used in each direction.
+   This will, of course, depend on the specific protocols negotiated.
+
+   The secret SHOULD NOT be the same in both directions.  This allows an
+   attacker to replay the peer's challenge, accept the computed
+   response, and use that response to authenticate.
+
+   In practice, within or associated with each PPP 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 (such as PAP rather than CHAP).  If the same
+
+
+
+Simpson                                                        [Page 10]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+   secret was used, PAP would reveal the secret to be used later with
+   CHAP.
+
+   Instead, for each user name 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.  Such a mechanism is outside the scope of this
+   specification.
+
+
+Acknowledgements
+
+   David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge
+   handshake at SDC when designing one of the protocols for a "secure"
+   network in the mid-1970s.  Tom Bearson built a prototype Sytek
+   product ("Poloneous"?) on the challenge-response notion in the 1982-
+   83 timeframe.  Another variant is documented in the various IBM SNA
+   manuals.  Yet another variant was implemented by Karl Auerbach in the
+   Telebit NetBlazer circa 1991.
+
+   Kim Toms and Barney Wolff provided useful critiques of earlier
+   versions of this document.
+
+   Special thanks to Dave Balenson, Steve Crocker, James Galvin, and
+   Steve Kent, for their extensive explanations and suggestions.  Now,
+   if only we could get them to agree with each other.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson                                                        [Page 11]
+\f
+RFC 1994                        PPP CHAP                     August 1996
+
+
+References
+
+   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+         51, RFC 1661, DayDreamer, July 1994.
+
+   [2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+         1700, USC/Information Sciences Institute, October 1994.
+
+   [3]   Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
+         MIT Laboratory for Computer Science and RSA Data Security,
+         Inc., RFC 1321, April 1992.
+
+
+
+Contacts
+
+   Comments should be submitted to the ietf-ppp@merit.edu mailing list.
+
+   This document was reviewed by the Point-to-Point Protocol Working
+   Group of the Internet Engineering Task Force (IETF).  The working
+   group can be contacted via the current chair:
+
+      Karl Fox
+      Ascend Communications
+      3518 Riverside Drive, Suite 101
+      Columbus, Ohio 43221
+
+          karl@MorningStar.com
+          karl@Ascend.com
+
+
+   Questions about this memo can also be directed to:
+
+      William Allen Simpson
+      DayDreamer
+      Computer Systems Consulting Services
+      1384 Fontaine
+      Madison Heights, Michigan  48071
+
+          wsimpson@UMich.edu
+          wsimpson@GreenDragon.com (preferred)
+
+
+
+
+
+
+
+
+
+
+Simpson                                                        [Page 12]
+\f
+

diff --git a/doc/standards/rfc2865.txt b/doc/standards/rfc2865.txt
new file mode 100644 (file)
index 0000000..10ec231
--- /dev/null
+++ b/doc/standards/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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f

diff --git a/doc/standards/rfc3579.txt b/doc/standards/rfc3579.txt
new file mode 100644 (file)
index 0000000..5eb72c7
--- /dev/null
+++ b/doc/standards/rfc3579.txt
@@ -0,0 +1,2579 @@
+
+
+
+
+
+
+Network Working Group                                           B. Aboba
+Request for Comments: 3579                                     Microsoft
+Updates: 2869                                                 P. Calhoun
+Category: Informational                                        Airespace
+                                                          September 2003
+
+
+          RADIUS (Remote Authentication Dial In User Service)
+          Support For Extensible Authentication Protocol (EAP)
+
+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 defines Remote Authentication Dial In User Service
+   (RADIUS) support for the Extensible Authentication Protocol (EAP), an
+   authentication framework which supports multiple authentication
+   mechanisms.  In the proposed scheme, the Network Access Server (NAS)
+   forwards EAP packets to and from the RADIUS server, encapsulated
+   within EAP-Message attributes.  This has the advantage of allowing
+   the NAS to support any EAP authentication method, without the need
+   for method-specific code, which resides on the RADIUS server.  While
+   EAP was originally developed for use with PPP, it is now also in use
+   with IEEE 802.
+
+   This document updates RFC 2869.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                      [Page 1]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.1.  Specification of Requirements. . . . . . . . . . . . . .  3
+       1.2.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  RADIUS Support for EAP . . . . . . . . . . . . . . . . . . . .  4
+       2.1.  Protocol Overview. . . . . . . . . . . . . . . . . . . .  5
+       2.2.  Invalid Packets. . . . . . . . . . . . . . . . . . . . .  9
+       2.3.  Retransmission . . . . . . . . . . . . . . . . . . . . . 10
+       2.4.  Fragmentation. . . . . . . . . . . . . . . . . . . . . . 10
+       2.5.  Alternative uses . . . . . . . . . . . . . . . . . . . . 11
+       2.6.  Usage Guidelines . . . . . . . . . . . . . . . . . . . . 11
+   3.  Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+       3.1.  EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 15
+       3.2.  Message-Authenticator. . . . . . . . . . . . . . . . . . 16
+       3.3.  Table of Attributes. . . . . . . . . . . . . . . . . . . 18
+   4.  Security Considerations. . . . . . . . . . . . . . . . . . . . 19
+       4.1.  Security Requirements. . . . . . . . . . . . . . . . . . 19
+       4.2.  Security Protocol. . . . . . . . . . . . . . . . . . . . 20
+       4.3.  Security Issues. . . . . . . . . . . . . . . . . . . . . 22
+   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 30
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
+       6.1.  Normative References . . . . . . . . . . . . . . . . . . 30
+       6.2.  Informative References . . . . . . . . . . . . . . . . . 32
+   Appendix A - Examples. . . . . . . . . . . . . . . . . . . . . . . 34
+   Appendix B - Change Log. . . . . . . . . . . . . . . . . . . . . . 43
+   Intellectual Property Statement. . . . . . . . . . . . . . . . . . 44
+   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 44
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 46
+
+1.  Introduction
+
+   The Remote Authentication Dial In User Service (RADIUS) is an
+   authentication, authorization and accounting protocol used to control
+   network access.  RADIUS authentication and authorization is specified
+   in [RFC2865], and RADIUS accounting is specified in [RFC2866]; RADIUS
+   over IPv6 is specified in [RFC3162].
+
+   The Extensible Authentication Protocol (EAP), defined in [RFC2284],
+   is an authentication framework which supports multiple authentication
+   mechanisms.  EAP may be used on dedicated links, switched circuits,
+   and wired as well as wireless links.
+
+   To date, EAP has been implemented with hosts and routers that connect
+   via switched circuits or dial-up lines using PPP [RFC1661].  It has
+   also been implemented with bridges supporting [IEEE802].  EAP
+   encapsulation on IEEE 802 wired media is described in [IEEE8021X].
+
+
+
+Aboba & Calhoun              Informational                      [Page 2]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   RADIUS attributes are comprised of variable length Type-Length-Value
+   3-tuples.  New attribute values can be added without disturbing
+   existing implementations of the protocol.  This specification
+   describes RADIUS attributes supporting the Extensible Authentication
+   Protocol (EAP): EAP-Message and Message-Authenticator.  These
+   attributes now have extensive field experience.  The purpose of this
+   document is to provide clarification and resolve interoperability
+   issues.
+
+   As noted in [RFC2865], a Network Access Server (NAS) that does not
+   implement a given service MUST NOT implement the RADIUS attributes
+   for that service.  This implies that a NAS that is unable to offer
+   EAP service MUST NOT implement the RADIUS attributes for EAP.  A NAS
+   MUST treat a RADIUS Access-Accept requesting an unavailable service
+   as an Access-Reject instead.
+
+1.1.  Specification of Requirements
+
+   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].
+
+1.2.  Terminology
+
+   This document frequently uses the following terms:
+
+   authenticator
+             The end of the link requiring the authentication.  Also
+             known as the Network Access Server (NAS) or RADIUS client.
+             Within IEEE 802.1X terminology, the term Authenticator is
+             used.
+
+   peer      The other end of the point-to-point link (PPP),
+             point-to-point LAN segment (IEEE 802.1X) or wireless link,
+             which is being authenticated by the authenticator.  In IEEE
+             802.1X, this end is known as the Supplicant.
+
+   authentication server
+             An authentication server is an entity that provides an
+             authentication service to an authenticator (NAS).  This
+             service verifies from the credentials provided by the peer,
+             the claim of identity made by the peer; it also may provide
+             credentials allowing the peer to verify the identity of the
+             authentication server.  Within this document it is assumed
+             that the NAS operates as a pass-through, forwarding EAP
+             packets between the RADIUS server and the EAP peer.
+
+
+
+Aboba & Calhoun              Informational                      [Page 3]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+             Therefore the RADIUS server operates as an authentication
+             server.
+
+   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.
+
+   displayable message
+             This is interpreted to be a human readable string of
+             characters, and MUST NOT affect operation of the protocol.
+             The message encoding MUST follow the UTF-8 transformation
+             format [RFC2279].
+
+   Network Access Server (NAS)
+             The device providing access to the network.  Also known as
+             the Authenticator (IEEE 802.1X or EAP terminology) or
+             RADIUS client.
+
+   service   The NAS provides a service to the user, such as IEEE 802 or
+             PPP.
+
+   session   Each service provided by the NAS to a peer 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
+             peer may have multiple sessions in parallel or series if
+             the NAS supports that, with each session generating a
+             separate start and stop accounting record.
+
+2.  RADIUS Support for EAP
+
+   The Extensible Authentication Protocol (EAP), described in [RFC2284],
+   provides a standard mechanism for support of additional
+   authentication methods without the NAS to be upgraded to support each
+   new method.  Through the use of EAP, support for a number of
+   authentication schemes may be added, including smart cards, Kerberos
+   [RFC1510], Public Key [RFC2716], One Time Passwords [RFC2284], and
+   others.
+
+   One of the advantages of the EAP architecture is its flexibility.
+   EAP is used to select a specific authentication mechanism.  Rather
+   than requiring the NAS to be updated to support each new
+   authentication method, EAP permits the use of an authentication
+   server implementing authentication methods, with the NAS acting as a
+   pass-through for some or all methods and peers.
+
+
+
+Aboba & Calhoun              Informational                      [Page 4]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   A NAS MAY authenticate local peers while at the same time acting as a
+   pass-through for non-local peers and authentication methods it does
+   not implement locally.  A NAS implementing this specification is not
+   required to use RADIUS to authenticate every peer.  However, once the
+   NAS begins acting as a pass-through for a particular session, it can
+   no longer perform local authentication for that session.
+
+   In order to support 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.
+
+2.1.  Protocol Overview
+
+   In RADIUS/EAP, RADIUS is used to shuttle RADIUS-encapsulated EAP
+   Packets between the NAS and an authentication server.
+
+   The authenticating peer and the NAS begin the EAP conversation by
+   negotiating use of EAP.  Once EAP has been negotiated, the NAS SHOULD
+   send an initial EAP-Request message to the authenticating peer.  This
+   will typically be an EAP-Request/Identity, although it could be an
+   EAP-Request for an authentication method (Types 4 and greater).  A
+   NAS MAY be configured to initiate with a default authentication
+   method.  This is useful in cases where the identity is determined by
+   another means (such as Called-Station-Id, Calling-Station-Id and/or
+   Originating-Line-Info); where a single authentication method is
+   required, which includes its own identity exchange; where identity
+   hiding is desired, so that the identity is not requested until after
+   a protected channel has been set up.
+
+   The peer replies with an EAP-Response.  The NAS MAY determine from
+   the Response that it should proceed with local authentication.
+   Alternatively, the NAS MAY act as a pass-through, encapsulating the
+   EAP-Response within EAP-Message attribute(s) sent to the RADIUS
+   server within a RADIUS Access-Request packet.  If the NAS sends an
+   EAP-Request/Identity message as the initial packet, the peer responds
+   with an EAP-Response/Identity.  The NAS may determine that the peer
+   is local and proceed with local authentication.  If no match is found
+   against the list of local users, the NAS encapsulates the
+   EAP-Response/Identity message within an EAP-Message attribute,
+   enclosed within an Access-Request packet.
+
+   On receiving a valid Access-Request packet containing EAP-Message
+   attribute(s), a RADIUS server compliant with this specification and
+   wishing to authenticate with EAP MUST respond with an
+   Access-Challenge packet containing EAP-Message attribute(s).  If the
+   RADIUS server does not support EAP or does not wish to authenticate
+   with EAP, it MUST respond with an Access-Reject.
+
+
+
+Aboba & Calhoun              Informational                      [Page 5]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   EAP-Message attribute(s) encapsulate a single EAP packet which the
+   NAS decapsulates and passes on to the authenticating peer.  The peer
+   then responds with an EAP-Response packet, which the NAS encapsulates
+   within an Access-Request containing EAP-Message attribute(s).  EAP is
+   a 'lock step' protocol, so that other than the initial Request, a new
+   Request cannot be sent prior to receiving a valid Response.
+
+   The conversation continues until either a RADIUS Access-Reject or
+   Access-Accept packet is received from the RADIUS server.  Reception
+   of a RADIUS Access-Reject packet MUST result in the NAS denying
+   access to the authenticating peer.  A RADIUS Access-Accept packet
+   successfully ends the authentication phase.  The NAS MUST NOT
+   "manufacture" a Success or Failure packet as the result of a timeout.
+   After a suitable number of timeouts have elapsed, the NAS SHOULD
+   instead end the EAP conversation.
+
+   Using RADIUS, the NAS can act as a pass-through for an EAP
+   conversation between the peer and authentication server, without
+   needing to implement the EAP method used between them.  Where the NAS
+   initiates the conversation by sending an EAP-Request for an
+   authentication method, it may not be required that the NAS fully
+   implement the EAP method reflected in the initial EAP-Request.
+   Depending on the initial method, it may be sufficient for the NAS to
+   be configured with the initial packet to be sent to the peer, and for
+   the NAS to act as a pass-through for subsequent messages.  Note that
+   since the NAS only encapsulates the EAP-Response in its initial
+   Access-Request, the initial EAP-Request within the authentication
+   method is not available to the RADIUS server.  For the RADIUS server
+   to be able to continue the conversation, either the initial
+   EAP-Request is vestigial, so that the RADIUS server need not be aware
+   of it, or the relevant information from the initial EAP-Request (such
+   as a nonce) is reflected in the initial EAP-Response, so that the
+   RADIUS server can obtain it without having received the initial
+   EAP-Request.
+
+   Where the initial EAP-Request sent by the NAS is for an
+   authentication Type (4 or greater), the peer MAY respond with a Nak
+   indicating that it would prefer another authentication method that is
+   not implemented locally.  In this case, the NAS SHOULD send
+   Access-Request encapsulating the received EAP-Response/Nak.  This
+   provides the RADIUS server with a hint about the authentication
+   method(s) preferred by the peer, although it does not provide
+   information on the Type of the original Request.  It also provides
+   the server with the Identifier used in the initial EAP-Request, so
+   that Identifier conflicts can be avoided.
+
+
+
+
+
+
+Aboba & Calhoun              Informational                      [Page 6]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   In order to evaluate whether the alternatives preferred by the
+   authenticating peer are allowed, the RADIUS server will typically
+   respond with an Access-Challenge containing EAP-Message attribute(s)
+   encapsulating an EAP-Request/Identity (Type 1).  This allows the
+   RADIUS server to determine the peer identity, so as to be able to
+   retrieve the associated authentication policy.  Alternatively, an
+   EAP-Request for an authentication method (Type 4 or greater) could be
+   sent.  Since the RADIUS server may not be aware of the Type of the
+   initial EAP-Request, it is possible for the RADIUS server to choose
+   an unacceptable method, and for the peer to respond with another Nak.
+
+   In order to permit non-EAP aware RADIUS proxies to forward the
+   Access-Request packet, if the NAS initially sends an
+   EAP-Request/Identity message to the peer, the NAS MUST copy the
+   contents of the Type-Data field of the EAP-Response/Identity received
+   from the peer into the User-Name attribute and MUST include the
+   Type-Data field of the EAP-Response/Identity in the User-Name
+   attribute in every subsequent Access-Request.  Since RADIUS proxies
+   are assumed to act as a pass-through, they cannot be expected to
+   parse an EAP-Response/Identity encapsulated within EAP-Message
+   attribute(s).  If the NAS initially sends an EAP-Request for an
+   authentication method, and the peer identity cannot be determined
+   from the EAP-Response, then the User-Name attribute SHOULD be
+   determined by another means.  As noted in [RFC2865] Section 5.6, it
+   is recommended that Access-Requests use the value of the
+   Calling-Station-Id as the value of the User-Name attribute.
+
+   Having the NAS send the initial EAP-Request packet has a number of
+   advantages:
+
+   [1]  It saves a round trip between the NAS and RADIUS server.
+
+   [2]  An Access-Request is only sent to the RADIUS server if the
+        authenticating peer sends an EAP-Response, confirming that it
+        supports EAP.  In situations where peers may be EAP unaware,
+        initiating a RADIUS Access-Request on a "carrier sense" or
+        "media up" indication may result in many authentication
+        exchanges that cannot complete successfully.  For example, on
+        wired networks [IEEE8021X] Supplicants typically do not initiate
+        the 802.1X conversation with an EAPOL-Start.  Therefore an IEEE
+        802.1X-enabled bridge may not be able to determine whether the
+        peer supports EAP until it receives a Response to the initial
+        EAP-Request.
+
+   [3]  It allows some peers to be authenticated locally.
+
+
+
+
+
+
+Aboba & Calhoun              Informational                      [Page 7]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   Although having the NAS send the initial EAP-Request packet has
+   substantial advantages, this technique cannot be universally
+   employed.  There are circumstances in which the peer identity is
+   already known (such as when authentication and accounting is handled
+   based on Called-Station-Id, Calling-Station-Id and/or
+   Originating-Line-Info), but where the appropriate EAP method may vary
+   based on that identity.
+
+   Rather than sending an initial EAP-Request packet to the
+   authenticating peer, on detecting the presence of the peer, the NAS
+   MAY send an Access-Request packet to the RADIUS server containing an
+   EAP-Message attribute signifying EAP-Start.  The RADIUS server will
+   typically respond with an Access-Challenge containing EAP-Message
+   attribute(s) encapsulating an EAP-Request/Identity (Type 1).
+   However, an EAP-Request for an authentication method (Type 4 or
+   greater) can also be sent by the server.
+
+   EAP-Start is indicated by sending an EAP-Message attribute with a
+   length of 2 (no data).  The Calling-Station-Id SHOULD be included in
+   the User-Name attribute.  This may result in a RADIUS Access-Request
+   being sent by the NAS to the RADIUS server without first confirming
+   that the peer supports EAP.  Since this technique can result in a
+   large number of uncompleted RADIUS conversations, in situations where
+   EAP unaware peers are common, or where peer support for EAP cannot be
+   determined on initial contact (e.g. [IEEE8021X] Supplicants not
+   initiating the conversation with an EAPOL-Start) it SHOULD NOT be
+   employed by default.
+
+   For proxied RADIUS requests, there are two methods of processing.  If
+   the domain is determined based on the Calling-Station-Id,
+   Called-Station-Id and/or Originating-Line-Info, the RADIUS server may
+   proxy the initial RADIUS Access-Request/EAP-Start.  If the realm is
+   determined based on the peer identity, the local RADIUS server MUST
+   respond with a RADIUS Access-Challenge including an EAP-Message
+   attribute encapsulating an EAP-Request/Identity packet.  The response
+   from the authenticating peer SHOULD be proxied to the final
+   authentication server.
+
+   If an Access-Request is sent to a RADIUS server which does not
+   support the EAP-Message attribute, then an Access-Reject MUST be sent
+   in response.  On receiving an Access-Reject, the NAS MUST deny access
+   to the authenticating peer.
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                      [Page 8]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+2.2.  Invalid Packets
+
+   While acting as a pass-through, the NAS MUST validate the EAP header
+   fields (Code, Identifier, Length) prior to forwarding an EAP packet
+   to or from the RADIUS server.  On receiving an EAP packet from the
+   peer, the NAS checks the Code (2) and Length fields, and matches the
+   Identifier value against the current Identifier, supplied by the
+   RADIUS server in the most recently validated EAP-Request.  On
+   receiving an EAP packet from the RADIUS server (encapsulated within
+   an Access-Challenge), the NAS checks the Code (1) and Length fields,
+   then updates the current Identifier value.  Pending EAP Responses
+   that do not match the current Identifier value are silently discarded
+   by the NAS.
+
+   Since EAP method fields (Type, Type-Data) are typically not validated
+   by a NAS operating as a pass-through, despite these checks it is
+   possible for a NAS to forward an invalid EAP packet to or from the
+   RADIUS server.  A RADIUS server receiving EAP-Message attribute(s) it
+   does not understand SHOULD make the determination of whether the
+   error is fatal or non-fatal based on the EAP Type.  A RADIUS server
+   determining that a fatal error has occurred MUST send an
+   Access-Reject containing an EAP-Message attribute encapsulating
+   EAP-Failure.
+
+   A RADIUS server determining that a non-fatal error has occurred MAY
+   send an Access-Challenge to the NAS including EAP-Message
+   attribute(s) as well as an Error-Cause attribute [RFC3576] with value
+   202 (decimal), "Invalid EAP Packet (Ignored)".  The Access-Challenge
+   SHOULD encapsulate within EAP-Message attribute(s) the most recently
+   sent EAP-Request packet (including the same Identifier value).  On
+   receiving such an Access-Challenge, a NAS implementing previous
+   versions of this specification will decapsulate the EAP-Request and
+   send it to the peer, which will retransmit the EAP-Response.
+
+   A NAS compliant with this specification, on receiving an
+   Access-Challenge with an Error-Cause attribute of value 202 (decimal)
+   SHOULD discard the EAP-Response packet most recently transmitted to
+   the RADIUS server and check whether additional EAP-Response packets
+   have been received matching the current Identifier value.  If so, a
+   new EAP-Response packet, if available, MUST be sent to the RADIUS
+   server within an Access-Request, and the EAP-Message attribute(s)
+   included within the Access-Challenge are silently discarded.  If no
+   EAP-Response packet is available, then the EAP-Request encapsulated
+   within the Access-Challenge is sent to the peer, and the
+   retransmission timer is reset.
+
+
+
+
+
+
+Aboba & Calhoun              Informational                      [Page 9]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   In order to provide protection against Denial of Service (DoS)
+   attacks, it is advisable for the NAS to allocate a finite buffer for
+   EAP packets received from the peer, and to discard packets according
+   to an appropriate policy once that buffer has been exceeded.  Also,
+   the RADIUS server is advised to permit only a modest number of
+   invalid EAP packets within a single session, prior to terminating the
+   session with an Access-Reject.  By default a value of 5 invalid EAP
+   packets is recommended.
+
+2.3.  Retransmission
+
+   As noted in [RFC2284], if an EAP packet is lost in transit between
+   the authenticating peer and the NAS (or vice versa), the NAS will
+   retransmit.
+
+   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 attribute within the Access-Challenge packet.
+
+   If Session-Timeout is present in an Access-Challenge packet that also
+   contains an EAP-Message, the value of the Session-Timeout is used to
+   set the EAP retransmission timer for that EAP Request, and that
+   Request alone.  Once the EAP-Request has been sent, the NAS sets the
+   retransmission timer, and if it expires without having received an
+   EAP-Response corresponding to the Request, then the EAP-Request is
+   retransmitted.
+
+2.4.  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.  A RADIUS server having received a
+   Framed-MTU attribute in an Access-Request packet MUST NOT send any
+   subsequent packet in this EAP conversation containing EAP-Message
+   attributes whose values, when concatenated, exceed the length
+   specified by the Framed-MTU value, taking the link type (specified by
+   the NAS-Port-Type attribute) into account.  For example, as noted in
+   [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE 802.11, the
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 10]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   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.
+
+2.5.  Alternative Uses
+
+   Currently the conversation between security servers and the RADIUS
+   server is often proprietary because of lack of standardization.  In
+   order to increase standardization and provide interoperability
+   between RADIUS vendors and  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 security
+   server instead.
+
+   In the case where RADIUS-encapsulated EAP is used in a conversation
+   between a RADIUS server and a security server, the security server
+   will typically return an Access-Accept 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 message to the NAS.
+
+2.6.  Usage Guidelines
+
+2.6.1.  Identifier Space
+
+   In EAP, each session has its own unique Identifier space.  RADIUS
+   server implementations MUST be able to distinguish between EAP
+   packets with the same Identifier existing within distinct sessions,
+   originating on the same NAS.  For this purpose, sessions can be
+   distinguished based on NAS and session identification attributes.
+   NAS identification attributes include NAS-Identifier,
+   NAS-IPv6-Address and NAS-IPv4-Address.  Session identification
+   attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id,
+   Called-Station-Id, Calling-Station-Id and Originating-Line-Info.
+
+2.6.2.  Role Reversal
+
+   Since EAP is a peer-to-peer protocol, an independent and simultaneous
+   authentication may take place in the reverse direction.  Both peers
+   may act as authenticators and authenticatees at the same time.
+
+   However, role reversal is not supported by this specification.  A
+   RADIUS server MUST respond to an Access-Request encapsulating an
+   EAP-Request with an Access-Reject.  In order to avoid retransmissions
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 11]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   by the peer, the Access-Reject SHOULD include an EAP-Response/Nak
+   packet indicating no preferred method, encapsulated within
+   EAP-Message attribute(s).
+
+2.6.3.  Conflicting Messages
+
+   The NAS MUST make its access control decision based solely on the
+   RADIUS Packet Type (Access-Accept/Access-Reject).  The access control
+   decision MUST NOT be based on the contents of the EAP packet
+   encapsulated in one or more EAP-Message attributes, if present.
+
+   Access-Accept packets SHOULD have only one EAP-Message attribute in
+   them, containing EAP Success; similarly, Access-Reject packets SHOULD
+   have only one EAP-Message attribute in them, containing EAP Failure.
+
+   Where the encapsulated EAP packet does not match the result implied
+   by the RADIUS Packet Type, the combination is likely to cause
+   confusion, because the NAS and peer will arrive at different
+   conclusions as to the outcome of the authentication.
+
+   For example, if the NAS receives an Access-Reject with an
+   encapsulated EAP Success, it will not grant access to the peer.
+   However, on receiving the EAP Success, the peer will be lead to
+   believe that it authenticated successfully.
+
+   If the NAS receives an Access-Accept with an encapsulated EAP
+   Failure, it will grant access to the peer.  However, on receiving an
+   EAP Failure, the peer will be lead to believe that it failed
+   authentication.  If no EAP-Message attribute is included within an
+   Access-Accept or Access-Reject, then the peer may not be informed as
+   to the outcome of the authentication, while the NAS will take action
+   to allow or deny access.
+
+   As described in [RFC2284], the EAP Success and Failure packets are
+   not acknowledged, and these packets terminate the EAP conversation.
+   As a result, if these packets are encapsulated within an
+   Access-Challenge, no response will be received, and therefore the NAS
+   will send no further Access-Requests to the RADIUS server for the
+   session.  As a result, the RADIUS server will not indicate to the NAS
+   whether to allow or deny access, while the peer will be informed as
+   to the outcome of the authentication.
+
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 12]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   To avoid these conflicts, the following combinations SHOULD NOT be
+   sent by a RADIUS server:
+
+      Access-Accept/EAP-Message/EAP Failure
+      Access-Accept/no EAP-Message attribute
+      Access-Accept/EAP-Start
+      Access-Reject/EAP-Message/EAP Success
+      Access-Reject/no EAP-Message attribute
+      Access-Reject/EAP-Start
+      Access-Challenge/EAP-Message/EAP Success
+      Access-Challenge/EAP-Message/EAP Failure
+      Access-Challenge/no EAP-Message attribute
+      Access-Challenge/EAP-Start
+
+   Since the responsibility for avoiding conflicts lies with the RADIUS
+   server, the NAS MUST NOT "manufacture" EAP packets in order to
+   correct contradictory messages that it receives.  This behavior,
+   originally mandated within [IEEE8021X], will be deprecated in the
+   future.
+
+2.6.4.  Priority
+
+   A RADIUS Access-Accept or Access-Reject packet may contain EAP-
+   Message attribute(s). In order to ensure the correct processing of
+   RADIUS packets, the NAS MUST first process the attributes, including
+   the EAP-Message attribute(s), prior to processing the Accept/Reject
+   indication.
+
+2.6.5.  Displayable Messages
+
+   The Reply-Message attribute, defined in [RFC2865], Section 5.18,
+   indicates text which may be displayed to the peer.  This is similar
+   in concept to EAP Notification, defined in [RFC2284].  When sending a
+   displayable message to a NAS during an EAP conversation, the RADIUS
+   server MUST encapsulate displayable messages within
+   EAP-Message/EAP-Request/Notification attribute(s).  Reply-Message
+   attribute(s) MUST NOT be included in any RADIUS message containing an
+   EAP-Message attribute.  An EAP-Message/EAP-Request/Notification
+   SHOULD NOT be included within an Access-Accept or Access-Reject
+   packet.
+
+   In some existing implementations, a NAS receiving Reply-Message
+   attribute(s) copies the Text field(s) into the Type-Data field of an
+   EAP-Request/Notification packet, fills in the Identifier field, and
+   sends this to the peer.  However, several issues arise from this:
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 13]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   [1]  Unexpected Responses.  On receiving an EAP-Request/Notification,
+        the peer will send an EAP-Response/Notification, and the NAS
+        will pass this on to the RADIUS server, encapsulated within
+        EAP-Message attribute(s).  However, the RADIUS server may not be
+        expecting an Access-Request containing an
+        EAP-Message/EAP-Response/Notification attribute.
+
+        For example, consider what happens when a Reply-Message is
+        included within an Access-Accept or Access-Reject packet with no
+        EAP-Message attribute(s) present.  If the value of the
+        Reply-Message attribute is copied into the Type-Data of an
+        EAP-Request/Notification and sent to the peer, this will result
+        in an Access-Request containing an
+        EAP-Message/EAP-Response/Notification attribute being sent by
+        the NAS to the RADIUS server.  Since an Access-Accept or
+        Access-Reject packet terminates the RADIUS conversation, such an
+        Access-Request would not be expected, and could be interpreted
+        as the start of another conversation.
+
+   [2]  Identifier conflicts.  While the EAP-Request/Notification is an
+        EAP packet containing an Identifier field, the Reply-Message
+        attribute does not contain an Identifier field.  As a result, a
+        NAS receiving a Reply-Message attribute and wishing to translate
+        this to an EAP-Request/Notification will need to choose an
+        Identifier value.  It is possible that the chosen Identifier
+        value will conflict with a value chosen by the RADIUS server for
+        another packet within the EAP conversation, potentially causing
+        confusion between a new packet and a retransmission.
+
+   To avoid these problems, a NAS receiving a Reply-Message attribute
+   from the RADIUS server SHOULD silently discard the attribute, rather
+   than attempting to translate it to an EAP Notification Request.
+
+3.  Attributes
+
+   The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS
+   in Access-Request packets, and either NAS-Identifier, NAS-IP-Address
+   or NAS-IPv6-Address attributes 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
+   difficult to manage.  The User-Name attribute within the Access-
+   Accept packet need not be the same as the User-Name attribute in the
+   Access-Request.
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 14]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+3.1.  EAP-Message
+
+   Description
+
+      This attribute encapsulates EAP [RFC2284] packets so as to allow
+      the NAS to authenticate peers via EAP without having to understand
+      the EAP method it is passing through.
+
+      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-Message attributes 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.  The RADIUS server can return EAP-Message attributes in
+      Access-Challenge, Access-Accept and Access-Reject packets.
+
+      When RADIUS is used to enable EAP authentication, Access-Request,
+      Access-Challenge, Access-Accept, and Access-Reject packets SHOULD
+      contain one or more EAP-Message attributes.  Where more than one
+      EAP-Message attribute is included, it is assumed that the
+      attributes are to be concatenated to form a single EAP packet.
+
+      Multiple EAP packets MUST NOT be encoded within EAP-Message
+      attributes contained within a single Access-Challenge,
+      Access-Accept, Access-Reject or Access-Request packet.
+
+      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 EAP Success or
+      EAP Failure packets) it is necessary that RADIUS provide
+      per-packet authentication and integrity protection.
+
+      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 EAP-Message attribute(s) without
+      a Message-Authenticator attribute SHOULD be silently discarded by
+      the RADIUS server.  A RADIUS server supporting the EAP-Message
+      attribute MUST calculate the correct value of the
+      Message-Authenticator and MUST silently discard the packet if it
+      does not match the value sent.  A RADIUS server not supporting the
+      EAP-Message attribute MUST return an Access-Reject if it receives
+      an Access-Request containing an EAP-Message attribute.
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 15]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+      Access-Challenge, Access-Accept, or Access-Reject packets
+      including EAP-Message attribute(s) without a Message-Authenticator
+      attribute SHOULD be silently discarded by the NAS.  A NAS
+      supporting the EAP-Message attribute MUST calculate the correct
+      value of the Message-Authenticator and MUST 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 an EAP packet, as defined in [RFC2284].
+      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 transported by RADIUS.
+
+3.2.  Message-Authenticator
+
+   Description
+
+      This attribute MAY be used to authenticate and integrity-protect
+      Access-Requests in order to prevent spoofing.  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.
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 16]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+      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.
+
+      This attribute is not required in Access-Requests which include
+      the User-Password attribute, 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.
+
+      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 [RFC2104] hash 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 message integrity check is calculated the signature
+      string should be considered to be sixteen octets of zero.
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 17]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+      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)
+
+      When the message integrity check 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 message
+      integrity check.  The Message-Authenticator is calculated and
+      inserted in the packet before the Response Authenticator is
+      calculated.
+
+3.3.  Table of Attributes
+
+   The following table provides a guide to which attributes may be found
+   in packets including EAP-Message attribute(s), and in what quantity.
+   The EAP-Message and Message-Authenticator attributes specified in
+   this document MUST NOT be present in an Accounting-Request.  If a
+   table entry is omitted, the values found in [RFC2548], [RFC2865],
+   [RFC2868], [RFC2869] and [RFC3162] should be assumed.
+
+Request  Accept  Reject  Challenge   #    Attribute
+0-1      0-1     0       0            1   User-Name
+0        0       0       0            2   User-Password [Note 1]
+0        0       0       0            3   CHAP-Password [Note 1]
+0        0       0       0           18   Reply-Message
+0        0       0       0           60   CHAP-Challenge
+0        0       0       0           70   ARAP-Password [Note 1]
+0        0       0       0           75   Password-Retry
+1+       1+      1+      1+          79   EAP-Message [Note 1]
+1        1       1       1           80   Message-Authenticator [Note 1]
+0-1      0       0       0           94   Originating-Line-Info [Note 3]
+0        0       0-1     0-1        101   Error-Cause [Note 2]
+Request  Accept  Reject  Challenge   #    Attribute
+
+   [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.  A RADIUS
+   server receiving an Access-Request not containing any of those four
+   attributes and also not containing a Message-Authenticator attribute
+   SHOULD silently discard it.
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 18]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   [Note 2] The Error-Cause attribute is defined in [RFC3576].
+
+   [Note 3] The Originating-Line-Info attribute is defined in [NASREQ].
+
+   The following table defines the meaning of 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.
+   1+    One or more of these attributes MUST be present.
+
+4.  Security Considerations
+
+4.1.  Security Requirements
+
+   RADIUS/EAP is used in order to provide authentication and
+   authorization for network access.  As a result, both the RADIUS and
+   EAP portions of the conversation are potential targets of an attack.
+   Threats are discussed in [RFC2607], [RFC2865], and [RFC3162].
+   Examples include:
+
+   [1]  An adversary may attempt to acquire confidential data and
+        identities by snooping RADIUS packets.
+
+   [2]  An adversary may attempt to modify packets containing RADIUS
+        messages.
+
+   [3]  An adversary may attempt to inject packets into a RADIUS
+        conversation.
+
+   [4]  An adversary may launch a dictionary attack against the RADIUS
+        shared secret.
+
+   [5]  An adversary may launch a known plaintext attack, hoping to
+        recover the key stream corresponding to a Request Authenticator.
+
+   [6]  An adversary may attempt to replay a RADIUS exchange.
+
+   [7]  An adversary may attempt to disrupt the EAP negotiation, in
+        order to weaken the authentication, or gain access to peer
+        passwords.
+
+   [8]  An authenticated NAS may attempt to forge NAS or session
+        identification attributes,
+
+   [9]  A rogue (unauthenticated) NAS may attempt to impersonate a
+        legitimate NAS.
+
+
+
+Aboba & Calhoun              Informational                     [Page 19]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   [10] An attacker may attempt to act as a man-in-the-middle.
+
+   To address these threats, it is necessary to support confidentiality,
+   data origin authentication, integrity, and replay protection on a
+   per-packet basis.  Bi-directional authentication between the RADIUS
+   client and server also needs to be provided.  There is no requirement
+   that the identities of RADIUS clients and servers be kept
+   confidential (e.g., from a passive eavesdropper).
+
+4.2.  Security Protocol
+
+   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 support SHOULD be
+   used to provide per-packet confidentiality, authentication, integrity
+   and replay protection.  IKE SHOULD be used for key management.
+
+   Within RADIUS [RFC2865], a shared secret is used for hiding of
+   attributes such as User-Password, as well as in computation of the
+   Response Authenticator.  In RADIUS accounting [RFC2866], the shared
+   secret is used in computation of both the Request Authenticator and
+   the Response Authenticator.
+
+   Since in RADIUS a shared secret is used to provide confidentiality as
+   well as integrity protection and authentication, only use of IPsec
+   ESP with a non-null transform can provide security services
+   sufficient to substitute for RADIUS application-layer security.
+   Therefore, where IPSEC AH or ESP null is used, it will typically
+   still be necessary to configure a RADIUS shared secret.
+
+   Where RADIUS is run over IPsec ESP with a non-null transform, the
+   secret shared between the NAS and the RADIUS server MAY NOT be
+   configured.  In this case, a shared secret of zero length MUST be
+   assumed.  However, a RADIUS server that cannot know whether incoming
+   traffic is IPsec-protected MUST be configured with a non-null RADIUS
+   shared secret.
+
+   When IPsec ESP is used with RADIUS, per-packet authentication,
+   integrity and replay protection MUST be used.  3DES-CBC MUST be
+   supported as an encryption transform and AES-CBC SHOULD be supported.
+   AES-CBC SHOULD be offered as a preferred encryption transform if
+   supported.  HMAC-SHA1-96 MUST be supported as an authentication
+   transform.  DES-CBC SHOULD NOT be used as the encryption transform.
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 20]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   A typical IPsec policy for an IPsec-capable RADIUS client is
+   "Initiate IPsec, from me to any destination port UDP 1812".  This
+   causes an IPsec SA to be set up by the RADIUS client prior to sending
+   RADIUS traffic.  If some RADIUS servers contacted by the client do
+   not support IPsec, then a more granular policy will be required:
+   "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination
+   port UDP 1812".
+
+   For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
+   IPsec, from any to me, destination port 1812".  This causes the
+   RADIUS server to accept (but not require) use of IPsec.  It may not
+   be appropriate to require IPsec for all RADIUS clients connecting to
+   an IPsec-enabled RADIUS server, since some RADIUS clients may not
+   support IPsec.
+
+   Where IPsec is used for security, and no RADIUS shared secret is
+   configured, it is important that the RADIUS client and server perform
+   an authorization check.  Before enabling a host to act as a RADIUS
+   client, the RADIUS server SHOULD check whether the host is authorized
+   to provide network access.  Similarly, before enabling a host to act
+   as a RADIUS server, the RADIUS client SHOULD check whether the host
+   is authorized for that role.
+
+   RADIUS servers can be configured with the IP addresses (for IKE
+   Aggressive Mode with pre-shared keys) or FQDNs (for certificate
+   authentication) of RADIUS clients.  Alternatively, if a separate
+   Certification Authority (CA) exists for RADIUS clients, then the
+   RADIUS server can configure this CA as a trust anchor [RFC3280] for
+   use with IPsec.
+
+   Similarly, RADIUS clients can be configured with the IP addresses
+   (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for
+   certificate authentication) of RADIUS servers.  Alternatively, if a
+   separate CA exists for RADIUS servers, then the RADIUS client can
+   configure this CA as a trust anchor for use with IPsec.
+
+   Since unlike SSL/TLS, IKE does not permit certificate policies to be
+   set on a per-port basis, certificate policies need to apply to all
+   uses of IPsec on RADIUS clients and servers.  In IPsec deployments
+   supporting only certificate authentication, a management station
+   initiating an IPsec-protected telnet session to the RADIUS server
+   would need to obtain a certificate chaining to the RADIUS client CA.
+   Issuing such a certificate might not be appropriate if the management
+   station was not authorized as a RADIUS client.
+
+   Where RADIUS clients may obtain their IP address dynamically (such as
+   an Access Point supporting DHCP), IKE Main Mode with pre-shared keys
+   [RFC2409] SHOULD NOT be used, since this requires use of a group
+
+
+
+Aboba & Calhoun              Informational                     [Page 21]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   pre-shared key; instead, Aggressive Mode SHOULD be used.  IKEv2, a
+   work in progress, may address this issue in the future.  Where RADIUS
+   client addresses are statically assigned, either Aggressive Mode or
+   Main Mode MAY be used.  With certificate authentication, Main Mode
+   SHOULD be used.
+
+   Care needs to be taken with IKE Phase 1 Identity Payload selection in
+   order to enable mapping of identities to pre-shared keys even with
+   Aggressive Mode.  Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity
+   Payloads are used and addresses are dynamically assigned, mapping of
+   identities to keys is not possible, so that group pre-shared keys are
+   still a practical necessity.  As a result, the ID_FQDN identity
+   payload SHOULD be employed in situations where Aggressive mode is
+   utilized along with pre-shared keys and IP addresses are dynamically
+   assigned.  This approach also has other advantages, since it allows
+   the RADIUS server and client to configure themselves based on the
+   fully qualified domain name of their peers.
+
+   Note that with IPsec, security services are negotiated at the
+   granularity of an IPsec SA, so that RADIUS exchanges requiring a set
+   of security services different from those negotiated with existing
+   IPsec SAs will need to negotiate a new IPsec SA.  Separate IPsec SAs
+   are also advisable where quality of service considerations dictate
+   different handling RADIUS conversations.  Attempting to apply
+   different quality of service to connections handled by the same IPsec
+   SA can result in reordering, and falling outside the replay window.
+   For a discussion of the issues, see [RFC2983].
+
+4.3.  Security Issues
+
+   This section provides more detail on the vulnerabilities identified
+   in Section 4.1., and how they may be mitigated.  Vulnerabilities
+   include:
+
+   Privacy issues
+   Spoofing and hijacking
+   Dictionary attacks
+   Known plaintext attacks
+   Replay attacks
+   Negotiation attacks
+   Impersonation
+   Man in the middle attacks
+   Separation of authenticator and authentication server
+   Multiple databases
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 22]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+4.3.1.  Privacy Issues
+
+   Since RADIUS messages may contain the User-Name attribute as well as
+   NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on
+   RADIUS traffic may be able to determine the geographic location of
+   peers in real time.  In wireless networks, it is often assumed that
+   RADIUS traffic is physically secure, since it typically travels over
+   the wired network and that this limits the release of location
+   information.
+
+   However, it is possible for an authenticated attacker to spoof ARP
+   packets [RFC826] so as to cause diversion of RADIUS traffic onto the
+   wireless network.  In this way an attacker may obtain RADIUS packets
+   from which it can glean peer location information, or which it can
+   subject to a known plaintext or offline dictionary attack.  To
+   address these vulnerabilities, implementations of this specification
+   SHOULD use IPsec ESP with non-null transform and per-packet
+   encryption, authentication, integrity and replay protection to
+   protect both RADIUS authentication [RFC2865] and accounting [RFC2866]
+   traffic, as described in Section 4.2.
+
+4.3.2.  Spoofing and Hijacking
+
+   Access-Request packets with a User-Password attribute establish the
+   identity of both the user and the NAS sending the Access-Request,
+   because of the way the shared secret between the NAS and RADIUS
+   server is used.  Access-Request packets with CHAP-Password or
+   EAP-Message attributes do not have a User-Password attribute.  As a
+   result, the Message-Authenticator attribute SHOULD be used in
+   Access-Request packets that do not have a User-Password attribute, in
+   order to establish the identity of the NAS sending the request.
+
+   An attacker may attempt to inject packets into the conversation
+   between the NAS and the RADIUS server, or between the RADIUS server
+   and the security server.  RADIUS [RFC2865] does not support
+   encryption other than attribute hiding.  As described in [RFC2865],
+   only Access-Reply and Access-Challenge packets are integrity
+   protected.  Moreover, the per-packet authentication and integrity
+   protection mechanism described in [RFC2865] has known weaknesses
+   [MD5Attack], making it a tempting target for attackers looking to
+   subvert RADIUS/EAP.
+
+   To provide stronger security, the Message-Authenticator attribute
+   MUST be used in all RADIUS packets containing an EAP-Message
+   attribute.  Implementations of this specification SHOULD use IPsec
+   ESP with non-null transform and per-packet encryption,
+   authentication, integrity and replay protection, as described in
+   Section 4.2.
+
+
+
+Aboba & Calhoun              Informational                     [Page 23]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+4.3.3.  Dictionary Attacks
+
+   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] 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.
+
+   The risk of an offline dictionary attack can be further reduced by
+   employing IPsec ESP with non-null transform in order to encrypt the
+   RADIUS conversation, as described in Section 4.2.
+
+4.3.4.  Known Plaintext Attacks
+
+   Since EAP [RFC2284] does not support PAP, the RADIUS User-Password
+   attribute is not used to carry hidden user passwords within
+   RADIUS/EAP conversations.  The User-Password hiding mechanism,
+   defined in [RFC2865] 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.
+
+   Since the key stream may have been determined previously from a known
+   plaintext attack, if the Request Authenticator repeats, attributes
+   encrypted using the RADIUS attribute hiding mechanism should be
+   considered compromised.  In addition to the User-Password attribute,
+   which is not used with EAP, this includes attributes such as
+   Tunnel-Password [RFC2868, section 3.5] and MS-MPPE-Send-Key and
+   MS-MPPE-Recv-Key attributes [RFC2548, section 2.4], which include a
+   Salt field as part of the hiding algorithm.
+
+   To avoid this, [RFC2865], Section 3 advises:
+
+      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.
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 24]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   Where the Request Authenticator repeats, the Salt field defined in
+   [RFC2548], Section 2.4 does not provide protection against
+   compromise.  This is because MD5 [RFC1321], rather than HMAC-MD5
+   [RFC2104], is used to generate the key stream, which is calculated
+   from the 128-bit RADIUS shared secret (S), the  128-bit Request
+   Authenticator (R), and the Salt field (A), using the formula b(1) =
+   MD5(S + R + A).  Since the Salt field is placed at the end, if the
+   Request Authenticator were to repeat on a network where PAP is in
+   use, then the salted keystream could be calculated from the
+   User-Password keystream by continuing the MD5 calculation based on
+   the Salt field (A), which is sent in the clear.
+
+   Even though EAP does 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 EAP and PAP.
+
+   The threat can be mitigated by protecting RADIUS with IPsec ESP with
+   non-null transform, as described in Section 4.2.  Where RADIUS shared
+   secrets are configured, the RADIUS shared secret used by a NAS
+   supporting EAP MUST NOT be reused by a NAS utilizing the
+   User-Password attribute, since improper shared secret hygiene could
+   lead to compromise of hidden attributes.
+
+4.3.5.  Replay Attacks
+
+   The RADIUS protocol provides only limited support for replay
+   protection.  RADIUS Access-Requests include liveness via the 128-bit
+   Request Authenticator.  However, the Request Authenticator is not a
+   replay counter.  Since RADIUS servers may not maintain a cache of
+   previous Request Authenticators, the Request Authenticator does not
+   provide replay protection.
+
+   RADIUS accounting [RFC2866] does not support replay protection at the
+   protocol level.  Due to the need to support failover between RADIUS
+   accounting servers, protocol-based replay protection is not
+   sufficient to prevent duplicate accounting records.  However, once
+   accepted by the accounting server, duplicate accounting records can
+   be detected by use of the the Acct-Session-Id [RFC2866, section 5.5]
+   and Event-Timestamp [RFC2869, section 5.3] attributes.
+
+   Unlike RADIUS authentication, RADIUS accounting does not use the
+   Request Authenticator as a nonce.  Instead, the Request Authenticator
+   contains an MD5 hash calculated over the Code, Identifier, Length,
+   and request attributes of the Accounting Request packet, plus the
+   shared secret.  The Response Authenticator also contains an MD5 hash
+   calculated over the Code, Identifier and Length, the Request
+
+
+
+Aboba & Calhoun              Informational                     [Page 25]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   Authenticator field from the Accounting-Request packet being replied
+   to, the response attributes and the shared secret.
+
+   Since the Accounting Response Authenticator depends in part on the
+   Accounting Request Authenticator, it is not possible to replay an
+   Accounting-Response unless the Request Authenticator repeats.  While
+   it is possible to utilize EAP methods such as EAP TLS [RFC2716] which
+   include liveness checks on both sides, not all EAP messages will
+   include liveness so that this provides incomplete protection.
+
+   Strong replay protection for RADIUS authentication and accounting can
+   be provided by enabling IPsec replay protection with RADIUS, as
+   described in Section 4.2.
+
+4.3.6.  Negotiation Attacks
+
+   In a negotiation attack a rogue NAS, tunnel server, RADIUS proxy or
+   RADIUS server attempts to cause the authenticating peer to choose a
+   less secure authentication method.  For example, a session that would
+   normally be authenticated with EAP would instead be authenticated via
+   CHAP or PAP; alternatively, a connection that would normally be
+   authenticated via a more secure EAP method such as EAP-TLS [RFC2716]
+   might be made to occur via a less secure EAP method, such as
+   MD5-Challenge.  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 [Masters].
+
+   Protection against negotiation attacks requires the elimination of
+   downward negotiations.  The RADIUS exchange may be further protected
+   by use of IPsec, as described in Section 4.2.  Alternatively, where
+   IPsec is not used, the vulnerability can be mitigated via
+   implementation of per-connection policy on the part of the
+   authenticating peer, and per-peer 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 a strong EAP method when connecting
+   to one service, while negotiating a weaker EAP method for another
+   service.
+
+   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
+
+
+
+Aboba & Calhoun              Informational                     [Page 26]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   peer expecting EAP to be negotiated for a session MUST NOT negotiate
+   a weaker method, such as CHAP or PAP.  In wireless networks, the
+   service advertisement itself may be spoof-able, so that an attacker
+   could fool the peer into negotiating an authentication method
+   suitable for a less secure network.
+
+   For a NAS, it may not be possible to determine whether a peer is
+   required to authenticate with EAP until the peer's identity is known.
+   For example, for shared-uses NASes it is possible for one reseller to
+   implement EAP while another does not.  Alternatively, some peer might
+   be authenticated locally by the NAS while other peers are
+   authenticated via RADIUS.  In such cases, if any peers of the NAS
+   MUST do EAP, then the NAS MUST attempt to negotiate EAP for every
+   session.  This avoids forcing a peer to support more than one
+   authentication type, which could weaken 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 peer 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 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, a PPP NAS MUST send an LCP-Terminate and disconnect
+   the peer.  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 peer connecting from one
+   location (with an EAP-capable proxy) might be able to successfully
+   authenticate via EAP, while the same peer connecting at another
+   location (and encountering an EAP-incapable proxy) might be
+   consistently disconnected.
+
+4.3.7.  Impersonation
+
+   [RFC2865] Section 3 states:
+
+      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.
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 27]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
+   NAS-IPv6-Address attributes may not match the source address.  Since
+   the NAS-Identifier attribute need not contain an FQDN, this attribute
+   also may not correspond to the source address, even indirectly, with
+   or without a proxy present.
+
+   As a result, the authenticity check performed by a RADIUS server or
+   proxy does not verify the correctness of NAS identification
+   attributes.  This makes it possible for a rogue NAS to forge
+   NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
+   a RADIUS Access-Request in order to impersonate another NAS.  It is
+   also possible for a rogue NAS to forge session identification
+   attributes such as Called-Station-Id, Calling-Station-Id, and
+   Originating-Line-Info.
+
+   This could fool the RADIUS server into subsequently sending
+   Disconnect or CoA-Request messages [RFC3576] containing forged
+   session identification attributes to a NAS targeted by an attacker.
+
+   To address these vulnerabilities RADIUS proxies SHOULD check whether
+   NAS identification attributes (NAS-IP-Address, NAS-IPv6-Address,
+   NAS-Identifier) match the source address of packets originating from
+   the NAS.  Where a match is not found, an Access-Reject SHOULD be
+   sent, and an error SHOULD be logged.
+
+   However, such a check may not always be possible.  Since the
+   NAS-Identifier attribute need not correspond to an FQDN, it may not
+   be resolvable to an IP address to be matched against the source
+   address.  Also, where a NAT exists between the RADIUS client and
+   proxy, checking the NAS-IP-Address or NAS-IPv6-Address attributes may
+   not be feasible.
+
+   To allow verification of NAS and session identification parameters,
+   EAP methods can support the secure exchange of these parameters
+   between the EAP peer and EAP server.  NAS identification attributes
+   include NAS-IP-Address, NAS-IPv6-Address and Called-Station-Id;
+   session identification attributes include User-Name and
+   Calling-Station-Id.  The secure exchange of these parameters between
+   the EAP peer and server enables the RADIUS server to check whether
+   the attributes provided by the NAS match those provided by the peer;
+   similarly, the peer can check the parameters provided by the NAS
+   against those provided by the EAP server.  This enables detection of
+   a rogue NAS.
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 28]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+4.3.8.  Man in the Middle Attacks
+
+   RADIUS only provides security on a hop-by-hop basis, even where IPsec
+   is used.  As a result, an attacker gaining control of a RADIUS proxy
+   could attempt to modify EAP packets in transit.  To protect against
+   this, EAP methods SHOULD incorporate their own per-packet integrity
+   protection and authentication mechanisms.
+
+4.3.9.  Separation of Authenticator and Authentication Server
+
+   As noted in [RFC2716], it is possible for the EAP peer and
+   authenticator to mutually authenticate, and derive a Master Session
+   Key (MSK) for a ciphersuite used to protect subsequent data traffic.
+   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 derive and pass a Transient Session Key (TSK) to
+   the ciphersuite module.
+
+   The situation is more complex when EAP is used with RADIUS, since the
+   authenticator and authentication server may not reside on the same
+   host.
+
+   In the case where the authenticator and authentication server reside
+   on different machines, there are several implications for security.
+   First, mutual authentication will occur between the peer and the
+   authentication 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, using
+   EAP alone.
+
+   As described in Section 4.2, when RADIUS/EAP is used to encapsulate
+   EAP packets, IPsec SHOULD be used to provide per-packet
+   authentication, integrity, replay protection and confidentiality.
+   The Message-Authenticator attribute is also required in RADIUS
+   Access-Requests containing an EAP-Message attribute sent from the NAS
+   or tunnel server to the RADIUS server.  Since the
+   Message-Authenticator attribute involves an HMAC-MD5 message
+   integrity check, 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, even where IPsec is not used.  Similarly, Access-Challenge
+   packets containing an EAP-Message attribute sent from the RADIUS
+   server to the NAS are also authenticated and integrity protected
+   using an HMAC-MD5 message integrity check, enabling the NAS or tunnel
+   server to determine the integrity of the packet and verify the
+   identity of the RADIUS server, even where IPsec is not used.
+   Moreover, EAP packets sent using methods that contain their own
+   integrity protection cannot be successfully modified by a rogue NAS
+   or tunnel server.
+
+
+
+Aboba & Calhoun              Informational                     [Page 29]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   The second issue that arises where the authenticator and
+   authentication server reside on separate hosts is that the EAP Master
+   Session Key (MSK) negotiated between the peer and authentication
+   server will need to be transmitted to the authenticator.  Therefore a
+   mechanism needs to be provided to transmit the MSK from the
+   authentication server to the NAS or tunnel server that needs it.  The
+   specification of the key transport and wrapping mechanism is outside
+   the scope of this document.  However, it is expected that the
+   wrapping mechanism will provide confidentiality, integrity and replay
+   protection, and data origin authentication.
+
+4.3.10.  Multiple Databases
+
+   In many cases a security server will be deployed along with a RADIUS
+   server in order to provide EAP services.  Unless the 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
+   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 security server store information in the same database; by having
+   the security server provide a full RADIUS implementation; or by
+   consolidating both the  security server and the RADIUS server onto
+   the same machine.
+
+5.  IANA Considerations
+
+   This specification does not create any new registries, or define any
+   new RADIUS attributes or values.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC
+                  1321, April 1992.
+
+   [RFC2104]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
+                  Keyed-Hashing for Message Authentication", RFC 2104,
+                  February 1997.
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 30]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2279]      Yergeau, F., "UTF-8, a transformation format of ISO
+                  10646", RFC 2279, January 1998.
+
+   [RFC2284]      Blunk, L. and J. Vollbrecht, "PPP Extensible
+                  Authentication Protocol (EAP)", RFC 2284, March 1998.
+
+   [RFC2401]      Atkinson, R. and S. Kent, "Security Architecture for
+                  the Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2406]      Kent, S. and R. Atkinson, "IP Encapsulating Security
+                  Payload (ESP)", RFC 2406, November 1998.
+
+   [RFC2409]      Harkins, D. and D. Carrel, "The Internet Key Exchange
+                  (IKE)", RFC 2409, November 1998.
+
+   [RFC2486]      Aboba, B. and M. Beadles, "The Network Access
+                  Identifier", RFC 2486, January 1999.
+
+   [RFC2865]      Rigney, C., Willens, S., Rubens, A. and W. Simpson,
+                  "Remote Authentication Dial In User Service (RADIUS)",
+                  RFC 2865, June 2000.
+
+   [RFC2988]      Paxson, V. and M. Allman, "Computing TCP's
+                  Retransmission Timer", RFC 2988, November 2000.
+
+   [RFC3162]      Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6",
+                  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.
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 31]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+6.2.  Informative References
+
+   [RFC826]       Plummer, D., "An Ethernet Address Resolution
+                  Protocol", STD 37, RFC 826, November 1982.
+
+   [RFC1510]      Kohl, J. and C. Neuman, "The Kerberos Network
+                  Authentication Service (V5)", RFC 1510, September
+                  1993.
+
+   [RFC1661]      Simpson, W., "The Point-to-Point Protocol (PPP)", STD
+                  51, RFC 1661, July 1994.
+
+   [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.
+
+   [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.
+
+   [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.
+
+   [RFC2983]      Black, D. "Differentiated Services and Tunnels", RFC
+                  2983, October 2000.
+
+   [RFC3580]      Congdon, P., Aboba, B., Smith, A., Zorn, G. and J.
+                  Roese, "IEEE 802.1X Remote Authentication Dial In User
+                  Service (RADIUS) Usage Guidelines", RFC 3580,
+                  September 2003.
+
+   [IEEE802]      IEEE Standards for Local and Metropolitan Area
+                  Networks:  Overview and Architecture, ANSI/IEEE Std
+                  802, 1990.
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 32]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   [IEEE8021X]    IEEE Standards for Local and Metropolitan Area
+                  Networks:  Port based Network Access Control, IEEE Std
+                  802.1X-2001, June 2001.
+
+   [MD5Attack]    Dobbertin, H., "The Status of MD5 After a Recent
+                  Attack", CryptoBytes Vol.2 No.2, Summer 1996.
+
+   [Masters]      Slatalla, M. and  J. Quittner, "Masters of Deception."
+                  HarperCollins, New York, 1995.
+
+   [NASREQ]       Calhoun, P., et al., "Diameter Network Access Server
+                  Application", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 33]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+Appendix A - Examples
+
+   The examples below illustrate conversations between an authenticating
+   peer, NAS, and RADIUS server.  The OTP and EAP-TLS protocols are used
+   only for illustrative purposes; other authentication protocols could
+   also have been used, although they might show somewhat different
+   behavior.
+
+   Where the NAS sends an EAP-Request/Identity as the initial packet,
+   the exchange appears as follows:
+
+Authenticating peer     NAS                    RADIUS server
+-------------------     ---                    -------------
+                        <- EAP-Request/
+                        Identity
+EAP-Response/
+Identity (MyID) ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        (MyID) ->
+                                               <- RADIUS
+                                               Access-Challenge/
+                                               EAP-Message/EAP-Request
+                                               OTP/OTP Challenge
+                        <- EAP-Request/
+                        OTP/OTP Challenge
+EAP-Response/
+OTP, OTPpw ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        OTP, OTPpw ->
+                                                <- RADIUS
+                                                Access-Accept/
+                                                EAP-Message/EAP-Success
+                                                (other attributes)
+                        <- EAP-Success
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 34]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   In the case where the NAS initiates with an EAP-Request for EAP TLS
+   [RFC2716], and the identity is determined based on the contents of
+   the client certificate, the exchange will appear as follows:
+
+Authenticating peer     NAS                    RADIUS server
+-------------------     ---                    -------------
+                        <- EAP-Request/
+                        EAP-Type=EAP-TLS
+                        (TLS Start, S bit set)
+EAP-Response/
+EAP-Type=EAP-TLS
+(TLS client_hello)->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        EAP-Type=EAP-TLS->
+                                              <-RADIUS Access-Challenge/
+                                              EAP-Message/
+                                              EAP-Request/
+                                              EAP-Type=EAP-TLS
+                         <- EAP-Request/
+                         EAP-Type=EAP-TLS
+                         (TLS server_hello,
+                         TLS certificate,
+                   [TLS server_key_exchange,]
+                   [TLS certificate_request,]
+                       TLS server_hello_done)
+EAP-Response/
+EAP-Type=EAP-TLS
+(TLS certificate,
+TLS client_key_exchange,
+[TLS certificate_verify,]
+TLS change_cipher_spec,
+TLS finished)->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        EAP-Type=EAP-TLS->
+                                              <-RADIUS Access-Challenge/
+                                              EAP-Message/
+                                              EAP-Request/
+                                              EAP-Type=EAP-TLS
+                        <- EAP-Request/
+                        EAP-Type=EAP-TLS
+                        (TLS change_cipher_spec,
+                        TLS finished)
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 35]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+EAP-Response/
+EAP-Type=EAP-TLS ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        EAP-Type=EAP-TLS->
+                                              <-RADIUS Access-Accept/
+                                              EAP-Message/EAP-Success
+                                              (other attributes)
+                        <- EAP-Success
+
+   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
+-------------------     ---                    -------------
+                        RADIUS Access-Request/
+                        EAP-Message/Start ->
+                                               <- RADIUS
+                                               Access-Challenge/
+                                               EAP-Message/EAP-Request/
+                                               Identity
+                        <- EAP-Request/
+                        Identity
+EAP-Response/
+Identity (MyID) ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        Identity (MyID) ->
+                                                <- RADIUS
+                                                Access-Challenge/
+                                                EAP-Message/EAP-Request/
+                                                OTP/OTP Challenge
+                        <- EAP-Request/
+                        OTP/OTP Challenge
+EAP-Response/
+OTP, OTPpw ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        OTP, OTPpw ->
+                                                <- RADIUS
+                                                Access-Accept/
+                                                EAP-Message/EAP-Success
+                                                (other attributes)
+                        <- EAP-Success
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 36]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   In the case where the NAS initiates with an EAP-Request for EAP TLS
+   [RFC2716], but the peer responds with a Nak, indicating that it would
+   prefer another method not implemented locally on the NAS, the
+   exchange will appear as follows:
+
+Authenticating peer     NAS                    RADIUS server
+-------------------     ---                    -------------
+                        <- EAP-Request/
+                        EAP-Type=EAP-TLS
+                        (TLS Start, S bit set)
+EAP-Response/
+EAP-Type=Nak
+(Alternative(s))->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        Nak ->
+                                               <- RADIUS
+                                               Access-Challenge/
+                                               EAP-Message/EAP-Request/
+                                               Identity
+                        <- EAP-Request/
+                        Identity
+EAP-Response/
+Identity (MyID) ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        (MyID) ->
+                                               <- RADIUS
+                                               Access-Challenge/
+                                               EAP-Message/EAP-Request
+                                               OTP/OTP Challenge
+                        <- EAP-Request/
+                        OTP/OTP Challenge
+EAP-Response/
+OTP, OTPpw ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        OTP, OTPpw ->
+                                                <- RADIUS
+                                                Access-Accept/
+                                                EAP-Message/EAP-Success
+                                                (other attributes)
+                        <- EAP-Success
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 37]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   In the case where the authenticating peer attempts to authenticate
+   the NAS, the conversation would appear as follows:
+
+Authenticating peer     NAS                    RADIUS Server
+-------------------     ---                    -------------
+EAP-Request/
+Challenge, MD5 ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Request/
+                        Challenge, MD5 ->
+                                                <- RADIUS
+                                                Access-Reject/
+                                                EAP-Message/
+                                                EAP-Response/
+                                                Nak (no alternative)
+
+                        <- EAP-Response/Nak
+                         (no alternative)
+EAP-Failure ->
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 38]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   In the case where an invalid EAP Response is inserted by an attacker,
+   the conversation would appear as follows:
+
+Authenticating peer     NAS                    RADIUS server
+-------------------     ---                    -------------
+                        <- EAP-Request/
+                        EAP-Type=Foo
+EAP-Response/
+EAP-Type=Foo ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        EAP-Type=Foo ->
+                                               <- RADIUS
+                                               Access-Challenge/
+                                               EAP-Message/EAP-Request/
+                                               EAP-Type=Foo
+                        <- EAP-Request/
+                        EAP-Type=Foo
+Attacker spoof:
+EAP-Response/
+EAP-Type=Bar ->
+
+Good guy:
+EAP-Response/
+EAP-Type=Foo ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        EAP-Type=Bar ->
+
+                                               <- RADIUS
+                                               Access-Challenge/
+                                               EAP-Message/EAP-Request/
+                                               EAP-Type=Foo,
+                                               Error-Cause="Invalid EAP
+                                                Packet (Ignored)"
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        EAP-Type=Foo ->
+                                               <- Access-Accept/
+                                               EAP-Message/Success
+                        <- EAP Success
+
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 39]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   In the case where the client fails EAP authentication, and an error
+   message is sent prior to disconnection, the conversation would appear
+   as follows:
+
+Authenticating peer     NAS                    RADIUS server
+-------------------     ---                    -------------
+                        RADIUS Access-Request/
+                        EAP-Message/Start ->
+                                               <- RADIUS
+                                               Access-Challenge/
+                                               EAP-Message/EAP-Response/
+                                               Identity
+                        <- EAP-Request/
+                        Identity
+EAP-Response/
+Identity (MyID) ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        (MyID) ->
+                                                <- RADIUS
+                                                Access-Challenge/
+                                                EAP-Message/EAP-Request
+                                                OTP/OTP Challenge
+                        <- EAP-Request/
+                        OTP/OTP Challenge
+EAP-Response/
+OTP, OTPpw ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        OTP, OTPpw ->
+                                                <- RADIUS
+                                                Access-Challenge/
+                                                EAP-Message/EAP-Request/
+                                                Notification
+                        <- EAP-Request/
+                           Notification
+
+EAP-Response/
+Notification ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        Notification ->
+                                                 <- RADIUS
+                                                 Access-Reject/
+                                                 EAP-Message/EAP-Failure
+                        <- EAP-Failure
+                        (client disconnected)
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 40]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   In the case that the RADIUS server or proxy does not support EAP-
+   Message, but no error message is sent, the conversation would appear
+   as follows:
+
+Authenticating peer     NAS                       RADIUS server
+-------------------     ---                       -------------
+                        RADIUS Access-Request/
+                        EAP-Message/Start ->
+                                                  <- RADIUS
+                                                  Access-Reject
+                        (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
+-------------------     ---                       -------------
+                        RADIUS Access-Request/
+                        EAP-Message/Start ->
+                                                  <- RADIUS
+                                                  Access-Challenge/
+                                                  EAP-Message/
+                                                  EAP-Response/
+                                                  Identity
+                        <- EAP-Request/
+                        Identity
+
+EAP-Response/
+Identity
+(MyID) ->
+                        RADIUS Access-Request/
+                        EAP-Message/EAP-Response/
+                        (MyID) ->
+                                                  <- RADIUS
+                                                  Access-Reject
+                                                  (proxied from remote
+                                                   RADIUS server)
+                        (User Disconnected)
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 41]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   In the case where PPP is the link and 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 PPP is the link, 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
+
+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)
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 42]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+Appendix B - Change Log
+
+   The following changes have been made from RFC 2869:
+
+   A NAS may simultaneously support both local authentication and
+   pass-through; once the NAS enters pass-through mode within a session,
+   it cannot revert back to local authentication.  Also EAP is
+   explicitly described as a 'lock step' protocol. (Section 2).
+
+   The NAS may initiate with an EAP-Request for an authentication Type.
+   If the Request is NAK'd, the NAS should send an initial
+   Access-Request with an EAP-Message attribute containing an
+   EAP-Response/Nak.
+
+   The RADIUS server may treat an invalid EAP Response as a non-fatal
+   error (Section 2.2)
+
+   For use with RADIUS/EAP, the Password-Retry (Section 2.3) and
+   Reply-Message (2.6.5) attributes are deprecated.
+
+   Each EAP session has a unique Identifier space (Section 2.6.1).
+
+   Role reversal is not supported (Section 2.6.2).
+
+   Message combinations (e.g. Access-Accept/EAP-Failure) that conflict
+   are discouraged (Section 2.6.3).
+
+   Only a single EAP packet may be encapsulated within a RADIUS message
+   (Section 3.1).
+
+   An Access-Request lacking explicit authentication as well as a
+   Message- Authenticator attribute SHOULD be silently discarded
+   (Section 3.3).
+
+   The Originating-Line-Info attribute is supported (Section 3.3).
+
+   IPsec ESP with non-null transform SHOULD be used and the usage model
+   is described in detail (Section 4.2).
+
+   Additional discussion of security vulnerabilities (Section 4.1) and
+   potential fixes (Section 4.3).
+
+   Separated normative (Section 6.1) and informative (Section 6.2)
+   references.
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 43]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+   Added additional examples (Appendix A): a NAS initiating with an
+   EAP-Request for an authentication Type; attempted role reversal.
+
+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.
+
+Acknowledgments
+
+   Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn of Cisco
+   Systems, Jari Arkko of Ericsson and Ashwin Palekar, Tim Moore and
+   Narendra Gidwani of Microsoft for useful discussions of this problem
+   space.  The authors would also like to acknowledge Tony Jeffree,
+   Chair of IEEE 802.1 for his assistance in resolving RADIUS/EAP issues
+   in IEEE 802.1X-2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 44]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+Authors' Addresses
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone:  +1 425 706 6605
+   Fax:    +1 425 936 7329
+   EMail:   bernarda@microsoft.com
+
+
+   Pat R. Calhoun
+   Airespace
+   110 Nortech Parkway
+   San Jose, California, 95134
+   USA
+
+   Phone:  +1 408 635 2023
+   Fax:    +1 408 635 2020
+   EMail:  pcalhoun@airespace.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 45]
+\f
+RFC 3579                      RADIUS & EAP                September 2003
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba & Calhoun              Informational                     [Page 46]
+\f