rfc4590.txt

使用最广泛的radius的linux的源码

   Due to syntactic requirements, HTTP-style protocols have to escape
   with backslash all quote and backslash characters in contents of HTTP
   Digest directives.  When translating directives into RADIUS
   attributes, the RADIUS client only removes the surrounding quotes
   where present.  See Section 3 for an example.

   If the Quality of Protection (qop) directive's value is 'auth-int',
   the RADIUS client calculates H(entity-body) as described in
   [RFC2617], Section 3.2.1, and puts the result in a
   Digest-Entity-Body-Hash attribute.

   The RADIUS client adds a Message-Authenticator attribute, defined in
   [RFC3579], and sends the Access-Request packet to the RADIUS server.

   The RADIUS server processes the packet and responds with an
   Access-Accept or an Access-Reject.

2.1.3.  Constructing an Authentication-Info Header

   After having received an Access-Accept from the RADIUS server, the
   RADIUS client constructs an Authentication-Info header:

   o  If the Access-Accept packet contains a Digest-Response-Auth
      attribute, the RADIUS client checks the Digest-Qop attribute:

      *  If the Digest-Qop attribute's value is 'auth' or not specified,
         the RADIUS client puts the Digest-Response-Auth attribute's
         content into the Authentication-Info header's 'rspauth'
         directive of the HTTP-style response.

      *  If the Digest-Qop attribute's value is 'auth-int', the RADIUS
         client ignores the Access-Accept packet and behaves as if it
         had received an Access-Reject packet (Digest-Response-Auth
         can't be correct as the RADIUS server does not know the
         contents of the HTTP-style response's body).






Sterman, et al.             Standards Track                     [Page 7]

RFC 4590              RADIUS Digest Authentication             July 2006


   o  If the Access-Accept packet contains a Digest-HA1 attribute, the
      RADIUS client checks the 'qop' and 'algorithm' directives in the
      Authorization header of the HTTP-style request it wants to
      authorize:

      *  If the 'qop' directive is missing or its value is 'auth', the
         RADIUS client ignores the Digest-HA1 attribute.  It does not
         include an Authentication-Info header in its HTTP-style
         response.

      *  If the 'qop' directive's value is 'auth-int' and at least one
         of the following conditions is true, the RADIUS client
         calculates the contents of the HTTP-style response's 'rspauth'
         directive:

         +  The algorithm directive's value is 'MD5-sess' or
            'AKAv1-MD5-sess'.

         +  IP Security (IPsec) is configured to protect traffic between
            the RADIUS client and RADIUS server with IPsec (see
            Section 8).

         It creates the HTTP-style response message and calculates the
         hash of this message's body.  It uses the result and the
         Digest-URI attribute's value of the corresponding
         Access-Request packet to perform the H(A2) calculation.  It
         takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce, and
         Digest-Qop values of the corresponding Access-Request and the
         Digest-HA1 attribute's value to finish the computation of the
         'rspauth' value.

   o  If the Access-Accept packet contains neither a
      Digest-Response-Auth nor a Digest-HA1 attribute, the RADIUS client
      will not create an Authentication-Info header for its HTTP-style
      response.

   When the RADIUS server provides a Digest-Nextnonce attribute in the
   Access-Accept packet, the RADIUS client puts the contents of this
   attribute into a 'nextnonce' directive.  Now it can send an
   HTTP-style response.

2.1.4.  Failed Authentication

   If the RADIUS client did receive an HTTP-style request without a
   (Proxy-)Authorization header matching its locally configured realm
   value, it obtains a new nonce and sends an error response (401 or
   407) containing a (Proxy-)Authenticate header.




Sterman, et al.             Standards Track                     [Page 8]

RFC 4590              RADIUS Digest Authentication             July 2006


   If the RADIUS client receives an Access-Challenge packet in response
   to an Access-Request containing a Digest-Nonce attribute, the RADIUS
   server did not accept the nonce.  If a Digest-Stale attribute is
   present in the Access-Challenge and has a value of 'true' (without
   surrounding quotes), the RADIUS client sends an error response (401
   or 407) containing a WWW-/Proxy-Authenticate header with the
   directive 'stale' and the digest directives derived from the Digest-*
   attributes.

   If the RADIUS client receives an Access-Reject from the RADIUS
   server, it sends an error response to the HTTP-style request it has
   received.  If the RADIUS client does not receive a response, it
   retransmits or fails over to another RADIUS server as described in
   [RFC2865].

2.1.5.  Obtaining Nonces

   The RADIUS client has two ways to obtain nonces: it has received one
   in a Digest-Nextnonce attribute of a previously received
   Access-Accept packet or it asks the RADIUS server for one.  To do the
   latter, it sends an Access-Request containing a Digest-Method and a
   Digest-URI attribute but without a Digest-Nonce attribute.  It adds a
   Message-Authenticator (see [RFC3579]) attribute to the Access-Request
   packet.  The RADIUS server chooses a nonce and responds with an
   Access-Challenge containing a Digest-Nonce attribute.

   The RADIUS client constructs a (Proxy-)Authenticate header using the
   received Digest-Nonce and Digest-Realm attributes to fill the nonce
   and realm directives.  The RADIUS server can send Digest-Qop,
   Digest-Algorithm, Digest-Domain, and Digest-Opaque attributes in the
   Access-Challenge carrying the nonce.  If these attributes are
   present, the client MUST use them.

2.2.  RADIUS Server Behavior

   If the RADIUS server receives an Access-Request packet with a
   Digest-Method and a Digest-URI attribute but without a Digest-Nonce
   attribute, it chooses a nonce.  It puts the nonce into a Digest-Nonce
   attribute and sends it in an Access-Challenge packet to the RADIUS
   client.  The RADIUS server MUST add Digest-Realm,
   Message-Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm
   and one or more Digest-Qop, and MAY add Digest-Domain or
   Digest-Opaque attributes to the Access-Challenge packet.

2.2.1.  General Attribute Checks

   If the RADIUS server receives an Access-Request packet containing a
   Digest-Response attribute, it looks for the following attributes:



Sterman, et al.             Standards Track                     [Page 9]

RFC 4590              RADIUS Digest Authentication             July 2006


   Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop,
   Digest-Algorithm, and Digest-Username.  Depending on the content of
   Digest-Algorithm and Digest-Qop, it looks for
   Digest-Entity-Body-Hash, Digest-CNonce, and Digest-AKA-Auts, too.
   See [RFC2617] and [RFC3310] for details.  If the Digest-Algorithm
   attribute is missing, 'MD5' is assumed.  If the RADIUS server has
   issued a Digest-Opaque attribute along with the nonce, the
   Access-Request MUST have a matching Digest-Opaque attribute.

   If mandatory attributes are missing, it MUST respond with an
   Access-Reject packet.

   The RADIUS server removes '\' characters that escape quote and '\'
   characters from the text values it has received in the Digest-*
   attributes.

   If the mandatory attributes are present, the RADIUS server MUST check
   if the RADIUS client is authorized to serve users of the realm
   mentioned in the Digest-Realm attribute.  If the RADIUS client is not
   authorized, the RADIUS server MUST send an Access-Reject.  The RADIUS
   server SHOULD log the event so as to notify the operator, and MAY
   take additional action such as sending an Access-Reject in response
   to all future requests from this client, until this behavior is reset
   by management action.

   The RADIUS server determines the age of the nonce in Digest-Nonce by
   using an embedded time-stamp or by looking it up in a local table.
   The RADIUS server MUST check the integrity of the nonce if it embeds
   the time-stamp in the nonce.  Section 2.2.2 describes how the server
   handles old nonces.

2.2.2.  Authentication

   If the Access-Request message has passed the checks described above,
   the RADIUS server calculates the digest response as described in
   [RFC2617].  To look up the password, the RADIUS server uses the
   RADIUS User-Name attribute.  The RADIUS server MUST check if the user
   identified by the User-Name attribute

   o  is authorized to access the protection space and

   o  is authorized to use the URI included in the SIP-AOR attribute, if
      this attribute is present.

   If any of those checks fails, the RADIUS server MUST send an
   Access-Reject.





Sterman, et al.             Standards Track                    [Page 10]

RFC 4590              RADIUS Digest Authentication             July 2006


   Correlation between User-Name and SIP-AOR AVP values is required just
   to avoid that any user can register or misuse a SIP-AOR allocated to
   a different user.

   All values required for the digest calculation are taken from the
   Digest attributes described in this document.  If the calculated
   digest response equals the value received in the Digest-Response
   attribute, the authentication was successful.

   If the response values match, but the RADIUS server considers the
   nonce in the Digest-Nonce attribute as too old, it sends an
   Access-Challenge packet containing a new nonce and a Digest-Stale
   attribute with a value of 'true' (without surrounding quotes).

   If the response values don't match, the RADIUS server responds with
   an Access-Reject.

2.2.3.  Constructing the Reply

   If the authentication was successful, the RADIUS server adds an
   attribute to the Access-Accept packet that can be used by the RADIUS
   client to construct an Authentication-Info header:

   o  If the Digest-Qop attribute's value is 'auth' or unspecified, the
      RADIUS server SHOULD put a Digest-Response-Auth attribute into the
      Access-Accept packet.

   o  If the Digest-Qop attribute's value is 'auth-int' and at least one
      of the following conditions is true, the RADIUS server SHOULD put
      a Digest-HA1 attribute into the Access-Accept packet:

      *  The Digest-Algorithm attribute's value is 'MD5-sess' or
         'AKAv1-MD5-sess'.

      *  IPsec is configured to protect traffic between the RADIUS
         client and RADIUS server with IPsec (see Section 8).

   In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
   sent.

   RADIUS servers MAY construct a Digest-Nextnonce attribute and add it
   to the Access-Accept packet.  This is useful to limit the lifetime of
   a nonce and to save a round-trip in future requests (see nextnonce
   discussion in [RFC2617], section 3.2.3).  The RADIUS server adds a
   Message-Authenticator attribute (see [RFC3579]) and sends the
   Access-Accept packet to the RADIUS client.





Sterman, et al.             Standards Track                    [Page 11]

RFC 4590              RADIUS Digest Authentication             July 2006


   If the RADIUS server does not accept the nonce received in an
   Access-Request packet but authentication was successful, the RADIUS
   server MUST send an Access-Challenge packet containing a Digest-Stale
   attribute set to 'true' (without surrounding quotes).  The RADIUS
   server MUST add Message-Authenticator (see [RFC3579]), Digest-Nonce,
   Digest-Realm, SHOULD add Digest-Algorithm and one or more Digest-Qop
   and MAY add Digest-Domain, Digest-Opaque attributes to the
   Access-Challenge packet.

3.  New RADIUS Attributes

   If not stated otherwise, the attributes have the following format:

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

   Quote and backslash characters in Digest-* attributes representing
   HTTP-style directives with a quoted-string syntax are escaped.  The
   surrounding quotes are removed.  They are syntactical delimiters that
   are redundant in RADIUS.  For example, the directive

   realm="the \"example\" value"

   is represented as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Digest-Realm  |       23      | the \"example\" value |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.  Digest-Response attribute

   Description
         If this attribute is present in an Access-Request message, a
         RADIUS server implementing this specification MUST treat the
         Access-Request as a request for Digest Authentication.  When a
         RADIUS client receives a (Proxy-)Authorization header, it puts
         the request-digest value into a Digest-Response attribute.
         This attribute (which enables the user to prove possession of
         the password) MUST only be used in Access-Requests.
   Type
         103 for Digest-Response.
   Length
         >= 3





Sterman, et al.             Standards Track                    [Page 12]

RFC 4590              RADIUS Digest Authentication             July 2006


   Text
         When using HTTP Digest, the text field is 32 octets long and
         contains a hexadecimal representation of a 16-octet digest
         value as it was calculated by the authenticated client.  Other
         digest algorithms MAY define different digest lengths.  The
         text field MUST be copied from request-digest of
         digest-response ([RFC2617]) without surrounding quotes.

3.2.  Digest-Realm Attribute

   Description
         This attribute describes a protection space component of the
         RADIUS server.  HTTP-style protocols differ in their definition
         of the protection space.  See [RFC2617], Section 1.2, for
         details.  It MUST only be used in Access-Request and
         Access-Challenge packets.
   Type
         104 for Digest-Realm
   Length
         >=3
   Text
         In Access-Requests, the RADIUS client takes the value of the
         realm directive (realm-value according to [RFC2617]) without
         surrounding quotes from the HTTP-style request it wants to