Network Working Group                                         B. Sterman
Internet-Draft                                           Kayote Networks
Expires: November 30, 2004                                 D. Sadolevsky
                                                          SecureOL, Inc.
                                                             D. Schwartz
                                                         Kayote Networks
                                                             D. Williams
                                                           Cisco Systems
                                                                 W. Beck
                                                     Deutsche Telekom AG
                                                               June 2004


               RADIUS Extension for Digest Authentication
                      draft-sterman-aaa-sip-03.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I 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 November 30, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   Basic and Digest authentication schemes are widely used in protocols
   such as SIP  and HTTP .  RADIUS  is a protocol for back end



Sterman, et al.        Expires November 30, 2004                [Page 1]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


   authentication.  RADIUS supports Basic authentication natively, as
   well as several other authentication schemes, such as CHAP, but does
   not support Digest authentication scheme.  This document describes an
   extension to RADIUS for Digest authentication and provides a scenario
   of Digest user authentication.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1  Terminology  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2  Motivation . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3  Scenario 1, RADIUS client chooses nonces . . . . . . . . .   4
     1.4  Scenario 2, RADIUS server chooses nonces . . . . . . . . .   5
     1.5  Approach . . . . . . . . . . . . . . . . . . . . . . . . .   7
   2.   New RADIUS attributes  . . . . . . . . . . . . . . . . . . .   8
     2.1  Digest-Response attribute  . . . . . . . . . . . . . . . .   8
     2.2  Digest-Realm attribute . . . . . . . . . . . . . . . . . .   9
     2.3  Digest-Nonce attribute . . . . . . . . . . . . . . . . . .   9
     2.4  Digest-Method attribute  . . . . . . . . . . . . . . . . .  10
     2.5  Digest-URI attribute . . . . . . . . . . . . . . . . . . .  10
     2.6  Digest-QoP attribute . . . . . . . . . . . . . . . . . . .  11
     2.7  Digest-Algorithm attribute . . . . . . . . . . . . . . . .  11
     2.8  Digest-Body attribute  . . . . . . . . . . . . . . . . . .  12
     2.9  Digest-CNonce attribute  . . . . . . . . . . . . . . . . .  13
     2.10   Digest-Nonce-Count attribute . . . . . . . . . . . . . .  13
     2.11   Digest-Username attribute  . . . . . . . . . . . . . . .  14
     2.12   Digest-Opaque attribute  . . . . . . . . . . . . . . . .  14
     2.13   Digest-Auth-Param attribute  . . . . . . . . . . . . . .  15
     2.14   Digest-AKA-Auts attribute  . . . . . . . . . . . . . . .  16
     2.15   Digest-Domain attribute  . . . . . . . . . . . . . . . .  16
     2.16   Digest-Stale attribute . . . . . . . . . . . . . . . . .  17
   3.   Detailed Description . . . . . . . . . . . . . . . . . . . .  18
     3.1  RADIUS Client Behaviour  . . . . . . . . . . . . . . . . .  18
     3.2  RADIUS Server Behaviour  . . . . . . . . . . . . . . . . .  19
   4.   Migration Path to DIAMETER . . . . . . . . . . . . . . . . .  21
   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  23
   6.   Security Considerations  . . . . . . . . . . . . . . . . . .  24
   7.   Example  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
   8.   Changes from -02 . . . . . . . . . . . . . . . . . . . . . .  29
   9.   Changes from -01 . . . . . . . . . . . . . . . . . . . . . .  30
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  31
   10.1   Normative References . . . . . . . . . . . . . . . . . . .  31
   10.2   Informative References . . . . . . . . . . . . . . . . . .  31
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  32
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  34
        Intellectual Property and Copyright Statements . . . . . . .  35





Sterman, et al.        Expires November 30, 2004                [Page 2]


Internet-Draft    RADIUS Extension for Digest Authentication   June 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].

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 weaknesses of Digest authentication (see Section 6),
   PKI-based authentication and encryption mechanisms have been
   introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633].  However,
   most SIP user agents that support TLS don't send client certificates.
   SIP with S/MIME is lacking support, too: even two years after the
   inclusion of S/MIME into SIP, almost no implementations exist.

   SIP service providers whishing to authenticate their clients have the
   following options: they can
   o  build a PKI and wait for interopable S/MIME capable SIP
      implementations,
   o  build a PKI and wait for SIP implementations supporting TLS with
      client-side certificates,
   o  replace their existing RADIUS infrastructure with DIAMETER
      [RFC3588], when DIAMETER supports HTTP Digest authentication,
   o  use TLS for server authentication and plaintext passwords (Basic)
      for client authentication, which can be done with standard RADIUS,
   o  upgrade their existing RADIUS servers with the functionality
      described in this document

   PKI solutions only cover authentication, not authorization (EAP could
   change this, but its use with SIP is not standardized).  TLS / Basic
   authentication works only with the limited number of SIP devices that
   implement TLS.  Basic authentication has been deprecated for SIP in
   [RFC3261].

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

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



Sterman, et al.        Expires November 30, 2004                [Page 3]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


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

1.3  Scenario 1, RADIUS client chooses nonces

   Figure 1 depicts the basic scenario that is relevant for this
   document.  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)    |     |           |     |
            |     |==========>|     |           |     |
            |  A  |           |  B  |    (4)    |  C  |
            |     |           |     |---------->|     |
            |     |           |     |    (5)    |     |
            |     |           |     |<----------|     |
            |     |    (6)    |     |           |     |
            |     |<==========|     |           |     |
            +-----+           +-----+           +-----+

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



                 Figure 1: Overview of basic operation

   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

   C: RADIUS server

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




Sterman, et al.        Expires November 30, 2004                [Page 4]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


   A sends B an HTTP/SIP request without authorization header (step 1).
   B challenges A sending an HTTP/SIP  "(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 from A is considered
   authentic.  If B receives an Access-Reject response, however, B then
   responds to  A with a "(Proxy) Authorization required" response (step
   6).

1.4  Scenario 2, RADIUS server chooses nonces

   Figure 2 depicts an alternative scenario, where the RADIUS server
   generates 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.

































Sterman, et al.        Expires November 30, 2004                [Page 5]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


                     HTTP/SIP           RADIUS

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

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



                 Figure 2: RADIUS server 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

   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-Accept (step 3).  This Access-Accept contains
   Digest attributes, from which B takes values to construct a HTTP/SIP
   "(Proxy) Authorization required" response.  The remaining steps are
   identical with scenario 1 (Section 1.3): 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)



Sterman, et al.        Expires November 30, 2004                [Page 6]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


   Authorization required" response (step 8).

1.5  Approach

   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.

   In most cases, the operation outlined in Section 1.3 is sufficient.
   It reduces the load on the RADIUS server to a minimum.  However, in
   some cases the RADIUS server is better off with pre-computed hashes.
   Section 1.4 describes an mechanism that enables this style of
   authentication.
















Sterman, et al.        Expires November 30, 2004                [Page 7]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


2.  New RADIUS attributes

   DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
   DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
   DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
   will be assigned by IANA, if this specification becomes a working
   group or IESG document.

   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.

2.1  Digest-Response attribute

   If this attribute is present, 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.

   Access-Accept packets MUST contain a Digest-Response attribute.  In
   Access-Accept packets, this attribute contains a digest that can be
   used for generating Authentication-Info headers.  The calculation of
   this digest is described in [RFC2617], section 3.2.3.  A summary of
   the Digest-Response attribute format is shown below.  The fields are
   transmitted from left to right.




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



   Type
         DIG-RES for Digest-Response.  Early implementations have used
         the experimental type 206.
   Length
         34
   String
         In Access-Requests, this string proves the user knows a
         password.  The String field is 32 octets long and contains
         hexadecimal representation of 16 octet digest value as it was
         calculated by the authenticated client.  The String field
         SHOULD be copied from request-digest of digest-response



Sterman, et al.        Expires November 30, 2004                [Page 8]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


         ([RFC2617]).  In Access-Accepts, this string 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 string.

2.2  Digest-Realm attribute

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




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



   Type
         DIG-REALM
   Length
         >=3
   String
         In Access-Requests, the RADIUS client takes the value of the
         realm directive (realm-value) from the HTTP-style request it
         wants to authenticate.  In Access-Accept messages carrying a
         Digest-Nonce attribute, the RADIUS server puts the expected
         realm value into this attribute.

2.3  Digest-Nonce attribute

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




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






Sterman, et al.        Expires November 30, 2004                [Page 9]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


   Type
         DIG-NONCE
   Length
         >=3
   String
         In Access-Requests, the RADIUS client takes the value of the
         nonce directive (nonce-value) from the HTTP-style request it
         wants to authenticate.  If the Access-Request had a
         Digest-Nonce attribute, the RADIUS server MAY put the nonce to
         be used in a future request into this attribute in the
         Access-Accept message.  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-Accept message.

2.4  Digest-Method attribute

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




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



   Type
         DIG-METHOD
   Length
         >=3
   String
         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.5  Digest-URI attribute

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






Sterman, et al.        Expires November 30, 2004               [Page 10]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


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



   Type
         DIG-URI
   Length
         >=3
   String
         In Access-Requests, the RADIUS client takes the value of the
         request URI (digest-uri-value) from the HTTP-style request it
         wants to authenticate.  The attribute MUST only be used in
         Access-Request messages.

2.6  Digest-QoP attribute

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




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



   Type
         DIG-QOP
   Length
         >=3
   String
         In Access-Requests, the RADIUS client takes the value of the
         qop directive (qop-value) from the HTTP-style request it wants
         to authenticate.  In Access-Accept messages carrying a
         Digest-Nonce attribute, the RADIUS server MAY put the desired
         qop-value into this attribute.

2.7  Digest-Algorithm attribute

   This attribute holds the algorithm parameter that influences the HTTP



Sterman, et al.        Expires November 30, 2004               [Page 11]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


   Digest calculation.




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



   Type
         DIG-ALG
   Length
         >=3
   String
         In Access-Requests, the RADIUS client takes the value of the
         algorithm directive from the HTTP-style request it wants to
         authenticate.  In Access-Accept messages, the RADIUS server MAY
         put the desired algorithm into this attribute.

2.8  Digest-Body attribute

   When using the qop level 'auth-int', the contents of the message body
   are 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.




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



   Type
         DIG-BODY
   Length
         34






Sterman, et al.        Expires November 30, 2004               [Page 12]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


   String
         String, hexadecimal representation of a digest calculated over
         entity-body of HTTP/SIP request ([RFC2616], [RFC3261]).
         Computed by entity B in figure Figure 1.  This attribute is not
         part of the HTTP Digest response.  See [RFC2617] section
         3.2.2.3.  This attribute MUST only be sent in Access-Request
         packets.

2.9  Digest-CNonce attribute

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




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



   Type
         DIG-CNONCE
   Length
         >=3
   String
         In Access-Requests, the RADIUS client takes the value of the
         cnonce directive (cnonce-value) from the HTTP-style request it
         wants to authenticate.  The attribute is never used in
         Access-Response messages.

2.10  Digest-Nonce-Count attribute

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




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




Sterman, et al.        Expires November 30, 2004               [Page 13]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


   Type
         DIG-NC
   Length
         9
   String
         In Access-Requests, the RADIUS client takes the value of the nc
         directive (nc-value) from the HTTP-style request it wants to
         authenticate.  The attribute MUST only be used in
         Access-Request messages.

2.11  Digest-Username attribute

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




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



   Type
         DIG-USER
   Length
         >= 3
   String
         In Access-Requests, the RADIUS client takes the value of the
         username directive (username-value) 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 sent in Access-Request packets.

2.12  Digest-Opaque attribute

   This attribute holds the opaque parameter that is passed to the
   HTTP-style client.  Th HTTP-style client passes this value back to
   the server (ie the RADIUS client) without modification.






Sterman, et al.        Expires November 30, 2004               [Page 14]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


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



   Type
         DIG-OPAQUE
   Length
         >=3
   String
         This attribute is only used when the RADIUS server chooses
         nonces.  In Access-Requests, the RADIUS client takes the value
         of the opaque directive from the HTTP-style request it wants to
         authenticate and puts it into this attribute.  In Access-Accept
         messages carrying a Digest-Nonce attribute, the RADIUS server
         MAY include this attribute.

2.13  Digest-Auth-Param attribute

   This attribute is a placeholder for future extensions.




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



   Type
         DIG-AUTHP
   Length
         >=3
   String
         This attribute is for future extensions.  Any extension
         parameter in the digest-response can be put into a
         Digest-Auth-Param attribute.  The string consists of the whole
         parameter, including its name and the equal ('=') sign.  RADIUS
         servers that do not implement a parameter contained in an
         Digest-Auth-Param attribute MUST respond with an Access-Reject
         message.  RADIUS clients that do not implement a parameter
         contained in an Digest-Auth-Param attribute MUST reject the



Sterman, et al.        Expires November 30, 2004               [Page 15]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


         original HTTP-style request.  This attribute MAY be used in
         Access-Request and Access-Accept messages.

2.14  Digest-AKA-Auts attribute

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




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



   Type
         DIG-AUTS
   Length
         >=3
   String
         In Access-Requests, the RADIUS client takes the value of the
         auts directive 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].
         RADIUS servers that do not implement AKA digest MUST respond
         with an Access-Reject message.

2.15  Digest-Domain attribute

   When a RADIUS client has asked for a nonce, the RADIUS server MAY add
   one or more Digest-Domain attributes to its Access-Accept 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).




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



Sterman, et al.        Expires November 30, 2004               [Page 16]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


   Type
         DIG-DOMAIN
   Length
         3
   String
         The string consists of a single URI, that defines a protection
         space.  RADIUS servers MAY send attributes of this type in
         Access-Accept messages that contain a Digest-Nonce attribute.
         RADIUS clients MUST NOT put attributes of this type in
         Access-Request messages.

2.16  Digest-Stale attribute

   If this attribute is present, the RADIUS server did not accept the
   nonce value.




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



   Type
         DIG-STALE
   Length
         3
   String
         The string consists of a single character '1'.  The contents of
         this string MAY be ignored by an implementation.  The presence
         of the attribute itself tells the RADIUS client that the nonce
         was considered stale.  The attribute MUST only be used in
         Access-Accept messages.














Sterman, et al.        Expires November 30, 2004               [Page 17]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


3.  Detailed Description

3.1  RADIUS Client Behaviour

   A RADIUS client without an encrypted or otherwise secured connection
   to its RADIUS server only accepts unsecured connections from its
   HTTP-style clients (or else the clients would have a false sense of
   security).

   The RADIUS client examines the (Proxy-)Authorization header of an
   incoming HTTP-style request message.  If this header is present and
   contains HTTP digest information, the RADIUS client checks the
   'nonce' parameter.  If the 'nonce' value has not been sent by the
   RADIUS client, 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, it takes the header
   parameters and puts them into a RADIUS Access-Request message.  It
   puts the 'response' parameter into a Digest-Response attribute and
   the realm / nonce / qop / algorithm / cnonce / nc / username into the
   respective Digest-Realm / Digest-Nonce / Digest-QoP /
   Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count /
   Digest-Username attributes.  The request URI and the request method
   are put into the Digest-URI and Digest-Method attributes.  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.  If the RADIUS client receives an
   Access-Accept, it examines the Digest attributes contained in the
   message.

   If the Digest-Stale attribute is present, the RADIUS client sends an
   error (401 or 407) response containing WWW-/Proxy-Authenticate header
   with a stale directive.

   If the Digest-Stale attribute is not present, the RADIUS client
   constructs an Authentication-Info header and puts the contents of
   Digest-Response into the 'rspauth' directive.  The RADIUS server MAY
   have added a Digest-Nonce attribute.  If the RADIUS client discovers
   this, it puts the contents of this attribute into a 'nextnonce'
   directive.  Now it can send a HTTP-style response.

   If the RADIUS client did not receive a (Proxy-)Authorization header
   from its HTTP-style client, 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



Sterman, et al.        Expires November 30, 2004               [Page 18]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


   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-Nonce 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-Accept containing a Digest-Nonce attribute.
   If the RADIUS server responds with an Access-Reject, the RADIUS
   client MAY generate a nonce locally.  If the RADIUS client does not
   generate nonces locally, the authentication has failed.  The RADIUS
   server can send Digest-QoP, Digest-Algorithm, Digest-Realm,
   Digest-Domain and Digest-Opaque attributes in the Access-Accept
   carrying the nonce.  If these attributes are present, the client MUST
   use them.

3.2  RADIUS Server Behaviour

   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-Accept message to the RADIUS
   client.  The RADIUS server MAY add Digest-QoP, Digest-Algorithm,
   Digest-Realm, Digest-Domain and Digest-Opaque attributes to the
   Access-Accept 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-Body,
   Digest-CNonce and Digest-AKA-Auts, too.  See [RFC2617] and [RFC3310]
   for details.  If it has issued a Digest-Opaque attribute along with
   the present nonce, the Access-Request MUST have a matching
   Digest-Opaque attribute.

   If it does not find these attributes, it responds 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.



Sterman, et al.        Expires November 30, 2004               [Page 19]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


   If the authentication was successful, the RADIUS server calculates a
   Digest-Response attribute that can be used by the RADIUS client to
   construct an Authentication-Info header.  The calculation of this
   response is described in [RFC2617], section 3.2.3.  RADIUS servers
   issuing nonces MAY construct a Digest-Nonce attribute.  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 Digest-Response attribute and the optional Digest-Nonce
   attribute are send to the RADIUS client in an Access-Accept message.










































Sterman, et al.        Expires November 30, 2004               [Page 20]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


4.  Migration Path to DIAMETER

   The following table gives an overview of the mapping between RADIUS
   attributes defined here and the corresponding DIAMETER AVPs described
   in [I-D.ietf-aaa-diameter-sip-app]:

   +---------------------------------+---------------------------------+
   | RADIUS                          | DIAMETER                        |
   +---------------------------------+---------------------------------+
   | Digest-Realm                    | Digest-Realm                    |
   |                                 |                                 |
   | Digest-Nonce                    | Digest-Nonce                    |
   |                                 |                                 |
   | Digest-URI                      | Digest-URI                      |
   |                                 |                                 |
   | Digest-Domain                   | Digest-Domain                   |
   |                                 |                                 |
   | Digest-QoP                      | Digest-Qop                      |
   |                                 |                                 |
   | Digest-Algorithm                | Digest-Algorithm                |
   |                                 |                                 |
   | Digest-CNonce                   | Digest-Cnonce                   |
   |                                 |                                 |
   | Digest-Nonce-Count              | Digest-Nonce-Count              |
   |                                 |                                 |
   | Digest-Method                   | SIP-Method AVP                  |
   |                                 |                                 |
   | Digest-Username                 | Digest-Username AVP             |
   |                                 |                                 |
   | Digest-Body                     | SIP-Entity-Body-Hash AVP        |
   |                                 |                                 |
   | Access-Request Digest-Response  | SIP-Authorization               |
   |                                 | Digest-Response                 |
   |                                 |                                 |
   | Access-Accept Digest-Response   | SIP-Authentication-Info         |
   |                                 | Digest-Response                 |
   |                                 |                                 |
   | Digest-Opaque                   | Digest-Opaque AVP               |
   |                                 |                                 |
   | Digest-Auth-Param               | Digest-Auth-Param               |
   |                                 |                                 |
   | Digest-AKA-Auts                 | Digest-AKA-Auts                 |
   |                                 |                                 |
   | Digest-Response                 | Digest-Response AVP             |
   |                                 |                                 |
   | Digest-Stale                    | Digest-Stale AVP                |
   +---------------------------------+---------------------------------+




Sterman, et al.        Expires November 30, 2004               [Page 21]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


                                Table 1

   Access-Requests containing a Digest-Response attribute and other
   Digest attributes are mapped to a DIAMETER SIP-Authorization AVP.
   The RADIUS/DIAMETER gateway constructs a MAR and sends it to the
   DIAMETER server.

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

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

                                Table 2

   If an Access-Request 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 2.  The gateway construct a
   MAR message and sends it to the DIAMETER server.

   If the MAA contains a SIP-Authenticate-AVP, the gateway maps the
   contained values to RADIUS attributes, according to Table 1.  If the
   Result-Code AVP is DIAMETER_MULTI_ROUND_AUTH, the gateway constructs
   an Access-Accept and sends it.


















Sterman, et al.        Expires November 30, 2004               [Page 22]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


5.  IANA Considerations

   DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
   DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
   DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
   require IANA registration.  They must be assigned from the RADIUS
   attribute type number space, if this specification becomes a working
   group or IESG document.











































Sterman, et al.        Expires November 30, 2004               [Page 23]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


6.  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
   <http://www.untruth.org/~josh/security/radius/radius-auth.html>)).

   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 1) 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, RADIUS
   clients MUST check if nonces received from a client have been issued
   by them.  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-Accept 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.
   Informational RfC 3579 [RFC3579], section 3.2 describes a
   Message-Authenticator attribute which MAY be used to protect the
   integrity of RADIUS messages.

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










Sterman, et al.        Expires November 30, 2004               [Page 24]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


7.  Example

   This is an example sniffed from the traffic between HearMe softphone
   (A), Cisco Systems Proxy Server (B) and deltathree RADIUS server (C)
   (The communication between Cisco Systems Proxy Server and a SIP PSTN
   gateway is omitted for brevity):



   A->B

      INVITE sip:97226491335@213.137.69.38 SIP/2.0
      Via: SIP/2.0/UDP 213.137.67.67:5061
      From: <sip:12345678@213.137.67.67>;tag=216ae97f
      To: sip:97226491335@213.137.69.38
      Contact: sip:12345678@213.137.67.67:5061
      Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
      CSeq: 2544265 INVITE
      Content-Length: 150
      Content-Type: application/sdp
      User-Agent: HearMe SoftPHONE

      v=0
      o=HearMe 2544265 2544265 IN IP4 213.137.67.67
      s=HearMe
      c=IN IP4 213.137.67.67
      t=0 0
      m=audio 8000 RTP/AVP 0 4
      a=ptime:20
      a=x-ssrc:009aa330


   B->A

      SIP/2.0 100 Trying
      Via: SIP/2.0/UDP 213.137.67.67:5061
      Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
      From: <sip:12345678@213.137.67.67>;tag=216ae97f
      To: sip:97226491335@213.137.69.38
      CSeq: 2544265 INVITE
      Content-Length: 0


   B->A

      SIP/2.0 407 Proxy Authentication Required
      Via: SIP/2.0/UDP 213.137.67.67:5061
      Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67



Sterman, et al.        Expires November 30, 2004               [Page 25]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


      From: <sip:12345678@213.137.67.67>;tag=216ae97f
      To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc
      CSeq: 2544265 INVITE
      Proxy-Authenticate: DIGEST realm="deltathree"
           ,nonce="3bada1a0", algorithm="md5"
      Content-Length: 0


   A->B

      ACK sip:97226491335@213.137.69.38 SIP/2.0
      Via: SIP/2.0/UDP 213.137.67.67:5061
      From: <sip:12345678@213.137.67.67>;tag=216ae97f
      To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc
      Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67
      CSeq: 2544265 ACK
      Content-Length: 0


   A->B

      INVITE sip:97226491335@213.137.69.38 SIP/2.0
      Via: SIP/2.0/UDP 213.137.67.67:5061
      From: <sip:12345678@213.137.67.67>;tag=29e97f
      To: sip:97226491335@213.137.69.38
      Contact: sip:12345678@213.137.67.67:5061
      Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
      CSeq: 2544266 INVITE
      Content-Length: 150
      Content-Type: application/sdp
      User-Agent: HearMe SoftPHONE
      Proxy-Authorization: DIGEST algorithm="md5",nonce="3bada1a0"
           ,opaque="",realm="deltathree"
           ,response="2ae133421cda65d67dc50d13ba0eb9bc"
           ,uri="sip:97226491335@213.137.69.38",username="12345678"

      v=0
      o=HearMe 2544265 2544265 IN IP4 213.137.67.67
      s=HearMe
      c=IN IP4 213.137.67.67
      t=0 0
      m=audio 8000 RTP/AVP 0 4
      a=ptime:20
      a=x-ssrc:009aa330


   B->C




Sterman, et al.        Expires November 30, 2004               [Page 26]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


      Code = 1 (Access-Request)
      Identifier = 1
      Length = 162
      Authenticator = 56 7b e6 9a 8e 43 cf b6 fb a6 c0 f0 9a 92 6f 0e
      Attributes:
      NAS-IP-Address = d5 89 45 26 (213.137.69.38)
      NAS-Port-Type = 5 (Virtual)
      User-Name = "12345678"
      Digest-Response (DIG-RES) = "2ae133421cda65d67dc50d13ba0eb9bc"
      Digest-Realm (DIG-REALM) = "deltathree"
      Digest-Nonce (DIG-NONCE) = "3bada1a0"
      Digest-Method (DIG-METHOD) = "INVITE"
      Digest-URI (DIG-URI) = "sip:97226491335@213.137.69.38"
      Digest-Algorithm (DIG-ALG) = "md5"
      Digest-Username (DIG-USER) =  "12345678"


   C->B

      Code = 2 (Access-Accept)
      Identifier = 1
      Length = 20
      Authenticator = 6d 76 53 ce aa 07 9a f7 ac b4 b0 e2 96 2f c4 0d
      Attributes:
      Digest-Response (206) = "6303c41b0e2c3e524e413cafe8cce954"


   B->A

      SIP/2.0 180 Ringing
      Via: SIP/2.0/UDP 213.137.67.67:5061
      From: <sip:12345678@213.137.67.67>;tag=29e97f
      To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E
      Date: Tue, 25 Jan 2000 03:41:00 gmt
      Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
      Server: Cisco-SIPGateway/IOS-12.x
      Record-Route: <sip:97226491335@213.137.69.38:5060
           ;maddr=213.137.69.38>
      CSeq: 2544266 INVITE
      Content-Length: 0


   B->A

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP 213.137.67.67:5061
      From: <sip:12345678@213.137.67.67>;tag=29e97f
      To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E



Sterman, et al.        Expires November 30, 2004               [Page 27]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


      Date: Tue, 25 Jan 2000 03:41:00 gmt
      Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
      Authentication-Info: nextnonce="ef0189c5",
          rspauth="6303c41b0e2c3e524e413cafe8cce954"
      Server: Cisco-SIPGateway/IOS-12.x
      Record-Route: <sip:97226491335@213.137.69.38:5060
           ;maddr=213.137.69.38>
      CSeq: 2544266 INVITE
      Contact: <sip:97226491335@213.137.69.36:5060;user=phone>
      Content-Type: application/sdp
      Content-Length: 158

      v=0
      o=CiscoSystemsSIP-GW-UserAgent 1901 5895 IN IP4 213.137.69.36
      s=SIP Call
      c=IN IP4 213.137.69.36
      t=0 0
      m=audio 17724 RTP/AVP 0
      a=rtpmap:0 PCMU/8000


   A->B

      ACK sip:97226491335@213.137.69.38:5060 SIP/2.0
      Via: SIP/2.0/UDP 213.137.67.67:5061
      From: <sip:12345678@213.137.67.67>;tag=29e97f
      To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E
      Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67
      CSeq: 2544266 ACK
      Content-Length: 0
      Route: <sip:97226491335@213.137.69.36:5060;user=phone>




















Sterman, et al.        Expires November 30, 2004               [Page 28]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


8.  Changes from -02

   o  Relaxed restrictions for DIG-DOMAIN, DIG-REALM, DIG-OPAQUE,
      DIG-QOP and DIG-ALG
   o  Additional security considerations for DIG-DOMAIN, DIG-QOP and
      DIG-ALG usage in Access-Accept messages













































Sterman, et al.        Expires November 30, 2004               [Page 29]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


9.  Changes from -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 November 30, 2004               [Page 30]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


10.  References

10.1  Normative References

   [I-D.ietf-aaa-diameter-sip-app]
              Garcia-Martin, M., "Diameter Session Initiation Protocol
              (SIP) Application", draft-ietf-aaa-diameter-sip-app-02
              (work in progress), April 2004.

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

10.2  Informative References

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

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

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.




Sterman, et al.        Expires November 30, 2004               [Page 31]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


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


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 November 30, 2004               [Page 32]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


   Wolfgang Beck
   Deutsche Telekom AG
   Am Kavalleriesand 3
   Darmstadt  64295
   Germany

   EMail: beckw@t-systems.com












































Sterman, et al.        Expires November 30, 2004               [Page 33]


Internet-Draft    RADIUS Extension for Digest Authentication   June 2004


Appendix A.  Acknowledgements

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















































Sterman, et al.        Expires November 30, 2004               [Page 34]


Internet-Draft    RADIUS Extension for Digest Authentication   June 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 November 30, 2004               [Page 35]