rfc4590.txt

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

Network Working Group                                         B. Sterman
Request for Comments: 4590                               Kayote Networks
Category: Standards Track                                  D. Sadolevsky
                                                          SecureOL, Inc.
                                                             D. Schwartz
                                                         Kayote Networks
                                                             D. Williams
                                                           Cisco Systems
                                                                 W. Beck
                                                     Deutsche Telekom AG
                                                               July 2006


               RADIUS Extension for Digest Authentication

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines an extension to the Remote Authentication
   Dial-In User Service (RADIUS) protocol to enable support of Digest
   Authentication, for use with HTTP-style protocols like the Session
   Initiation Protocol (SIP) and HTTP.

Table of Contents

1. Introduction ....................................................2
   1.1. Terminology ................................................2
   1.2. Motivation .................................................3
   1.3. Overview ...................................................4
2. Detailed Description ............................................6
   2.1. RADIUS Client Behavior .....................................6
        2.1.1. Credential Selection ................................6
        2.1.2. Constructing an Access-Request ......................6
        2.1.3. Constructing an Authentication-Info Header ..........7
        2.1.4. Failed Authentication ...............................8
        2.1.5. Obtaining Nonces ....................................9
   2.2. RADIUS Server Behavior .....................................9



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


        2.2.1. General Attribute Checks ............................9
        2.2.2. Authentication .....................................10
        2.2.3. Constructing the Reply .............................11
3. New RADIUS Attributes ..........................................12
   3.1. Digest-Response attribute .................................12
   3.2. Digest-Realm Attribute ....................................13
   3.3. Digest-Nonce Attribute ....................................13
   3.4. Digest-Response-Auth Attribute ............................14
   3.5. Digest-Nextnonce Attribute ................................14
   3.6. Digest-Method Attribute ...................................14
   3.7. Digest-URI Attribute ......................................15
   3.8. Digest-Qop Attribute ......................................15
   3.9. Digest-Algorithm Attribute ................................16
   3.10. Digest-Entity-Body-Hash Attribute ........................16
   3.11. Digest-CNonce Attribute ..................................17
   3.12. Digest-Nonce-Count Attribute .............................17
   3.13. Digest-Username Attribute ................................17
   3.14. Digest-Opaque Attribute ..................................18
   3.15. Digest-Auth-Param Attribute ..............................18
   3.16. Digest-AKA-Auts Attribute ................................19
   3.17. Digest-Domain Attribute ..................................19
   3.18. Digest-Stale Attribute ...................................20
   3.19. Digest-HA1 Attribute .....................................20
   3.20. SIP-AOR Attribute ........................................21
4. Diameter Compatibility .........................................21
5. Table of Attributes ............................................22
6. Examples .......................................................23
7. IANA Considerations ............................................27
8. Security Considerations ........................................27
   8.1. Denial of Service .........................................28
   8.2. Confidentiality and Data Integrity ........................28
9. Acknowledgements ...............................................29
10. References ....................................................29
   10.1. Normative References .....................................29
   10.2. Informative References ...................................30

1.  Introduction

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The use of normative requirement key words in this document shall
   apply only to RADIUS client and RADIUS server implementations that
   include the features described in this document.  This document
   creates no normative requirements for existing implementations.



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


   HTTP-style protocol
         The term 'HTTP-style' denotes any protocol that uses HTTP-like
         headers and uses HTTP Digest Authentication as described in
         [RFC2617].  Examples are HTTP and the Session Initiation
         Protocol (SIP).

   NAS
         Network Access Server, the RADIUS client.

   nonce
         An unpredictable value used to prevent replay attacks.  The
         nonce generator may use cryptographic mechanisms to produce
         nonces it can recognize without maintaining state.

   protection space
         HTTP-style protocols differ in their definition of the
         protection space.  For HTTP, it is defined as the combination
         of realm and canonical root URL of the requested resource for
         which the use is authorized by the RADIUS server.  In the case
         of SIP, the realm string alone defines the protection space.

   SIP UA
         SIP User Agent, an Internet endpoint that uses the Session
         Initiation Protocol.

   SIP UAS
         SIP User Agent Server, a logical entity that generates a
         response to a SIP (Session Initiation Protocol) request.

1.2.  Motivation

   The HTTP Digest Authentication mechanism, defined in [RFC2617], was
   subsequently adapted for use with SIP [RFC3261].  Due to the
   limitations and weaknesses of Digest Authentication (see [RFC2617],
   section 4), additional authentication and encryption mechanisms are
   defined in SIP [RFC3261], including Transport Layer Security (TLS)
   [RFC4346] and Secure MIME (S/MIME) [RFC3851].  However, Digest
   Authentication support is mandatory in SIP implementations, and
   Digest Authentication is the preferred way for a SIP UA to
   authenticate itself to a proxy server.  Digest Authentication is used
   in other protocols as well.

   To simplify the provisioning of users, there is a need to support
   this authentication mechanism within Authentication, Authorization,
   and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter
   [RFC3588].





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


   This document defines an extension to the RADIUS protocol to enable
   support of Digest Authentication for use with SIP, HTTP, and other
   HTTP-style protocols using this authentication method.  Support for
   Digest mechanisms such as Authentication and Key Agreement (AKA)
   [RFC3310] is also supported.  A companion document [SIP-APP] defines
   support for Digest Authentication within Diameter.

1.3.  Overview

   HTTP Digest is a challenge-response protocol used to authenticate a
   client's request to access some resource on a server.  Figure 1 shows
   a single HTTP Digest transaction.

                                 HTTP/SIP..
                  +------------+  (1)     +------------+
                  |            |--------->|            |
                  | HTTP-style |  (2)     | HTTP-style |
                  | client     |<---------| server     |
                  |            |  (3)     |            |
                  |            |--------->|            |
                  |            |  (4)     |            |
                  |            |<---------|            |
                  +------------+          +------------+

                 Figure 1: Digest operation without RADIUS

   If the client sends a request without any credentials (1), the server
   will reply with an error response (2) containing a nonce.  The client
   creates a cryptographic digest from parts of the request, from the
   nonce it received from the server, and from a shared secret.  The
   client re-transmits the request (3) to the server, but now includes
   the digest within the packet.  The server does the same digest
   calculation as the client and compares the result with the digest it
   received in (3).  If the digest values are identical, the server
   grants access to the resource and sends a positive response to the
   client (4).  If the digest values differ, the server sends a negative
   response to the client (4).

   Instead of maintaining a local user database, the server could use
   RADIUS to access a centralized user database.  However, RADIUS
   [RFC2865] does not include support for HTTP Digest Authentication.
   The RADIUS client cannot use the User-Password attribute, since it
   does not receive a password from the HTTP-style client.  The
   CHAP-Challenge and CHAP-Password attributes described in [RFC1994]
   are also not suitable since the CHAP algorithm is not compatible with
   HTTP Digest.





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


   This document defines new attributes that enable the RADIUS server to
   perform the digest calculation defined in [RFC2617], providing
   support for Digest Authentication as a native authentication
   mechanism within RADIUS.

   The nonces required by the digest algorithm are generated by the
   RADIUS server.  Generating them in the RADIUS client would save a
   round-trip, but introduce security and operational issues.  Some
   digest algorithms -- e.g., AKA [RFC3310] -- would not work.

   Figure 2 depicts a scenario in which the HTTP-style server defers
   authentication to a RADIUS server.  Entities A and B communicate
   using HTTP or SIP, while entities B and C communicate using RADIUS.

                        HTTP/SIP           RADIUS

               +-----+    (1)    +-----+           +-----+
               |     |==========>|     |    (2)    |     |
               |     |           |     |---------->|     |
               |     |           |     |    (3)    |     |
               |     |    (4)    |     |<----------|     |
               |     |<==========|     |           |     |
               |     |    (5)    |     |           |     |
               |     |==========>|     |           |     |
               |  A  |           |  B  |    (6)    |  C  |
               |     |           |     |---------->|     |
               |     |           |     |    (7)    |     |
               |     |           |     |<----------|     |
               |     |    (8)    |     |           |     |
               |     |<==========|     |           |     |
               +-----+           +-----+           +-----+

               ====> HTTP/SIP
               ----> RADIUS

                    Figure 2: HTTP Digest over RADIUS

   The entities have the following roles:

   A: HTTP client / SIP UA

   B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
      acting also as a RADIUS NAS

   C: RADIUS server






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


   The following messages are sent in this scenario:

   A sends B an HTTP/SIP request without an authorization header (step
   1).  B sends an Access-Request packet with the newly defined
   Digest-Method and Digest-URI attributes but without a Digest-Nonce
   attribute to the RADIUS server, C (step 2).  C chooses a nonce and
   responds with an Access-Challenge (step 3).  This Access-Challenge
   contains Digest attributes, from which B takes values to construct an
   HTTP/SIP "(Proxy) Authorization required" response.  B sends this
   response to A (step 4).  A resends its request with its credentials
   (step 5).  B sends an Access-Request to C (step 6).  C checks the
   credentials and replies with Access-Accept or Access-Reject (step 7).
   Depending on C's result, B processes A's request or rejects it with a
   "(Proxy) Authorization required" response (step 8).

2.  Detailed Description

2.1.  RADIUS Client Behavior

   The attributes described in this document are sent in cleartext.
   Therefore, were a RADIUS client to accept secure connections (HTTPS
   or SIPS) from HTTP-style clients, this could result in information
   intentionally protected by HTTP-style clients being sent in the clear
   during RADIUS exchange.

2.1.1.  Credential Selection

   On reception of an HTTP-style request message, the RADIUS client
   checks whether it is authorized to authenticate the request.  Where
   an HTTP-style request traverses several proxies and each of the
   proxies requests to authenticate the HTTP-style client, the request
   at the HTTP-style server may contain multiple credential sets.

   The RADIUS client can use the 'realm' directive in HTTP to determine
   which credentials are applicable.  Where none of the realms are of
   interest, the RADIUS client MUST behave as though no relevant
   credentials were sent.  In all situations, the RADIUS client MUST
   send zero or exactly one credential to the RADIUS server.  The RADIUS
   client MUST choose the credential of the (Proxy-)Authorization header
   if the realm directive matches its locally configured realm.

2.1.2.  Constructing an Access-Request

   If a matching (Proxy-)Authorization header is present and contains
   HTTP Digest information, the RADIUS client checks the 'nonce'
   parameter.





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


   If the RADIUS client recognizes the nonce, it takes the header
   directives and puts them into a RADIUS Access-Request packet.  It
   puts the 'response' directive into a Digest-Response attribute and
   the realm, nonce, digest-uri, qop, algorithm, cnonce, nc, username,
   and opaque directives into the respective Digest-Realm, Digest-Nonce,
   Digest-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce,
   Digest-Nonce-Count, Digest-Username, and Digest-Opaque attributes.
   The RADIUS client puts the request method into the Digest-Method
   attribute.