[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

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


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

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 August 6, 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
   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



Sterman, et al.          Expires August 6, 2004                 [Page 1]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


   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 . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   1.4  Approach . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.   New RADIUS attributes  . . . . . . . . . . . . . . . . . . .   7
   2.1  Digest-Response attribute  . . . . . . . . . . . . . . . . .   7
   2.2  Digest-Attributes attribute  . . . . . . . . . . . . . . . .   8
   2.3  Realm  . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   2.4  Nonce  . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   2.5  Method . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   2.6  URI  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   2.7  QOP  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   2.8  Algorithm  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   2.9  Body-Digest  . . . . . . . . . . . . . . . . . . . . . . . .  11
   2.10 CNonce . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   2.11 Nonce-Count  . . . . . . . . . . . . . . . . . . . . . . . .  12
   2.12 User-Name  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   3.   Detailed Description . . . . . . . . . . . . . . . . . . . .  14
   3.1  RADIUS Client Behaviour  . . . . . . . . . . . . . . . . . .  14
   3.2  RADIUS Server Behaviour  . . . . . . . . . . . . . . . . . .  14
   4.   Security Considerations  . . . . . . . . . . . . . . . . . .  16
   5.   Example  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
        Normative References . . . . . . . . . . . . . . . . . . . .  21
        Informative References . . . . . . . . . . . . . . . . . . .  22
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  23
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  25
        Intellectual Property and Copyright Statements . . . . . . .  26


















Sterman, et al.          Expires August 6, 2004                 [Page 2]


Internet-Draft    RADIUS Extension for Digest Authentication  February 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 4),
   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



Sterman, et al.          Expires August 6, 2004                 [Page 3]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


   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.

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

1.3 Scenario

   Figure 1 depicts the 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 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}



Sterman, et al.          Expires August 6, 2004                 [Page 4]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


   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 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 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 two newly defined
   RADIUS attributes. The Digest-Response attribute and the
   Digest-Attributes attribute carrying multiple HTTP Digest parameters
   as subattributes. These two 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 structure



Sterman, et al.          Expires August 6, 2004                 [Page 5]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


   of Digest-Response, the structure of Digest-Attributes and  the
   mapping/meaning of its subattributes are described in the next
   chapter.
















































Sterman, et al.          Expires August 6, 2004                 [Page 6]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


2. New RADIUS attributes

   DIG-RES and DIG-ATTRS are placeholders for values that will be
   assigned by IANA, if this specification becomes a working group
   document.

2.1 Digest-Response attribute

   If this attribute is present, the RADIUS server SHOULD view the
   Access-Request as a Digest one. The following paragraphs apply for
   RADIUS servers implementing this specification.

   Access-Request packets MUST contain an Digest-Response attribute. In
   Access-Request packets, this attribute contains the digest taken from
   request-digest field in Digest (Proxy)Authorization header, as
   received from the HTTP or SIP client.

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






Sterman, et al.          Expires August 6, 2004                 [Page 7]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


         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
         ([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-Attributes attribute

   This attribute contains subattributes which indicate the values
   contained in a Digest (Proxy)Authorization header and other
   information necessary to calculate the correct digest response.  It
   is only used in Access- Request  packets.  There can be multiple
   Digest-Attributes attributes contained in one Access-Request packet.
   In this case RADIUS server MUST interpret a concatenation of their
   values as if it came in one attribute.

   A summary of the Digest-Attributes 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 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Length       | String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Type

         DIG-ATTRS for Digest-Attributes. Early implementations have
         used the experimental type 207.

   Length

         >= 5

   String






Sterman, et al.          Expires August 6, 2004                 [Page 8]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


         The String field is 3 or more octets and contains one or more
         subattributes. Format of a subattribute 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 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Sub-Type  |  Sub-Length   | Sub-Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-



      Sub-Type

            Subattribute type.  Meanings of the following defined types
            can be found in section Section 2.3





    1      Realm
    2      Nonce
    3      Method
    4      URI
    5      QOP
    6      Algorithm
    7      Body-Digest
    8      CNonce
    9      Nonce-Count
   10      User-Name



         Sub-Length >= 3

         Sub-Value Subattribute-specific value


2.3 Realm







Sterman, et al.          Expires August 6, 2004                 [Page 9]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


   Sub-Type

         1

   Sub-Length

         >= 3

   Sub-Value

         String, copied from realm-value of digest-response ([RFC2617])


2.4 Nonce

   Sub-Type

         2

   Sub-Length

         >= 3

   Sub-Value

         String, copied from realm-value of digest-response ([RFC2617])


2.5 Method

   Sub-Type

         3

   Sub-Length

         >= 3

   Sub-Value

         String, copied from digest-response. Method is taken from HTTP
         or SIP request ([RFC2616], [RFC3261])


2.6 URI






Sterman, et al.          Expires August 6, 2004                [Page 10]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


   Sub-Type

         4

   Sub-Length

         >= 3

   Sub-Value

         String, copied from digest-uri-value of digest-response
         ([RFC2617])


2.7 QOP

   Sub-Type

         5

   Sub-Length

         >= 3

   Sub-Value

         String, copied from qop-value of digest-response ([RFC2617])


2.8 Algorithm

   Sub-Type

         6

   Sub-Length

         >= 3

   Sub-Value

         String, "MD5" | "MD5-sess" | token, copied from of
         digest-response ([RFC2617])


2.9 Body-Digest





Sterman, et al.          Expires August 6, 2004                [Page 11]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


   Sub-Type

         7

   Sub-Length

         34

   Sub-Value

         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.


2.10 CNonce

   Sub-Type

         8

   Sub-Length

         >= 3

   Sub-Value

         String copied from cnonce-value of digest-response ([RFC2617])


2.11 Nonce-Count

   Sub-Type

         9

   Sub-Length

         10

   Sub-Value

         String, 8LHEX, copied from nc-value of digest-response
         ([RFC2617])





Sterman, et al.          Expires August 6, 2004                [Page 12]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


2.12 User-Name

   Sub-Type

         10

   Sub-Length

         >= 3

   Sub-Value

         String  copied from username-value of digest-response
         ([RFC2617]) 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 password, the RADIUS
         server SHOULD use the value of the User-Name _attribute_


































Sterman, et al.          Expires August 6, 2004                [Page 13]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


3. Detailed Description

   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.

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' parameter has not been issued 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 issues 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 a
   Digest-Attributes attribute.  The request URI and the request method
   are put into the Digest-Attributes attribute, too. 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-Response attribute contained in
   the message. It constructs an Authentication-Info header and puts the
   contents of Digest-Response into the 'rspauth' header parameter. 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 generates 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.

3.2 RADIUS Server Behaviour

   If the RADIUS server receives an Access-Request message containing a
   Digest-Response attribute, it looks for the Digest-Attributes



Sterman, et al.          Expires August 6, 2004                [Page 14]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


   attribute. If it does not find this attribute, it responds with an
   Access-Reject message. If the Digest-Attribute attribute is 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-Attribute attribute.  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 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. The
   Digest-Response attribute is send to the RADIUS client in an
   Access-Accept message.



































Sterman, et al.          Expires August 6, 2004                [Page 15]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


4. 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, 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.

   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 August 6, 2004                [Page 16]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


5. 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 August 6, 2004                [Page 17]


Internet-Draft    RADIUS Extension for Digest Authentication  February 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 August 6, 2004                [Page 18]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


      Code = 1 (Access-Request)
      Identifier = 1
      Length = 164
      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 (206) = "2ae133421cda65d67dc50d13ba0eb9bc"
      Digest-Attributes (207) = [Realm (1) = "deltathree"]
      Digest-Attributes (207) = [Nonce (2) = "3bada1a0"]
      Digest-Attributes (207) = [Method (3) = "INVITE"]
      Digest-Attributes (207) =
           [URI (4) = "sip:97226491335@213.137.69.38"]
      Digest-Attributes (207) = [Algorithm (5) = "md5"]
      Digest-Attributes (207) = [User-Name (10) = "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



Sterman, et al.          Expires August 6, 2004                [Page 19]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


      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
      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 August 6, 2004                [Page 20]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


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.






























Sterman, et al.          Expires August 6, 2004                [Page 21]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


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.

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






































Sterman, et al.          Expires August 6, 2004                [Page 22]


Internet-Draft    RADIUS Extension for Digest Authentication  February 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 August 6, 2004                [Page 23]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


   Wolfgang Beck
   Deutsche Telekom AG
   Am Kavalleriesand 3
   Darmstadt  64295
   Germany

   EMail: beckw@t-systems.com












































Sterman, et al.          Expires August 6, 2004                [Page 24]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


Appendix A. Acknowledgements

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















































Sterman, et al.          Expires August 6, 2004                [Page 25]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Sterman, et al.          Expires August 6, 2004                [Page 26]


Internet-Draft    RADIUS Extension for Digest Authentication  February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Sterman, et al.          Expires August 6, 2004                [Page 27]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/