RFC 4590 - RADIUS Extension for Digest Authentication(2)

时间:2006-11-02 来源: 作者: 点击:
TheRADIUSserverMUSTchecktheintegrityofthenonceifitembeds thetime-stampinthenonce.Section2.2.2describeshowtheserver handlesoldnonces. 2.2.2.Authentication IftheAccess-Requestmessagehaspassedthechecksd
  
   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.

   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.

   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

   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
         authenticate.  In Access-Challenge packets, the RADIUS server
         puts the expected realm value into this attribute.

3.3.  Digest-Nonce Attribute

   Description

         This attribute holds a nonce to be used in the HTTP Digest
         calculation.  If the Access-Request had a Digest-Method and a
         Digest-URI but no Digest-Nonce attribute, the RADIUS server
         MUST put a Digest-Nonce attribute into its Access-Challenge
         packet.  This attribute MUST only be used in Access-Request and
         Access-Challenge packets.
   Type
         105 for Digest-Nonce
   Length
         >=3
   Text
         In Access-Requests, the RADIUS client takes the value of the
         nonce directive (nonce-value in [RFC2617]) without surrounding
         quotes from the HTTP-style request it wants to authenticate.
         In Access-Challenge packets, the attribute contains the nonce
         selected by the RADIUS server.

3.4.  Digest-Response-Auth Attribute

   Description
         This attribute enables the RADIUS server to prove possession of
         the password.  If the previously received Digest-Qop attribute
         was ’auth-int’ (without surrounding quotes), the RADIUS server
         MUST send a Digest-HA1 attribute instead of a
         Digest-Response-Auth attribute.  The Digest-Response-Auth
         attribute MUST only be used in Access-Accept packets.  The
         RADIUS client puts the attribute value without surrounding
         quotes into the rspauth directive of the Authentication-Info
         header.
   Type
         106 for Digest-Response-Auth.
   Length
         >= 3
   Text
         The RADIUS server calculates a digest according to section
         3.2.3 of [RFC2617] and copies the result into this attribute.
         Digest algorithms other than the one defined in [RFC2617] MAY
         define digest lengths other than 32.

3.5.  Digest-Nextnonce Attribute

   This attribute holds a nonce to be used in the HTTP Digest
   calculation.

   Description

         The RADIUS server MAY put a Digest-Nextnonce attribute into an
         Access-Accept packet.  If this attribute is present, the RADIUS
         client MUST put the contents of this attribute into the
         nextnonce directive of an Authentication-Info header in its
         HTTP-style response.  This attribute MUST only be used in
         Access-Accept packets.
   Type
         107 for Digest-Nextnonce
   Length
         >=3
   Text
         It is recommended that this text be base64 or hexadecimal data.

3.6.  Digest-Method Attribute

   Description
         This attribute holds the method value to be used in the HTTP
         Digest calculation.  This attribute MUST only be used in
         Access-Request packets.

   Type
         108 for Digest-Method
   Length
         >=3
   Text
         In Access-Requests, the RADIUS client takes the value of the
         request method from the HTTP-style request it wants to
         authenticate.

3.7.  Digest-URI Attribute

   Description
         This attribute is used to transport the contents of the
         digest-uri directive or the URI of the HTTP-style request.  It
         MUST only be used in Access-Request packets.
   Type
         109 for Digest-URI
   Length
         >=3
   Text
         If the HTTP-style request has an Authorization header, the
         RADIUS client puts the value of the "uri" directive found in
         the HTTP-style request Authorization header (known as
         "digest-uri-value" in section 3.2.2 of [RFC2617]) without
         surrounding quotes into this attribute.  If there is no
         Authorization header, the RADIUS client takes the value of the
         request URI from the HTTP-style request it wants to
         authenticate.

3.8.  Digest-Qop Attribute

   Description
         This attribute holds the Quality of Protection parameter that
         influences the HTTP Digest calculation.  This attribute MUST
         only be used in Access-Request and Access-Challenge packets.  A
         RADIUS client SHOULD insert one of the Digest-Qop attributes it
         has received in a previous Access-Challenge packet.  RADIUS
         servers SHOULD insert at least one Digest-Qop attribute in an
         Access-Challenge packet.  Digest-Qop is optional in order to
         preserve backward compatibility with a minimal implementation
         of [RFC2069].
   Type
         110 for Digest-Qop
   Length
         >=3
   Text
         In Access-Requests, the RADIUS client takes the value of the
         qop directive (qop-value as described in [RFC2617]) from the

         HTTP-style request it wants to authenticate.  In
         Access-Challenge packets, the RADIUS server puts a desired
         qop-value into this attribute.  If the RADIUS server supports
         more than one "quality of protection" value, it puts each
         qop-value into a separate Digest-Qop attribute.

3.9.  Digest-Algorithm Attribute

   Description
         This attribute holds the algorithm parameter that influences
         the HTTP Digest calculation.  It MUST only be used in
         Access-Request and Access-Challenge packets.  If this attribute
         is missing, MD5 is assumed.
   Type
         111 for Digest-Algorithm
   Length
         >=3
   Text
         In Access-Requests, the RADIUS client takes the value of the
         algorithm directive (as described in [RFC2617], section 3.2.1)
         from the HTTP-style request it wants to authenticate.  In
         Access-Challenge packets, the RADIUS server SHOULD put the
         desired algorithm into this attribute.

3.10.  Digest-Entity-Body-Hash Attribute

   Description
         When using the qop-level ’auth-int’, a hash of the HTTP-style
         message body’s contents is required for digest calculation.
         Instead of sending the complete body of the message, only its
         hash value is sent.  This hash value can be used directly in
         the digest calculation.

         The clarifications described in section 22.4 of [RFC3261] about
         the hash of empty entity bodies apply to the
         Digest-Entity-Body-Hash attribute.  This attribute MUST only be
         sent in Access-Request packets.
   Type
         112 for Digest-Entity-Body-Hash
   Length
         >=3
   Text
         The attribute holds the hexadecimal representation of
         H(entity-body).  This hash is required by certain
         authentication mechanisms, such as HTTP Digest with quality of
         protection set to "auth-int".  RADIUS clients MUST use this
         attribute to transport the hash of the entity body when HTTP
         Digest is the authentication mechanism and the RADIUS server

         requires that the integrity of the entity body (e.g., qop
         parameter set to "auth-int") be verified.  Extensions to this
         document may define support for authentication mechanisms other
         than HTTP Digest.

3.11.  Digest-CNonce Attribute

   Description
         This attribute holds the client nonce parameter that is used in
         the HTTP Digest calculation.  It MUST only be used in
         Access-Request packets.
   Type
         113 for Digest-CNonce
   Length
         >=3
   Text
         This attribute includes the value of the cnonce-value [RFC2617]
         without surrounding quotes, taken from the HTTP-style request.

3.12.  Digest-Nonce-Count Attribute

   Description
         This attribute includes the nonce count parameter that is used
         to detect replay attacks.  The attribute MUST only be used in
         Access-Request packets.

   Type
         114 for Digest-Nonce-Count
   Length
         10
   Text
         In Access-Requests, the RADIUS client takes the value of the nc
         directive (nc-value according to [RFC2617]) without surrounding
         quotes from the HTTP-style request it wants to authenticate.

3.13.  Digest-Username Attribute

   Description
         This attribute holds the user name used in the HTTP Digest
         calculation.  The RADIUS server MUST use this attribute only
         for the purposes of calculating the digest.  In order to
         determine the appropriate user credentials, the RADIUS server
         MUST use the User-Name (1) attribute, and MUST NOT use the
         Digest-Username attribute.  This attribute MUST only be used in
         Access-Request packets.
   Type
         115 for Digest-Username

   Length
         >= 3
   Text
         In Access-Requests, the RADIUS client takes the value of the
         username directive (username-value according to [RFC2617])
         without surrounding quotes from the HTTP-style request it wants
         to authenticate.

3.14.  Digest-Opaque Attribute

   Description
         This attribute holds the opaque parameter that is passed to the
         HTTP-style client.  The HTTP-style client will pass this value
         back to the server (i.e., the RADIUS client) without
         modification.  This attribute MUST only be used in
         Access-Request and Access-Challenge packets.
   Type
         116 for Digest-Opaque
   Length
         >=3
   Text
         In Access-Requests, the RADIUS client takes the value of the
         opaque directive (opaque-value according to [RFC2617]) without
         surrounding quotes from the HTTP-style request it wants to
         authenticate and puts it into this attribute.  In
         Access-Challenge packets, the RADIUS server MAY include this
         attribute.

3.15.  Digest-Auth-Param Attribute

   Description
         This attribute is a placeholder for future extensions and
         corresponds to the "auth-param" parameter defined in section
         3.2.1 of [RFC2617].  The Digest-Auth-Param is the mechanism
         whereby the RADIUS client and RADIUS server can exchange
         auth-param extension parameters contained within Digest headers
         that are not understood by the RADIUS client and for which
         there are no corresponding stand-alone attributes.

         Unlike the previously listed Digest-* attributes, the
         Digest-Auth-Param contains not only the value but also the
         parameter name, since the parameter name is unknown to the
         RADIUS client.  If the Digest header contains several unknown
         parameters, then the RADIUS implementation MUST repeat this
         attribute and each instance MUST contain one different unknown
         Digest parameter/value combination.  This attribute MUST ONLY
         be used in Access-Request, Access-Challenge, or Access-Accept
         packets.

   Type
         117 for Digest-Auth-Param
   Length
         >=3
   Text
         The text consists of the whole parameter, including its name
         and the equal sign (’=’) and quotes.

3.16.  Digest-AKA-Auts Attribute

   Description
         This attribute holds the auts parameter that is used in the
         Digest AKA ([RFC3310]) calculation.  It is only used if the
         algorithm of the digest-response denotes a version of AKA
         Digest [RFC3310].  This attribute MUST only be used in
         Access-Request packets.
   Type
         118 for Digest-AKA-Auts
   Length
         >=3
   Text
         In Access-Requests, the RADIUS client takes the value of the
         auts directive (auts-param according to section 3.4 of
         [RFC3310]) without surrounding quotes from the HTTP-style
         request it wants to authenticate.

3.17.  Digest-Domain Attribute

   Description
         When a RADIUS client has asked for a nonce, the RADIUS server
         MAY send one or more Digest-Domain attributes in its
         Access-Challenge packet.  The RADIUS client puts them into the
         quoted, space-separated list of URIs of the ’domain’ directive
         of a WWW-Authenticate header.  Together with Digest-Realm, the
         URIs in the list define the protection space (see [RFC2617],
         section 3.2.1) for some HTTP-style protocols.  This attribute
         MUST only be used in Access-Challenge packets.
   Type
         119 for Digest-Domain
   Length
         3
   Text
         This attribute consists of a single URI that defines a
         protection space component.

3.18.  Digest-Stale Attribute

   Description
         This attribute is sent by a RADIUS server in order to notify
         the RADIUS client whether it has accepted a nonce.  If the
         nonce presented by the RADIUS client was stale, the value is
         ’true’ and is ’false’ otherwise.  The RADIUS client puts the
         content of this attribute into a ’stale’ directive of the
         WWW-Authenticate header in the HTTP-style response to the
         request it wants to authenticate.  The attribute MUST only be
         used in Access-Challenge packets.
   Type
         120 for Digest-Stale
   Length
         3
   Text
         The attribute has either the value ’true’ or ’false’ (both
         values without surrounding quotes).

3.19.  Digest-HA1 Attribute

   Description
         This attribute is used to allow the generation of an
         Authentication-Info header, even if the HTTP-style response’s
         body is required for the calculation of the rspauth value.  It
         SHOULD be used in Access-Accept packets if the required quality
         of protection (’qop’) is ’auth-int’.

         This attribute MUST NOT be sent if the qop parameter was not
         specified or has a value of ’auth’ (in this case, use
         Digest-Response-Auth instead).

         The Digest-HA1 attribute MUST only be sent by the RADIUS server
         or processed by the RADIUS client if at least one of the
         following conditions is true:

         +  The Digest-Algorithm attribute’s value is ’MD5-sess’ or
            ’AKAv1-MD5-sess’.

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

         This attribute MUST only be used in Access-Accept packets.
   Type
         121 for Digest-HA1
   Length
         >= 3

   Text
         This attribute contains the hexadecimal representation of H(A1)
         as described in [RFC2617], sections 3.1.3, 3.2.1, and 3.2.2.2.

3.20.  SIP-AOR Attribute

   Description
         This attribute is used for the authorization of SIP messages.
         The SIP-AOR attribute identifies the URI, the use of which must
         be authenticated and authorized.  The RADIUS server uses this
         attribute to authorize the processing of the SIP request.  The
         SIP-AOR can be derived from, for example, the To header field
         in a SIP REGISTER request (user under registration), or the
         From header field in other SIP requests.  However, the exact
         mapping of this attribute to SIP can change due to new
         developments in the protocol.  This attribute MUST only be used
         when the RADIUS client wants to authorize SIP users and MUST
         only be used in Access-Request packets.
   Type
         122 for SIP-AOR
   Length
         >=3
   Text
         The syntax of this attribute corresponds either to a SIP URI
         (with the format defined in [RFC3261] or a tel URI (with the
         format defined in [RFC3966]).

         The SIP-AOR attribute holds the complete URI, including
         parameters and other parts.  It is up to the RADIUS server what
         components of the URI are regarded in the authorization
         decision.

4.  Diameter Compatibility

   This document defines support for Digest Authentication in RADIUS.  A
   companion document "Diameter Session Initiation Protocol (SIP)
   Application" [SIP-APP] defines support for Digest Authentication in
   Diameter, and addresses compatibility issues between RADIUS and
   Diameter.

5.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity.

   +-----+--------+--------+-----------+-----+-------------------------+
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容