[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 rfc4590                         
Network Working Group                                         B. Sterman
Internet-Draft                                           Kayote Networks
Expires: June 8, 2005                                      D. Sadolevsky
                                                          SecureOL, Inc.
                                                             D. Schwartz
                                                         Kayote Networks
                                                             D. Williams
                                                           Cisco Systems
                                                                 W. Beck
                                                     Deutsche Telekom AG
                                                        December 8, 2004


               RADIUS Extension for Digest Authentication
                  draft-ietf-radext-digest-auth-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 8, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract




Sterman, et al.           Expires June 8, 2005                  [Page 1]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


   Several protocols borrow the authentication mechanisms from the
   Hypertext Transfer Protocol, HTTP.  This document specifies an
   extension to RADIUS that allows a RADIUS client in an HTTP-style
   server, upon reception of a request, retrieve and compute Digest
   authentication information from a RADIUS server.  Additionally, a
   scenario describing  the authentication of a user emitting an
   HTTP-style request is provided.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2   Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.3.1   Scenario 1, RADIUS client chooses nonces . . . . . . .  6
       1.3.2   Scenario 2, RADIUS server chooses nonces . . . . . . .  7
   2.  New RADIUS attributes  . . . . . . . . . . . . . . . . . . . .  9
     2.1   Digest-Response attribute  . . . . . . . . . . . . . . . .  9
     2.2   Digest-Realm attribute . . . . . . . . . . . . . . . . . .  9
     2.3   Digest-Nonce attribute . . . . . . . . . . . . . . . . . . 10
     2.4   Digest-Response-Auth attribute . . . . . . . . . . . . . . 10
     2.5   Digest-Nextnonce attribute . . . . . . . . . . . . . . . . 11
     2.6   Digest-Method attribute  . . . . . . . . . . . . . . . . . 11
     2.7   Digest-URI attribute . . . . . . . . . . . . . . . . . . . 11
     2.8   Digest-Qop attribute . . . . . . . . . . . . . . . . . . . 12
     2.9   Digest-Algorithm attribute . . . . . . . . . . . . . . . . 12
     2.10  Digest-Entity-Body-Hash attribute  . . . . . . . . . . . . 12
     2.11  Digest-CNonce attribute  . . . . . . . . . . . . . . . . . 13
     2.12  Digest-Nonce-Count attribute . . . . . . . . . . . . . . . 13
     2.13  Digest-Username attribute  . . . . . . . . . . . . . . . . 14
     2.14  Digest-Opaque attribute  . . . . . . . . . . . . . . . . . 14
     2.15  Digest-Auth-Param attribute  . . . . . . . . . . . . . . . 14
     2.16  Digest-AKA-Auts attribute  . . . . . . . . . . . . . . . . 15
     2.17  Digest-Domain attribute  . . . . . . . . . . . . . . . . . 15
     2.18  Digest-Stale attribute . . . . . . . . . . . . . . . . . . 16
     2.19  Digest-HA1 attribute . . . . . . . . . . . . . . . . . . . 16
   3.  Detailed Description . . . . . . . . . . . . . . . . . . . . . 18
     3.1   RADIUS Client Behavior . . . . . . . . . . . . . . . . . . 18
     3.2   RADIUS Server Behavior . . . . . . . . . . . . . . . . . . 20
   4.  Migration Path to Diameter . . . . . . . . . . . . . . . . . . 22
     4.1   RADIUS Client, Diameter Server . . . . . . . . . . . . . . 22
     4.2   Diameter Client, RADIUS Server . . . . . . . . . . . . . . 23
     4.3   Limitations  . . . . . . . . . . . . . . . . . . . . . . . 23
   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   8.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     8.1   Changes from draft-sterman-aaa-sip-04  . . . . . . . . . . 29



Sterman, et al.           Expires June 8, 2005                  [Page 2]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


     8.2   Changes from draft-sterman-aaa-sip-03  . . . . . . . . . . 29
     8.3   Changes from draft-sterman-aaa-sip-02  . . . . . . . . . . 29
     8.4   Changes from draft-sterman-aaa-sip-01  . . . . . . . . . . 29
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 30
   9.2   Informative References . . . . . . . . . . . . . . . . . . . 30
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 34
       Intellectual Property and Copyright Statements . . . . . . . . 35










































Sterman, et al.           Expires June 8, 2005                  [Page 3]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


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].

   This document uses terminology from [RFC2617] and [RFC2865]

1.2  Motivation

   Digest authentication is a simple authentication mechanism for HTTP
   and SIP.  While it was not too successful in HTTP environments, it is
   the only SIP authentication mechanism that has been widely adopted.
   Due to the limitations and weaknesses of Digest authentication (see
   [RFC2617], section 4), additional PKI-based authentication and
   encryption mechanisms have been introduced into SIP: TLS [RFC2246]
   and S/MIME [RFC2633].  The majority of today's SIP clients only
   supports HTTP digest.

   Current RADIUS-based AAA infrastructures have been built and debugged
   over years.  Some deficiencies of RADIUS have been mitigated with
   proprietary extensions.  Operators are therefore reluctant to replace
   their RADIUS infrastructure in order to enable a single new
   authentication mechanism.

   Given the complexity of the alternatives, simple clients will
   continue to support HTTP digest authentication only.  Its
   interoperability with a back-end authentication protocol such as
   RADIUS is needed.

   Operators that are about to replace their RADIUS-based AAA
   infrastructure are strongly recommended to use Diameter.

1.3  Overview

   Figure 1 depicts the basic scenario that is relevant for this
   document.  'HTTP-style Client' and 'RADIUS Client' are entities using
   a protocol with support for HTTP Digest Authentication, like SIP or
   HTTP.










Sterman, et al.           Expires June 8, 2005                  [Page 4]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


                     HTTP/SIP            RADIUS
         +------------+          +--------+         +--------+
         | HTTP-style |          | RADIUS |         | RADIUS |
         | Client     |<========>| Client |<------->| Server |
         |            |          |        |         |        |
         +------------+          +--------+         +--------+




                    Figure 1: Overview of operation

   The approach taken here is to extend RADIUS to support Digest
   authentication by mimicking its native support for CHAP
   authentication.  According to [RFC2865], the RADIUS server
   distinguishes between different authentication schemes by looking at
   the presence of an attribute specific for that scheme.  For the three
   natively supported authentication schemes, these attributes are:
   User-Password for PAP (or any other clear-text password scheme),
   CHAP-Password for CHAP, and State + User- Password for
   challenge-response scheme.  This document adds another attribute to
   be used in this role: Digest-Response.  Also according to [RFC2865],
   "An Access-Request packet MUST contain either a User-Password or a
   CHAP-Password or a State.  It 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 instead of User-Password or CHAP-Password." The
   Digest-Response introduced here therefore can be used instead of
   User-Password or CHAP-Password.

   The HTTP Authentication parameters found in the Proxy-Authorization
   or Authorization request header are mapped into newly defined RADIUS
   attributes.  These new RADIUS attributes are defined in the document
   together with some other information required for calculating the
   correct digest response on the RADIUS server with exception of the
   password, which the RADIUS server is assumed to be able to retrieve
   from a data store given the username.

   The nonces required by the digest algorithm are either generated by
   the RADIUS client or by the RADIUS server.  A mix of nonce generation
   modes is not supported.  If the RADIUS server generates nonces, all
   RADIUS clients MUST NOT try to generate nonces.  If the RADIUS server
   does not generate nonces, all RADIUS clients MUST generate nonces
   locally.  If at least one HTTP-style client requires AKA
   authentication [RFC3310], the RADIUS server MUST generate nonces and
   its RADIUS clients MUST NOT generate nonces locally.





Sterman, et al.           Expires June 8, 2005                  [Page 5]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


1.3.1  Scenario 1, RADIUS client chooses nonces





                     HTTP/SIP           RADIUS

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

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



                 Figure 2: RADIUS client chooses nonces

   The roles played by the entities in this scenario are as follows:

   A: HTTP client / SIP UA

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

   C: RADIUS server

   The relevant order of messages sent in this scenario is as follows:

   A sends B an HTTP/SIP request without authorization header (step 1).
   B challenges A sending an HTTP/SIP "407 / 401 (Proxy)  Authorization
   required" response containing a locally generated nonce (step 2).  A
   sends B an HTTP/SIP request with authorization header (step 3).  B
   sends C a RADIUS Access-Request with attributes described in this
   document (step 4).  C responds to B with a RADIUS
   Access-Accept/Access-Reject response (step 5).  If credentials were
   accepted B receives an Access-Accept response and the message sent



Sterman, et al.           Expires June 8, 2005                  [Page 6]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


   from A is considered authentic.  If B receives an Access-Reject
   response, however, B then responds to  A with a "407 / 401 (Proxy)
   Authorization required" response (step 6).

1.3.2  Scenario 2, RADIUS server chooses nonces

   In most cases, the operation outlined in Section 1.3.1 is sufficient.
   It reduces the load on the RADIUS server to a minimum.  However, when
   using AKA [RFC3310] the nonce is partially derived from a precomputed
   authentication vector.  These authentication vectors are often stored
   centrally.

   Figure 3 depicts a scenario, where the RADIUS server chooses nonces.
   It shows a generic case where entities A and B communicate in the
   front-end using protocols such as HTTP/SIP, while entities B and C
   communicate in the back-end using RADIUS.





                     HTTP/SIP           RADIUS

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

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



                 Figure 3: RADIUS server chooses nonces

   The roles played by the entities in this scenario are as follows:




Sterman, et al.           Expires June 8, 2005                  [Page 7]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


   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

   The relevant order of messages sent in this scenario is as follows:

   A sends B an HTTP/SIP request without authorization header (step 1).
   B sends an Access-Request message 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.  The remaining
   steps are identical with scenario 1 (Section 1.3.1): 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).
   Dependent on the C's result, B processes A's request or rejects it
   with a "(Proxy) Authorization required" response (step 8).





























Sterman, et al.           Expires June 8, 2005                  [Page 8]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


2.  New RADIUS attributes

   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 SIP.

   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       | String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




2.1  Digest-Response attribute

   If this attribute is present in an Access-Request message, the RADIUS
   server SHOULD view the Access-Request as a Digest one.  When a RADIUS
   client receives a (Proxy-)Authorization header, it puts the
   request-digest value into a Digest-Response attribute.

   Type
         [IANA: use 102 if possible] for Digest-Response.
   Length
         >= 34
   Text
         This attribute MUST only be used in Access-Requests.  It proves
         the user knows the password.  The text field is usually 32
         octets long and contains hexadecimal representation of 16 octet
         digest value as it was calculated by the authenticated client.
         The text field SHOULD be copied from request-digest of
         digest-response ([RFC2617]) without quotes.

2.2  Digest-Realm attribute

   This attribute describes a protection space of the RADIUS server.
   See [RFC2617] 1.2 for details.

   Type






Sterman, et al.           Expires June 8, 2005                  [Page 9]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


         [IANA: use 103 if possible] 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
         quotes from the HTTP-style request it wants to authenticate.
         In Access-Challenge messages, the RADIUS server puts the
         expected realm value into this attribute.  This attribute MUST
         only be used in Access-Request and Access-Challenge messages.

2.3  Digest-Nonce attribute

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

   Type
         [IANA: use 104 if possible] for Digest-Nonce
   Length
         >=3
   Text
         In Access-Requests, the RADIUS client takes the value of the
         nonce directive (nonce-value in [RFC2617]) without quotes from
         the HTTP-style request it wants to authenticate.  If the
         Access-Request had a Digest-Method and a Digest-URI but no
         Digest-Nonce attribute and the RADIUS server is configured to
         choose nonces, it MUST put a Digest-Nonce attribute into its
         Access-Challenge message.  This attribute MUST only be used in
         Access-Request and Access-Challenge messages.

2.4  Digest-Response-Auth attribute

   Type
         [IANA: use 105 if possible] for Digest-Response-Auth.
   Length
         >= 34
   Text
         This attribute MUST only be used in Access-Accept messages.
         This text proves the RADIUS server knows the password.  The
         RADIUS server calculates a digest according to section 3.2.3 of
         [RFC2617] and copies the result into this attribute.  The
         RADIUS client puts the attribute value without quotes into the
         rspauth directive of the Authentication-Info header.  If the
         previously received Digest-Qop attribute was 'auth-int'
         (without quotes), the RADIUS server MUST send a Digest-HA1
         attribute instead of Digest-Response-Auth.





Sterman, et al.           Expires June 8, 2005                 [Page 10]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


2.5  Digest-Nextnonce attribute

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

   Type
         [IANA: use 106 if possible] for Digest-Nextnonce
   Length
         >=3
   Text
         If the RADIUS server is configured to choose nonces it MAY put
         a Digest-Nextnonce attribute into an Access-Accept message.  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 messages.

2.6  Digest-Method attribute

   This attribute holds the method string to be used in the HTTP Digest
   calculation.

   Type
         [IANA: use 107 if possible] 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.  This attribute MUST only be used in
         Access-Request messages.

2.7  Digest-URI attribute

   This attribute holds the URI string to be used in the HTTP Digest
   calculation.

   Type
         [IANA: use 108 if possible] 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 in the
         (known as "digest-uri-value" in Section 3.2.2 of [RFC2617])
         without 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



Sterman, et al.           Expires June 8, 2005                 [Page 11]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


         authenticate.  The attribute MUST only be used in
         Access-Request messages.

2.8  Digest-Qop attribute

   This attribute holds the Quality of Protection parameter that
   influences the HTTP Digest calculation.

   Type
         [IANA: use 109 if possible] 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]) without the
         quotes from the HTTP-style request it wants to authenticate.
         If the directive contains more than one qop-value, the RADIUS
         client puts each qop-value into a separate Digest-Qop
         attribute.  In Access-Challenge messages, the RADIUS server
         SHOULD put the desired qop-value into this attribute.  This
         attribute MUST only be used in Access-Request and
         Access-Challenge messages.

2.9  Digest-Algorithm attribute

   This attribute holds the algorithm parameter that influences the HTTP
   Digest calculation.

   Type
         [IANA: use 110 if possible] 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)
         without the quotes from the HTTP-style request it wants to
         authenticate.  In Access-Challenge messages, the RADIUS server
         MAY put the desired algorithm into this attribute.  This
         attribute MUST only be used in Access-Request and
         Access-Challenge messages.

2.10  Digest-Entity-Body-Hash attribute

   When using the qop level 'auth-int', a hash of the 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.




Sterman, et al.           Expires June 8, 2005                 [Page 12]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


   Type
         [IANA: use 111 if possible] for Digest-Entity-Body-Hash
   Length
         >=34
   String
         The Digest-Entity-Body-Hash attribute contains a hash of the
         entity body contained in the SIP message.  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 to verify the integrity of the
         entity body (e.g., qop parameter set to "auth-int").
         Extensions to this document may define support for
         authentication mechanisms other than HTTP Digest.
         The clarifications described in Section 22.4 of [RFC2617] 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.

2.11  Digest-CNonce attribute

   This attribute holds the client nonce parameter that is used in the
   HTTP Digest calculation.

   Type
         [IANA: use 112 if possible] for Digest-CNonce
   Length
         >=3
   Text
         In Access-Requests, the RADIUS client takes the value of the
         cnonce directive (cnonce-value according to [RFC2617]) without
         quotes from the HTTP-style request it wants to authenticate.
         This attribute MUST only be used in Access-Request messages.

2.12  Digest-Nonce-Count attribute

   This attribute holds the nonce count parameter that is used to detect
   replay attacks.

   Type
         [IANA: use 113 if possible] for Digest-Nonce-Count
   Length
         10
   Text






Sterman, et al.           Expires June 8, 2005                 [Page 13]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


         In Access-Requests, the RADIUS client takes the value of the nc
         directive (nc-value according to [RFC2617]) without quotes from
         the HTTP-style request it wants to authenticate.  The attribute
         MUST only be used in Access-Request messages.

2.13  Digest-Username attribute

   This attribute holds the user name parameter that is used in the HTTP
   digest calculation.

   Type
         [IANA: use 114 if possible] 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 quotes from the HTTP-style request it wants to
         authenticate.  The RADIUS server SHOULD NOT use this value for
         password finding, but only for digest calculation purpose.  In
         order to find the user record containing the password, the
         RADIUS server SHOULD use the value of the ([RFC2865]
         -)User-Name attribute.  This attribute MUST only be used in
         Access-Request packets.

2.14  Digest-Opaque attribute

   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 (ie the RADIUS client) without modification.

   Type
         [IANA: use 115 if possible] for Digest-Opaque
   Length
         >=3
   Text
         This attribute is only used when the RADIUS server chooses
         nonces.  In Access-Requests, the RADIUS client takes the value
         of the opaque directive (opaque-value according to [RFC2617])
         without quotes from the HTTP-style request it wants to
         authenticate and puts it into this attribute.  In
         Access-Challenge messages, the RADIUS server MAY include this
         attribute.  This attribute MUST only be used in Access-Request
         and Access-Challenge messages.

2.15  Digest-Auth-Param attribute

   This attribute is a placeholder for future extensions.



Sterman, et al.           Expires June 8, 2005                 [Page 14]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


   Type
         [IANA: use 116 if possible] for Digest-Auth-Param
   Length
         >=3
   Text
         The Digest-Auth-Param is the mechanism whereby the RADIUS
         client and RADIUS server can exchange possible extension
         parameters contained in 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 corresponds to the "auth-param" parameter defined in
         section 3.2.1 of [RFC2617].
         The text consists of the whole parameter, including its name
         and the equal ('=') sign and quotes.  This attribute MAY be
         used in any type of RADIUS messages.

2.16  Digest-AKA-Auts attribute

   This attribute holds the auts parameter that is used in the Digest
   AKA ([RFC3310]) calculation.

   Type
         [IANA: use 117 if possible] 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 quotes from the HTTP-style request it wants
         to authenticate.  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 messages.

2.17  Digest-Domain attribute

   When a RADIUS client has asked for a nonce, the RADIUS server MAY
   send one or more Digest-Domain attributes in its Access-Challenge
   message.  The RADIUS client puts them into the quoted,
   space-separated list of URIs of the 'domain' directive of a
   WWW-Authenticate header.  The URIs in the list define the protection
   space (see [RFC2617], section 3.2.1).




Sterman, et al.           Expires June 8, 2005                 [Page 15]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


   Type
         [IANA: use 118 if possible] for Digest-Domain
   Length
         3
   Text
         This attribute consists of a single URI, that defines a
         protection space.  RADIUS servers MAY send one or more
         attributes of this type in Access-Challenge messages.  This
         attribute MUST only be used in Access-Challenge messages.

2.18  Digest-Stale attribute

   The RADIUS server uses this attribute to tell whether it has accepted
   a nonce.

   Type
         [IANA: use 119 if possible] for Digest-Stale
   Length
         3
   Text
         The attribute has either the value 'true' or 'false' (both
         values without quotes).  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 messages
         and only if the RADIUS server chooses nonces.

2.19  Digest-HA1 attribute

   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.

   Type
         [IANA: use 120 if possible] for Digest-HA1
   Length
         >= 34
   Text
         This attribute contains the hexadecimal representation of H(A1)
         as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2.
         It SHOULD be used in Access-Accept messages 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).




Sterman, et al.           Expires June 8, 2005                 [Page 16]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


         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'.
         +  The authenticity and integrity of the Access-Accept message
            is secured by cryptographic or equivalently secure means.
         This attribute MUST only be used in Access-Accept messages.











































Sterman, et al.           Expires June 8, 2005                 [Page 17]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


3.  Detailed Description

3.1  RADIUS Client Behavior

   If a RADIUS client has no encrypted or otherwise secured connection
   to its RADIUS server, it MUST NOT accept secured connections (like
   https or sips) from its HTTP-style clients (or else the HTTP-style
   clients would have a false sense of security).

   On reception of an HTTP-style request message, the RADIUS client
   looks for a (Proxy-)Authorization header where the realm directive
   matches its locally configured realm value.  If such a header is
   present and contains HTTP digest information, the RADIUS client
   checks the 'nonce' parameter.  If the RADIUS client generates nonces
   but did not issue the received nonce, it responds with a 401
   (Unauthorized) or 407 (Proxy Authentication Required) to the
   HTTP-style client.  In this error response, the RADIUS client sends a
   new nonce.

   If the RADIUS client recognizes the nonce or does not generate
   nonces, it takes the header directives and puts them into a RADIUS
   Access-Request message.  It puts the 'response' directive into a
   Digest-Response attribute and the realm / nonce / digest-uri / qop /
   algorithm / cnonce / nc / username / opaque directives into the
   respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop /
   Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count /
   Digest-Username / Digest-Opaque attributes.  The request method is
   put into the Digest-Method attribute.  Now, the RADIUS client sends
   the Access-Request message to the RADIUS server.

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

   The RADIUS client constructs an Authentication-Info header:
   o  If the Access-Accept message 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 message and behaves like it
         had received an Access-Reject message (Digest-Response-Auth
         can't be correct as the RADIUS server does not know the
         contents of the HTTP-style response's body).
   o  If the Access-Accept message 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



Sterman, et al.           Expires June 8, 2005                 [Page 18]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


      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 into 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'.
         +  The Access-Accept message was secured by cryptographic or
            equivalently secure means.
         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 message 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 message 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.

   The RADIUS server MAY have added a Digest-Nextnonce attribute into an
   Access-Accept message.  If the RADIUS client discovers this, it puts
   the contents of this attribute into a 'nextnonce' directive.  Now it
   can send an HTTP-style response.

   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.

   If the RADIUS client receives an Access-Reject or no response from
   the RADIUS server, it sends an error response to the HTTP-style
   request it has received.

   The RADIUS client has three ways to obtain nonces: it generates them
   locally, it has received one in a Digest-Nextnonce attribute of a
   previously received Access-Accept message, 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.  The RADIUS server chooses a nonce and
   responds with an Access-Challenge containing a Digest-Nonce
   attribute.



Sterman, et al.           Expires June 8, 2005                 [Page 19]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


   The RADIUS server can send Digest-Qop, Digest-Algorithm,
   Digest-Realm, Digest-Domain and Digest-Opaque attributes in the
   Access-Challenge carrying the nonce.  If these attributes are
   present, the client MUST use them.

   If the RADIUS client receives an Access-Challenge message 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
   quotes), the RADIUS client sends an error (401 or 407) response
   containing WWW-/Proxy-Authenticate header with the directive 'stale'
   and the digest directives derived from the Digest-* attributes.

3.2  RADIUS Server Behavior

   If the RADIUS server receives an Access-Request message 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 message to the RADIUS
   client.  The RADIUS server MUST add Digest-Algorithm, Digest-Realm,
   SHOULD add one or more Digest-Qop and MAY add Digest-Domain,
   Digest-Opaque attributes to the Access-Challenge message.  If the
   server cannot choose a nonce, it replies with an Access-Reject
   message.

   If the RADIUS server receives an Access-Request message containing a
   Digest-Response attribute, it looks for the following attributes:
   Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop,
   Digest-Algorithm, 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 it 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 message.  If the attributes are present, 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.  All other values are taken from the Digest attributes
   described in this document.  If the calculated digest response equals
   the string received in the Digest-Response attribute, the
   authentication was successful.  If not, the RADIUS server responds
   with an Access-Reject.

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



Sterman, et al.           Expires June 8, 2005                 [Page 20]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


   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 message
   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 message:
      *  The Digest-Algorithm attribute's value is 'MD5-sess' or
         'AKAv1-MD5-sess'.
      *  The authenticity and integrity of the Access-Accept message is
         secured by cryptographic or equivalently secure means.
   In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
   sent.

   RADIUS servers issuing nonces MAY construct a Digest-Nextnonce
   attribute and add it to the Access-Accept message.  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).

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


























Sterman, et al.           Expires June 8, 2005                 [Page 21]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


4.  Migration Path to Diameter

   The attributes specified in this document correspond to some AVPs
   defined in [I-D.ietf-aaa-diameter-sip-app].

4.1  RADIUS Client, Diameter Server

   If an Access-Request message contains a Digest-Nonce attribute, the
   gateway maps all Digest-* attributes to a Diameter SIP-Authorization
   AVP.  If the Access-Request message contains a Digest-Method and a
   Digest-URI attribute but no Digest-Nonce attribute, the gateway maps
   the RADIUS attributes to Diameter according to Table 1.  The gateway
   constructs a MAR message and sends it to the Diameter server.

                     +---------------+------------+
                     | RADIUS        | Diameter   |
                     +---------------+------------+
                     | Digest-Method | SIP-Method |
                     |               |            |
                     | Digest-URI    | SIP-AOR    |
                     +---------------+------------+

                                Table 1

   The Diameter Server responds with a MAA message.  This message
   contains a Result-Code AVP set to the value DIAMETER_MULTI_ROUND_AUTH
   and challenge parameters in a SIP-Authenticate AVP.  The gateway
   translates the AVPs of SIP-Authenticate AVP and puts the resulting
   RADIUS attributes into an Access-Challenge message.  It sends the
   Access-Challenge message to the RADIUS client.

   The gateway maps an Access-Request message containing a
   Digest-Response attribute to an MAR message with a Diameter
   SIP-Authorization AVP.  All RADIUS attributes of the Access-Request
   message are mapped to the corresponding Diameter AVPs.  The gateway
   sends the MAR message to the Diameter server.

   If the authentication was successful, the Diameter server replies
   with an MAA containing a SIP-Authentication-Info and a
   Digest-Response AVP.  The gateway converts these AVPs to the
   corresponding RADIUS attributes and constructs a RADIUS message.  If
   the Result-Code AVP is Diameter_SUCCESS, an Access-Accept is sent.
   In all other cases, an Access-Reject is sent.

   If the Diameter found the nonce to be stale, it will respond with a
   new challenge in a SIP-Authenticate AVP of an MAA message.  The
   gateway handles this MAA like the first MAA message containing
   challenge parameters, as described in above.



Sterman, et al.           Expires June 8, 2005                 [Page 22]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


4.2  Diameter Client, RADIUS Server

   The Diameter client sends a Diameter MAR to the gateway.  If the MAR
   message does not contain SIP-Auth-Data-Item AVPs, the gateway
   constructs an Access-Request message and maps the SIP-AOR and
   SIP-Method AVPs to RADIUS attributes according to Table 1.  The
   gateway sends the Access-Request message to the RADIUS server which
   will respond with an Access-Challenge.  The gateway creates a MAA
   message with a Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH and
   maps the Digest-* attributes to Diameter AVPs in a SIP-Authenticate
   AVP.  The gateway sends the resulting MAA to the Diameter client,
   which will respond with a new MAR.

   The gateway checks the SIP-Auth-Data-Item AVPs of this MAR for an AVP
   where the Digest-Realm AVP matches the locally configured realm
   value.  It takes the AVPs from this SIP-Auth-Data-Item AVP, converts
   them into the corresponding RADIUS attributes and constructs a RADIUS
   Access-Request message.  The gateway sends the Access-Request message
   to the RADIUS server.  If the RADIUS server responds with an
   Access-Accept message, the gateway converts the RADIUS attributes to
   Diameter AVPs, constructs a MAR with a Result-Code AVP set to
   DIAMETER_SUCCESS and sends this message to the Diameter client.  If
   the RADIUS server responds with an Access-Reject message, the gateway
   converts the RADIUS attributes to Diameter AVPs, constructs a MAR
   with a Result-Code AVP set to DIAMETER_ERROR_IDENTITIES_DONT_MATCH
   and sends this message to the Diameter client.

4.3  Limitations

   This document covers not all functionality found in
   [I-D.ietf-aaa-diameter-sip-app].
   o  There is no equivalent to Diameter's UAR/UAA, SAR/SAA, LIR/LIA,
      RTR/RTA and PPR/PPA messages
   o  The operational mode where the Diameter server sends the expected
      digest response to the client is not supported.

   The operational mode where the RADIUS client chooses nonces is not
   supported in [I-D.ietf-aaa-diameter-sip-app].













Sterman, et al.           Expires June 8, 2005                 [Page 23]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


5.  Example

   This is an example sniffed from the traffic between a softphone (A),
   a Proxy Server (B) and example.com RADIUS server (C).  The
   communication between the Proxy Server and a SIP PSTN gateway is
   omitted for brevity.  The SIP messages are not shown completely.



   A->B

      INVITE sip:97226491335@10.0.69.38 SIP/2.0


   B->A

      SIP/2.0 100 Trying


   B->A

      SIP/2.0 407 Proxy Authentication Required
      Proxy-Authenticate: Digest realm="example.com"
           ,nonce="3bada1a0", algorithm="md5"
      Content-Length: 0


   A->B

      ACK sip:97226491335@10.0.69.38 SIP/2.0


   A->B

      INVITE sip:97226491335@10.0.69.38 SIP/2.0
      Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
           ,opaque="",realm="example.com"
           ,response="f3ce87e6984557cd0fecc26f3c5e97a4"
           ,uri="sip:97226491335@10.0.69.38",username="12345678"


   B->C

      Code = 1 (Access-Request)
      Attributes:
      NAS-IP-Address = a 0 45 26 (10.0.69.38)
      NAS-Port-Type = 5 (Virtual)
      User-Name = "12345678"



Sterman, et al.           Expires June 8, 2005                 [Page 24]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


      Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4"
      Digest-Realm = "example.com"
      Digest-Nonce = "3bada1a0"
      Digest-Method = "INVITE"
      Digest-URI = "sip:97226491335@10.0.69.38"
      Digest-Algorithm = "md5"
      Digest-Username =  "12345678"


   C->B

      Code = 2 (Access-Accept)
      Attributes:
      Digest-Response-Auth =
                   "6303c41b0e2c3e524e413cafe8cce954"


   B->A

      SIP/2.0 180 Ringing


   B->A

      SIP/2.0 200 OK


   A->B

      ACK sip:97226491335@10.0.69.38:5060 SIP/2.0



   A second example shows the traffic between a web browser (A), web
   server (B) and a RADIUS server (C).



   A->B

      GET /index.html HTTP/1.1


   B->A

      HTTP/1.1 407 Authentication Required
      WWW-Authenticate: Digest realm="example.com",
          domain="/index.html",



Sterman, et al.           Expires June 8, 2005                 [Page 25]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


          nonce="a3086ac8", algorithm="md5"
      Content-Length: 0


   A->B

      GET /index.html HTTP/1.1
      Authorization: Digest algorithm="md5",nonce="a3086ac8"
           ,opaque="",realm="example.com"
           ,response="f052b68058b2987aba493857ae1ab002"
           ,uri="/index.html",username="12345678"


   B->C

      Code = 1 (Access-Request)
      Attributes:
      NAS-IP-Address = a 0 45 26 (10.0.69.38)
      NAS-Port-Type = 5 (Virtual)
      User-Name = "12345678"
      Digest-Response = "f052b68058b2987aba493857ae1ab002"
      Digest-Realm = "example.com"
      Digest-Nonce = "a3086ac8"
      Digest-Method = "GET"
      Digest-URI = "/index.html""
      Digest-Algorithm = "md5"
      Digest-Username =  "12345678"


   C->B

      Code = 2 (Access-Accept)
      Attributes:
      Digest-Response-Auth =
          "e644aa513effbfe1caff67103ff6433c"


   B->A

      HTTP/1.1 200 OK
      ...

      <html>
      ...







Sterman, et al.           Expires June 8, 2005                 [Page 26]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


6.  IANA Considerations

   This document serves as IANA registration request for a number of
   values from the RADIUS attribute type number space:

          +-------------------------+------------------------+
          | placeholder             | value assigned by IANA |
          +-------------------------+------------------------+
          | Digest-Response         | TBD                    |
          |                         |                        |
          | Digest-Realm            | TBD                    |
          |                         |                        |
          | Digest-Nonce            | TBD                    |
          |                         |                        |
          | Digest-Nextnonce        | TBD                    |
          |                         |                        |
          | Digest-Response-Auth    | TBD                    |
          |                         |                        |
          | Digest-Method           | TBD                    |
          |                         |                        |
          | Digest-URI              | TBD                    |
          |                         |                        |
          | Digest-Qop              | TBD                    |
          |                         |                        |
          | Digest-Algorithm        | TBD                    |
          |                         |                        |
          | Digest-Entity-Body-Hash | TBD                    |
          |                         |                        |
          | Digest-CNonce           | TBD                    |
          |                         |                        |
          | Digest-Nonce-Count      | TBD                    |
          |                         |                        |
          | Digest-Username         | TBD                    |
          |                         |                        |
          | Digest-Opaque           | TBD                    |
          |                         |                        |
          | Digest-Auth-Param       | TBD                    |
          |                         |                        |
          | Digest-AKA-Auts         | TBD                    |
          |                         |                        |
          | Digest-Domain           | TBD                    |
          |                         |                        |
          | Digest-Stale            | TBD                    |
          |                         |                        |
          | Digest-HA1              | TBD                    |
          +-------------------------+------------------------+

                                Table 2



Sterman, et al.           Expires June 8, 2005                 [Page 27]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


7.  Security Considerations

   The RADIUS extensions described in this document make RADIUS a
   transport protocol for the data that is required to perform a digest
   calculation.  It adds the vulnerabilities of HTTP Digest (see
   [RFC2617], section 4) to those of RADIUS (see [RFC2865], section 8 or
   here [1])).

   If an attacker gets access to a RADIUS client or RADIUS proxy, it can
   perform man-in-the-middle attacks even if the connections between A,
   B and B, C (Figure 2) have been secured with TLS or IPSec.

   SIP or HTTP requests occur much more frequently than dial-in
   requests.  RADIUS servers implementing this specification must meet
   that additional performance requirements.  An attacker could try to
   overload the RADIUS infrastructure by excessively sending SIP or HTTP
   requests.  This kind of attack was more difficult when RADIUS was
   just used for dial-in authentication: the attacker could be
   identified by the DSL / Cable interface or with some help of the PSTN
   provider.

   To make simple denial of service attacks more difficult, the nonce
   issuer (RADIUS client or server) MUST check if it has generated the
   nonce received from an HTTP-style client.  This SHOULD be done
   statelessly.  For example, a nonce could consist of a
   cryptographically random part and some kind of signature of the
   RADIUS client, as described in [RFC2617], section 3.2.1.

   RADIUS servers MAY include Digest-Qop and Digest-Algorithm attributes
   in Access-Challenge messages.  A man in the middle can modify or
   remove those attributes in a bidding down attack.  In this case, the
   RADIUS client would use a weaker authentication scheme than intended.
   RfC 3579 [RFC3579], section 3.2 describes a Message-Authenticator
   attribute which MUST be used to improve the integrity protection of
   RADIUS messages.

   The Digest-HA1 attribute contains no random components if the
   algorithm is 'MD5' or 'AKAv1-MD5'.  This makes offline dictionary
   attacks easier and can be used for replay attacks.

   HTTP-style clients can use TLS with server side certificates together
   with HTTP-Digest authentication.  Instead of TLS, IPSec can be used,
   too.  TLS or IPSec secure the connection while Digest Authentication
   authenticates the user.  If a RADIUS client accepts such connections,
   it MUST have an equally secure connection to the RADIUS server.






Sterman, et al.           Expires June 8, 2005                 [Page 28]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


8.  Change Log

8.1  Changes from draft-sterman-aaa-sip-04

   o  clarified usage of Digest-HA1
   o  clarified usage of Digest-Stale (is sent in an Access-Challenge
      now)
   o  clarified allowed attribute usage for message types
   o  changed attribute type to 'Text' where the corresponding Diameter
      AVPs have a UTF8String
   o  added Diameter client - RADIUS server handling

8.2  Changes from draft-sterman-aaa-sip-03

   o  addressed 'auth-int' issue
   o  New Digest-Nextnonce attribute
   o  revised abstract, motivational section and examples
   o  Access-Challenge instead of 'Access-Accept carrying a Digest-Nonce
      attribute'
   o  shortened SIP messages in example, removed real-world addresses
      and product names

8.3  Changes from draft-sterman-aaa-sip-02

   o  Relaxed restrictions for Digest-Domain, Digest-Realm,
      Digest-Opaque, Digest-Qop and Digest-Algorithm
   o  Additional security considerations for Digest-Domain, Digest-Qop
      and Digest-Algorithm usage in Access-Accept messages

8.4  Changes from draft-sterman-aaa-sip-01

   o  Replaced Sub-attributes with flat attributes
   o  aligned naming with [I-D.ietf-aaa-diameter-sip-app]
   o  Added how a server must treat unknown attributes.
   o  Added a section 'Migration path to Diameter'
   o  Added an optional attribute for support of the digest scheme
      described in informational [RFC3310].
   o  Added a mode of operation where the RADIUS server chooses the
      nonce.  This was required for AKA [RFC3310], but can be useful for
      ordinary Digest authentication when the qop directive is not used.
      This required the addition of several attributes.










Sterman, et al.           Expires June 8, 2005                 [Page 29]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


9.  References

9.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A. and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)", RFC
              2865, June 2000.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
              "SIP: Session Initiation Protocol", RFC 3261, June 2002.

   [RFC3310]  Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer
              Protocol (HTTP) Digest Authentication Using Authentication
              and Key Agreement (AKA)", RFC 3310, September 2002.

9.2  Informative References

   [I-D.ietf-aaa-diameter-sip-app]
              Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
              Canales-Valenzuela, C. and K. Tammi, "Diameter Session
              Initiation Protocol (SIP) Application",
              draft-ietf-aaa-diameter-sip-app-04 (work in progress),
              October 2004.

   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
              Recommendations for Security", RFC 1750, December 1994.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2633]  Ramsdell, B., "S/MIME Version 3 Message Specification",
              RFC 2633, June 1999.

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible



Sterman, et al.           Expires June 8, 2005                 [Page 30]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.















































Sterman, et al.           Expires June 8, 2005                 [Page 31]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


URIs

   [1]  <http://www.untruth.org/~josh/security/radius/radius-auth.html>


Authors' Addresses

   Baruch Sterman
   Kayote Networks
   P.O. Box 1373
   Efrat  90435
   Israel

   EMail: baruch@kayote.com


   Daniel Sadolevsky
   SecureOL, Inc.
   Jerusalem Technology Park
   P.O. Box 16120
   Jerusalem  91160
   Israel

   EMail: dscreat@dscreat.com


   David  Schwartz
   Kayote Networks
   P.O. Box 1373
   Efrat  90435
   Israel

   EMail: david@kayote.com


   David Williams
   Cisco Systems
   7025 Kit Creek Road
   P.O. Box 14987
   Research Triangle Park  NC 27709
   USA

   EMail: dwilli@cisco.com








Sterman, et al.           Expires June 8, 2005                 [Page 32]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


   Wolfgang Beck
   Deutsche Telekom AG
   Am Kavalleriesand 3
   Darmstadt  64295
   Germany

   EMail: beckw@t-systems.com












































Sterman, et al.           Expires June 8, 2005                 [Page 33]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


Appendix A.  Acknowledgments

   We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or
   providing comments and experimental implementation.

   Many thanks to all reviewers, especially to Miguel Garcia, Jari
   Arrko, Avi Lior and Jun Wang.












































Sterman, et al.           Expires June 8, 2005                 [Page 34]


Internet-Draft    RADIUS Extension for Digest Authentication  December 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Sterman, et al.           Expires June 8, 2005                 [Page 35]