rfc2058.txt

RFC 的详细文档！

      string    0-253 octets

      address   32 bit value, most significant octet first.

      integer   32 bit value, most significant octet first.






Rigney, et. al.              Informational                     [Page 19]

RFC 2058                         RADIUS                     January 1997


      time      32 bit value, most significant octet first -- seconds
                since 00:00:00 GMT, January 1, 1970.  The standard
                Attributes do not use this data type but it is presented
                here for possible use within Vendor-Specific attributes.

5.1.  User-Name

   Description

     This Attribute indicates the name of the user to be authenticated.
     It is only used in Access-Request packets.

   A summary of the User-Name Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

     1 for User-Name.

   Length

     >= 3

   String

     The String field is one or more octets.  The NAS may limit the
     maximum length of the User-Name but the ability to handle at least
     63 octets is recommended.

















Rigney, et. al.              Informational                     [Page 20]

RFC 2058                         RADIUS                     January 1997


     The format of the username MAY be one of several forms:

     monolithic Consisting only of alphanumeric characters.  This
                simple form might be used to locally manage a NAS.

     simple     Consisting only of printable ASCII characters.

     name@fqdn SMTP address.  The Fully Qualified Domain Name (with or
               without trailing dot) indicates the realm in which the
               name part applies.

     distinguished name
               A name in ASN.1 form used in Public Key authentication
               systems.

5.2.  User-Password

   Description

     This Attribute indicates the password of the user to be
     authenticated, or the user's input following an Access-Challenge.
     It is only used in Access-Request packets.

     On transmission, the password is hidden.  The password is first
     padded at the end with nulls to a multiple of 16 octets.  A one-way
     MD5 hash is calculated over a stream of octets consisting of the
     shared secret followed by the Request Authenticator.  This value is
     XORed with the first 16 octet segment of the password and placed in
     the first 16 octets of the String field of the User-Password
     Attribute.

     If the password is longer than 16 characters, a second one-way MD5
     hash is calculated over a stream of octets consisting of the shared
     secret followed by the result of the first xor.  That hash is XORed
     with the second 16 octet segment of the password and placed in the
     second 16 octets of the String field of the User-Password
     Attribute.

     If necessary, this operation is repeated, with each xor result
     being used along with the shared secret to generate the next hash
     to xor the next segment of the password, to no more than 128
     characters.

     The method is taken from the book "Network Security" by Kaufman,
     Perlman and Speciner [4] pages 109-110.  A more precise explanation
     of the method follows:





Rigney, et. al.              Informational                     [Page 21]

RFC 2058                         RADIUS                     January 1997


     Call the shared secret S and the pseudo-random 128-bit Request
     Authenticator RA.  Break the password into 16-octet chunks p1, p2,
     etc.  with the last one padded at the end with nulls to a 16-octet
     boundary.  Call the ciphertext blocks c(1), c(2), etc.  We'll need
     intermediate values b1, b2, etc.

         b1 = MD5(S + RA)       c(1) = p1 xor b1
         b2 = MD5(S + c(1))     c(2) = p2 xor b2
                .                       .
                .                       .
                .                       .
         bi = MD5(S + c(i-1))   c(i) = pi xor bi


     The String will contain c(1)+c(2)+...+c(i) where + denotes
     concatenation.

     On receipt, the process is reversed to yield the original password.

   A summary of the User-Password Attribute format is shown below.  The
   fields are transmitted from left to right.

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
      |     Type      |    Length     |  String ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Type

         2 for User-Password.

      Length

         At least 18 and no larger than 130.

      String

         The String field is between 16 and 128 octets long, inclusive.

5.3.  CHAP-Password

   Description

     This Attribute indicates the response value provided by a PPP
     Challenge-Handshake Authentication Protocol (CHAP) user in response
     to the challenge.  It is only used in Access-Request packets.




Rigney, et. al.              Informational                     [Page 22]

RFC 2058                         RADIUS                     January 1997


     The CHAP challenge value is found in the CHAP-Challenge Attribute
     (60) if present in the packet, otherwise in the Request
     Authenticator field.

   A summary of the CHAP-Password Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  CHAP Ident   |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Type

      3 for CHAP-Password.

   Length

      19

   CHAP Ident

      This field is one octet, and contains the CHAP Identifier from the
      user's CHAP Response.

   String

      The String field is 16 octets, and contains the CHAP Response from
      the user.


5.4.  NAS-IP-Address

   Description

     This Attribute indicates the identifying IP Address of the NAS
     which is requesting authentication of the user.  It is only used in
     Access-Request packets.  Either NAS-IP-Address or NAS-Identifier
     SHOULD be present in an Access-Request packet.










Rigney, et. al.              Informational                     [Page 23]

RFC 2058                         RADIUS                     January 1997


   A summary of the NAS-IP-Address Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      4 for NAS-IP-Address.

   Length

      6

   Address

      The Address field is four octets.

5.5.  NAS-Port

   Description

     This Attribute indicates the physical port number of the NAS which
     is authenticating the user.  It is only used in Access-Request
     packets.  Note that this is using "port" in its sense of a physical
     connection on the NAS, not in the sense of a TCP or UDP port
     number.  Either NAS-Port or NAS-Port-Type (61) or both SHOULD be
     present in an Access-Request packet, if the NAS differentiates
     among its ports.
















Rigney, et. al.              Informational                     [Page 24]

RFC 2058                         RADIUS                     January 1997


   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.  Despite the size of the field,
      values range from 0 to 65535.


5.6.  Service-Type

   Description

     This Attribute indicates the type of service the user has
     requested, or the type of service to be provided.  It MAY be used
     in both Access-Request and Access-Accept packets.  A NAS is not
     required to implement all of these service types, and MUST treat
     unknown or unsupported Service-Types as though an Access-Reject had
     been received instead.

   A summary of the Service-Type Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Rigney, et. al.              Informational                     [Page 25]

RFC 2058                         RADIUS                     January 1997