[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
   SIP Working Group                                        James Undery
   Internet Draft                                               Ubiquity
   Category: Standards Track
                                                              Sanjoy Sen
   Expires on Dec 2002                                   Nortel Networks

                                                           Vesa Torvinen
                                                                Ericsson

                                                               June 2002



           Enhanced Usage of HTTP Digest Authentication for SIP

                   <draft-undery-sip-auth-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


Abstract

   HTTP Digest has some shortcomings if applied for SIP. Firstly, SIP
   UA has serious difficulties to distinguish the source of
   Authentication-Info and Proxy-Authentication-Info headers in SIP
   forking situations. This is due to the absence of the ærealmÆ
   parameter in these headers. Secondly, HTTP authentication is
   particularly vulnerable against MITM bid-down attacks on the list of
   algorithms (e.g., MD-5, SHA-1) or the desired security level (auth,
   auth-int). Thirdly, HTTP authentication provides limited integrity
   protection of only the message body. In SIP, important information
   can be carried in many of the headers that may need integrity
   protection. This draft proposes to add the realm parameter in the *-
   Authentication-Info headers, recommends a format for computing the

Undery/Sen/Torvinen                                           [Page 1]


Internet Draft       Enhanced Usage of HTTP Digest            June 2002

   nonce for detection of bid-down attack and proposes a mechanism for
   integrity protection of SIP headers using MIME body.


1  Introduction

  HTTP Digest [3] has some shortcomings if applied for SIP. RFC 3261
  [2] allows the use of Authentication-Info header in responses for
  mutual authentication between the client and the server. As these
  headers currently do not contain the ærealmÆ parameter, the client
  has serious difficulties to distinguish the source of Authentication-
  Info headers if the SIP request is forked. Thus there is no way for
  the client to match the credential carried in the Authentication-Info
  header with the corresponding challenge.

  HTTP authentication is also vulnerable against MITM bid-down attacks,
  possibly on the algorithms (e.g., MD-5, SHA-1) or on the protection
  levels (auth, auth-int). A MITM attacker can easily remove the
  stronger mechanism among the existing mechanisms in the challenge
  (e.g., remove æauth-intÆ from a challenge containing both æauthÆ and
  æauth-intÆ). Also, HTTP authentication provides limited integrity
  protection of only the message body. In SIP, important information
  can be carried in many of the headers that may need integrity
  protection. This draft proposes to add the realm parameter in the *-
  Authentication-Info headers, recommends a format for computing the
  nonce for detection of bid-down attack and proposes a mechanism for
  integrity protection of SIP headers using MIME body.

2  Conventions used in this document

   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 RFC-2119.


3  Syntax for Authentication-Info header

   The Authentication-Info header is used by the server to communicate
   some information regarding the successful authentication in the
   response. The modified syntax is shown. The two new parameters added
   are ærealmÆ and æauth-paramÆ.

      AuthenticationInfo = "Authentication-Info" ":" auth-info
      auth-info          = 1#(nextnonce | realm | [message-qop]
                           | [response-auth ] | [cnonce]
                           | [nonce-count] | [auth-param])
      nextnonce          = "nextnonce" "=" nonce-value
      response-auth      = "rspauth" "=" response-digest
      response-digest    = <"> *LHEX <">


Undery/Sen/Torvinen         Expires Dec 2002                 [Page 2]


Internet Draft       Enhanced Usage of HTTP Digest            June 2002

   realm
     A string contained in the server challenge that can be rendered
   for the end user to provide the context with which to authenticate
   itself. The ærealmÆ parameter in Authentication-Info header SHOULD
   contain the same value as the corresponding element carried in the
   most recent challenge from the server.

   auth-param
     This is included for future extensions; unknown values should be
   ignored.

   The same syntax changes apply to the Proxy-Authentication-Info
   header that can be added by the Proxies in responses to UAC.


4  Recommendation for nonce construction

   Traditionally nonces have contained no meaning for the client,
   however, in order to detect bid-down attacks this draft will
   recommend a format. This format is designed to allow a server to
   encode the list that needs to be protected against bid-down attack.

   The following definition will replace nonce-value:

   nonce-value      = LDQUOT "(" 1#auth-prefix ")"
                      trad-nonce-value RDQUOT
   auth-prefix      = auth-algorithms | digest-auth-type | token
   auth-algorithms  = "MD5" | "AKA" | "SHA1"
   auth-type        = "auth" | "auth-int"
   trad-nonce-value = *(qdtext | quoted-pair)

   auth-algorithm
     These are the algorithms used by the Digest scheme to produce the
   digest.

   auth-type
     These are the protection levels for Digest authentication. Each
   value corresponds to a qop-value.

   The client compares the list of algorithms or protection level
   values with that encoded in the nonce to detect a bid-down attack.
   If the attacker modifies the auth-prefix in the nonce, then the
   digest credential computed by the server with the original nonce
   will not match that in the Digest response and the attack will be
   detected.

   A possible implementation of trad-nonce-value is:

Undery/Sen/Torvinen         Expires Dec 2002                 [Page 3]


Internet Draft       Enhanced Usage of HTTP Digest            June 2002


      trad-nonce-value = time-stamp "-" H(time-stamp ":" request-uri
     ":" private-key)

   where, the time-stamp is a non repeating value, the request-uri is
   the Request URI from the request and the private-key is to ensure
   that the nonce was generated by an entity that knows the private-
   key. The auth-prefix MAY be included in the hash function above. The
   inclusion of the auth-prefix in the hash is only really useful if
   the server generating the challenge varies the challenge on a
   request-by-request basis and does not want to reevaluate its policy
   rules.

5  Integrity protection of headers by the client

   If the client wants to integrity protect certain headers and if the
   server supports the level of protection æauth-intÆ, the client can
   do so by using the process of including headers in the message body
   by using MIME type æmessage/sipfragÆ, as described in [6] or by
   using the mechanism of tunneling entire SIP messages by using MIME
   type æmessage/sipÆ as discussed in [2].

   A valid æmessage/sipfragÆ message body is formed by taking the
   original SIP message and deleting either (1) entire start-line, or
   (2) one or more complete headers, or (3) entire body. The qop
   parameter in the Authorization or Proxy-Authorization header MUST be
   set to æauth-intÆ. This can be used to provide hop-by-hop, end-to-
   end, end-to-middle or middle-to-end integrity protection of selected
   headers using Digest. Some of the headers that can be integrity
   protected by this mechanism are: From, To, Call-ID, Contact, CSeq,
   Expires etc. An example of using this mechanism to protect a SIP
   header (Security-Verify) is discussed in [7]. The MIME type
   æmessage/sipÆ can be used for integrity protection of entire SIP
   message.

   The same mechanism can also be used by the server (or Proxy) to
   integrity protect headers, the response Status Code or the entire
   response message using the Authentication-Info (or Proxy-
   Authentication-Info) header.

6  Client and Server Behavior

   The server MUST include the ærealmÆ parameter in the Authentication-
   Info header. The server MUST ignore any æauth-paramÆ value that it
   does not understand. Otherwise, the semantic for the Authentication-
   Info header is the same as in [3].


Undery/Sen/Torvinen         Expires Dec 2002                 [Page 4]


Internet Draft       Enhanced Usage of HTTP Digest            June 2002

   For bid-down attack detection, the client MUST compare the list of
   algorithms or protection levels in the challenge with those encoded
   in the nonce. The server MUST store the original nonce that it had
   sent in the challenge and use it to compute the credential to match
   against the credential sent by the client.

   If the client wants to integrity protect one or more headers of the
   SIP message, then it MUST use the process of including headers in
   the message body by using MIME type æmessage/sipfragÆ as described
   in [6]. If the client wants to integrity protect the entire SIP
   message, then it MUST use the process of including entire SIP
   message in the message body (tunneling) using MIME type
   æmessage/sipÆ as discussed in [2]. In both cases, the qop parameter
   in the Authorization or Proxy-Authorization header MUST be set to
   æauth-intÆ. The client MUST use the mechanism for computing Digest
   credential for qop = auth-int, as described in [3].

7  Security Considerations

   The purpose of this draft is security. Items ruled out of scope of
   this document are privacy and resistance to denial of service
   attacks. Since this draft either proposes fix to RFC 2617 headers or
   discusses application of RFC 2617 for SIP, most of the security
   considerations discussed in [3] are applicable here.

   Note that, two of the mechanisms proposed in this draft û bid-down
   detection and integrity protection of headers / entire message û
   have to be initiated by the client. There is no way for the server
   or the Proxy to request that the client uses these mechanisms. [7]
   discusses a way that can be used by the server (or Proxy) to
   negotiate the use of these mechanisms with the client.

   The bid-down protection mechanism does not include algorithm
   revocation mechanisms. The result of this is if a one-way hashing
   algorithm is broken such that a message s + m can be recovered from
   KD(s + m) if m is known; or given a message s + m, it is possible to
   find n such that KD(s + m) = KD(s + n) for constant unknown s. Then
   this mechanism will fail, although in the second case m and n will
   have to be syntactically equivalent.


7.1  Security Considerations Missing From RFC 2617

   RFC 2617 [3] has a remarkably thorough security considerations
   section, however, in our opinion an important consideration
   is missed. In the WWW-Authenticate header the qop directive can
   contain a list of schemes supported. It is possible for an attacker
   to downgrade the security on offer by removing auth-int if present
   so the body of the message is not included in the protection, or
   simply remove the qop parameter entirely.

Undery/Sen/Torvinen         Expires Dec 2002                 [Page 5]


Internet Draft       Enhanced Usage of HTTP Digest            June 2002



8  Future Work

   Future work on this topic should include the following:

   - A mechanism for the server to recommend the list of headers that
   needs to be integrity protected
   - A way for the server to specify the protection mechanism to be
   used in the challenge
   - Authentication of Proxies by the UAS


9  References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
   9, RFC 2026, October 1996.

   2  Handley, M., Schulzrinne, H, Schooler, E. and Rosenberg, J.,
   "SIP: Session Initiation Protocol", RFC 3261.

   3  Franks, J. et al, "HTTP Authentication: Basic and Digest Access
   Authentication", RFC 2617, June 1999.

   4  Bellovin, S., "Report of the IAB Security Architecture Workshop",
   RFC 2316, April 1998.

   5  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
   1992.

   6 Sparks, R., "Internet Media Types message/sip and
   message/sipfrag", draft-sparks-sip-mimetypes-01 (work in progress),
   March 2002.

   7. Arkko, et. Al., "Security Mechanism Agreement for SIP Sessions",
   draft-ietf-sip-sec-agree-02.txt, May 2002.



10 Acknowledgments

   The authors acknowledge that the idea of using æmessage/sip-fragÆ to
   provide integrity protection of SIP headers using Digest was
   proposed by Henning.


11 Authors' Addresses

   James Undery
   Ubiquity Software Corporation Ltd.
   Ubiquity House

Undery/Sen/Torvinen         Expires Dec 2002                 [Page 6]


Internet Draft       Enhanced Usage of HTTP Digest            June 2002

   Langstone Park
   Newport, UK
   Email: jundery@ubiquity.net

   Sanjoy Sen
   Nortel Networks
   sanjoy@nortelnetworks.com
   Richardson, Texas
   Email: sanjoy@nortelnetworks.com

   Vesa Torvinen
   Oy LM Ericsson Ab
   Email: vesa.torvinen@ericsson.fi


12 Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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
   assigns.  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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR
   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE."




Undery/Sen/Torvinen         Expires Dec 2002                 [Page 7]