[Home]

Summary:ASTERISK-01123: [request] SIP authentication with HTTP_DIGEST QOP values
Reporter:Olle Johansson (oej)Labels:
Date Opened:2004-02-29 05:56:38.000-0600Date Closed:2004-09-25 02:51:28
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:The Asterisk SIP channel doesn't support HTTP-digest authentication with quality of protection parameters. These protect against replay attacks. Some SIP Service providers seems to require this kind of auth. The current version of Asterisk can't register with these SIP providers.

Asterisk needs to support this both for outbound registrations (registry) and for peer registration.

****** ADDITIONAL INFORMATION ******

From RFC 3261:
However, servers MUST always send a "qop" parameter in WWW-Authenticate and Proxy-Authenticate header field values.  If a client receives a "qop" parameter in a challenge header field, it MUST send the "qop" parameter in any resulting authorization header field.

-------------
HTTP-digest auth is defined in RFC 2617 (http://www.zvon.org/tmRFC/RFC2617/Output/index.html).

About QoP headers (from RFC 2617):
qop
    Indicates what "quality of protection" the client has applied to
    the message. If present, its value MUST be one of the alternatives
    the server indicated it supports in the WWW-Authenticate header.
    These values affect the computation of the request-digest. Note
    that this is a single token, not a quoted list of alternatives as
    in WWW- Authenticate.  This directive is optional in order to
    preserve backward compatibility with a minimal implementation of
    RFC 2069(-> 2617draft) [6], but SHOULD be used if the server indicated that qop
    is supported by providing a qop directive in the WWW-Authenticate
    header field.

  cnonce
    This MUST be specified if a qop directive is sent (see above), and
    MUST NOT be specified if the server did not send a qop directive in
    the WWW-Authenticate header field.  The cnonce-value is an opaque
    quoted string value provided by the client and used by both client
    and server to avoid chosen plaintext attacks, to provide mutual
    authentication, and to provide some message integrity protection.
    See the descriptions below of the calculation of the response-
    digest and request-digest values.

  nonce-count
    This MUST be specified if a qop directive is sent (see above), and
    MUST NOT be specified if the server did not send a qop directive in
    the WWW-Authenticate header field.  The nc-value is the hexadecimal
    count of the number of requests (including the current request)
    that the client has sent with the nonce value in this request.  For
    example, in the first request sent in response to a given nonce
    value, the client sends "nc=00000001".  The purpose of this
    directive is to allow the server to detect request replays by
    maintaining its own copy of this count - if the same nc-value is
    seen twice, then the request is a replay.   See the description
    below of the construction of the request-digest value.
----
Comments:By: Olle Johansson (oej) 2004-04-05 06:40:19

First patch added by markster in head cvs