tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2865

 
 
 

Remote Authentication Dial In User Service (RADIUS)

Part 3 of 3, p. 50 to 76
Prev RFC Part

 


prevText      Top      Up      ToC       Page 50 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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.