Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2865

Remote Authentication Dial In User Service (RADIUS)

Pages: 76
Draft Standard
Errata
Obsoletes:  2138
Updated by:  28683575508069298044
Part 3 of 3 – Pages 50 to 76
First   Prev   None

Top   ToC   RFC2865 - Page 50   prevText

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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Top   ToC   RFC2865 - Page 51
   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
Top   ToC   RFC2865 - Page 52
   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
Top   ToC   RFC2865 - Page 53
   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.
Top   ToC   RFC2865 - Page 54
   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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Top   ToC   RFC2865 - Page 55
   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
Top   ToC   RFC2865 - Page 56
   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
Top   ToC   RFC2865 - Page 57
   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.
Top   ToC   RFC2865 - Page 58

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.
Top   ToC   RFC2865 - Page 59
   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... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Top   ToC   RFC2865 - Page 60
   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
Top   ToC   RFC2865 - Page 61
      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.
Top   ToC   RFC2865 - Page 62
    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
Top   ToC   RFC2865 - Page 63
   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
Top   ToC   RFC2865 - Page 64
   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".
Top   ToC   RFC2865 - Page 65
   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.
Top   ToC   RFC2865 - Page 66

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.
Top   ToC   RFC2865 - Page 67
      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)
Top   ToC   RFC2865 - Page 68
   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
Top   ToC   RFC2865 - Page 69
       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).
Top   ToC   RFC2865 - Page 70
   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)
Top   ToC   RFC2865 - Page 71

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.
Top   ToC   RFC2865 - Page 72
   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.
Top   ToC   RFC2865 - Page 73

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.
Top   ToC   RFC2865 - Page 74
   [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
Top   ToC   RFC2865 - Page 75

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
Top   ToC   RFC2865 - Page 76

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.