sip Internet Draft Paul D.Smith Expires: October 2004 Data Connection Ltd Ian Clarkson Data Connection Ltd April 2004 Digest Authentication Examples for Session Initiation Protocol (SIP) draft-smith-sip-auth-examples-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract RFC3261 [2] recommends that SIP requests be authenticated using HTTP Digest authentication as defined in RFC2617 [3], and many vendors have successfully added this function to their products. However implementation bugs are still being observed both at interoperability events and in the field. This document provides worked examples of Digest authentication usage in SIP. It is intended to help new SIP implementers, and to provide a common set of test authentication examples against which an implementation may be checked. Smith & Clarkson Expires - October 2004 [Page 1] Digest Authentication Examples for SIP April 2004 Table of Contents 1. Introduction...................................................3 2. Common Mistakes................................................3 2.1 Quotation marks in Quality-of-protection (QOP) Description..3 2.2 Absent QOP and qop=auth result in different digests.........5 2.3 Invalid validation of a nonce...............................6 3. Worked Examples................................................7 3.1 Algorithm and QOP not specified.............................8 3.1.1 Challenge...............................................8 3.1.2 Authenticated Request...................................8 3.1.3 Digest Generation Process...............................9 3.2 auth and algorithm unspecified (MD5 assumed)...............11 3.2.1 Challenge..............................................11 3.2.2 Authenticated Request..................................11 3.2.3 Digest Generation Process..............................12 3.3 auth and MD5...............................................14 3.3.1 Challenge..............................................14 3.3.2 Authenticated Request..................................14 3.3.3 Digest Generation Process..............................15 3.4 auth and MD5-Sess..........................................17 3.4.1 Challenge..............................................17 3.4.2 Authenticated Request..................................17 3.4.3 Digest Generation Process..............................18 3.5 auth-int and MD5...........................................20 3.5.1 Challenge..............................................20 3.5.2 Authenticated Request..................................20 3.5.3 Digest Generation Process..............................21 3.6 auth-int and MD5-Sess......................................24 3.6.1 Challenge..............................................24 3.6.2 Authenticated Request..................................24 3.6.3 Digest Generation Process..............................25 Security Considerations..........................................28 References.......................................................28 Acknowledgments..................................................28 Authors' Addresses...............................................29 Conventions used in this document The key words "MUST", "MUST NOT" and "SHOULD NOT" in this document should be interpreted as described in RFC2119 [4]. This document uses the representations introduced in draft-ietf-sipping-torture-tests [5] to specify the input and output from cryptographic operations. Smith & Clarkson Expires - October 2004 [Page 2] Digest Authentication Examples for SIP April 2004 1. Introduction This document performs two tasks. Firstly, it describes three common problems encountered with Digest authentication usage in SIP implementations. Secondly, it provides SIP implementers with a set of Digest authentication examples, complete with checkpoints, for the various stages of the Digest calculations. These examples can be used to test and prove implementations. This document does not comment on the benefits or deficiencies of HTTP Digest authentication compared to other possible authentication schemes. Similarly, HTTP Basic authentication is deprecated from SIP by RFC3261 [1] so is not covered by this document. It is assumed that the reader is familiar with RFC3261 [1] and RFC2617 [3]. 2. Common Mistakes 2.1 Quotation marks in Quality-of-protection (QOP) Description In typical SIP usage, the Quality-of-Protection (QOP) indicates whether the authentication digest includes a hash of the body of the SIP message or just the name and password of the caller. A challenging UAS may indicate which of these QOP options is supported by returning a list of permitted QOPs through the qop-options field of a challenge. The requesting UAC then chooses one of these QOPs and indicates which it has chosen through the message-qop field of the credentials. However, since the qop-options in a challenge consists of a comma separated list, the qop-value(s) associated with the qop-options MUST be surrounded by double-quotes. The message-qop in the resulting credentials consists of a single qop-value and MUST NOT be surrounded by double-quotes. Examples of "double-quotes in credentials" and "missing double-quotes in challenges", both of which are invalid, have been observed. Smith & Clarkson Expires - October 2004 [Page 3] Digest Authentication Examples for SIP April 2004 The ABNF in RFC2617 [3] that specifies this syntax is reproduced here. The challenge contains a qop-options, and the qop-values are surrounded by double-quotes. Note that this is true even if only a single qop-value is specified. challenge = "Digest" digest-challenge digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |[ stale ] | [ algorithm ] | [ qop-options ] | [auth-param] ) qop-options = "qop" "=" <"> 1#qop-value <"> qop-value = "auth" | "auth-int" | token The credentials contain a single message-qop value which is not surrounded by double quotes. credentials = "Digest" digest-response digest-response = 1#( username | realm | nonce | digest-uri | response | [ algorithm ] | [cnonce] | [opaque] | [message-qop] | [nonce-count] | [auth-param] ) message-qop = "qop" "=" qop-value The following examples, taken from RFC3261 [1], display this subtle point. The WWW-Authenticate header is an example of a challenge, whilst the Authorization header is an example of credentials. WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" Smith & Clarkson Expires - October 2004 [Page 4] Digest Authentication Examples for SIP April 2004 2.2 Absent QOP and qop=auth result in different digests Another common mistake arises from the following part of RFC2617 [3]. If the "qop" value is "auth" or "auth-int": request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) > <"> If the "qop" directive is not present (this construction is for compatibility with RFC 2069): request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <"> Although the values for A1 and A2 are the same regardless of whether the "qop" directive is unspecified or auth, the Digest is different. Smith & Clarkson Expires - October 2004 [Page 5] Digest Authentication Examples for SIP April 2004 2.3 Invalid validation of a nonce It has been observed that some implementations create, and then attempt to validate, nonces based on the contents of the request that has been challenged. This causes implementation problems where the partner does not maintain certain SIP header fields between the original and later, authenticated, request. RFC 3261 does not specify a mechanism for creating a nonce for use in an authentication challenge. An implementation is free to generate a nonce in whichever way it sees fit and may choose to do so such that it may be validated and stale nonces detected to avoid replay attacks. RFC3261 [1] section 8.1.3.5 describes how to act on receipt of a 4XX class response, including 401 and 407 challenges, and states the following: In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. This has been interpreted by some implementations to mean that an authenticated request can be relied upon to always contain the same Call-ID, To and From as the previous request. However this assumption is wrong in the case of dialog creating requests. If an initial dialog creating request fails, the dialog has ended. Reusing the same Call-ID and From tag appears to indicate that the dialog is expected to still exist. It does not and thus reuse of the same Call-ID and From tag should not be assumed. Nonces SHOULD NOT be generated based on information such as the Call- ID and tags unless a dialog has successfully been established and the request is therefore in-dialog. Smith & Clarkson Expires - October 2004 [Page 6] Digest Authentication Examples for SIP April 2004 3. Worked Examples This chapter gives worked examples of challenges and the resulting authorized requests using the various combinations of QOP and algorithm options defined in RFC2617 [3]. For each worked example, each phase of the generation of the request- dialog, the value assigned to the "response" parameter of the Authorization header, is presented. These examples, and the checkpoint values, may be used to test and prove new SIP implementations using Digest authentication. In order to remove any doubt regarding possible whitespace, the first example shows key values both using plain text and also the representation [5]. For each example, it may be assumed that a similar, but unauthorized, INVITE has been issued previously which the UAS has challenged. Many SIP header fields that are not pertinent to the explanation of the digest calculation have been omitted for clarity. Finally, it should be noted that in all cases, Bob's password is: zanzibar or 7a616e7a69626172 Smith & Clarkson Expires - October 2004 [Page 7] Digest Authentication Examples for SIP April 2004 3.1 Algorithm and QOP not specified 3.1.1 Challenge SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen From: Bob ;tag=9483056782 To: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE WWW-Authenticate: Digest realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Length: 0 3.1.2 Authenticated Request INVITE sip:alice@atlanta.com.com SIP/2.0 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Bob To: Alice ;tag=8493745023 Call-ID: ab734d9e6b793b CSeq: 83952 INVITE Contact: Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", nc=00000001, cnonce="0a4f113b", response="89eb0059246c02b2f6ee02c7961d5ea3", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) Smith & Clarkson Expires - October 2004 [Page 8] Digest Authentication Examples for SIP April 2004 3.1.3 Digest Generation Process The challenge contains no QOP information. In order to be compliant with RFC2617 [3], implementations SHOULD provide a qop-options field. This field is only optional in RFC2617 [3] for back-compatibility with RFC2069 [6]. However implementations may choose to handle this challenge in order to provide maximum chance of interoperating against other implementations. Given the absence of both algorithm and QOP, RFC2617 [3] defines A1 as: If the "algorithm" directive's value is "MD5" or is unspecified, then A1 is: A1 = unq(username-value) ":" unq(realm-value) ":" passwd where passwd = < user's password > This value of A1 is: bob:biloxi.com:zanzibar or 626f623a62696c6f78692e636f6d3a7a616e7a69626172 Using the definition of H(A1) given in RFC2617 [3], H(A1) has the following value: 12af60467a33e8518da5c68bbff12b11 From RFC2617 [3], A2 is defined as: If the "qop" directive's value is "auth" or is unspecified, then A2 is: A2 = Method ":" digest-uri-value The value of A2 is INVITE:sip:bob@biloxi.com Smith & Clarkson Expires - October 2004 [Page 9] Digest Authentication Examples for SIP April 2004 or 494e564954453a7369703a626f624062696c6f78692e636f6d H(A2) then has value: 13a14a3eb5e2c24732a1a04fff543e92 Finally, the Digest is given by the following: If the "qop" directive is not present (this construction is for compatibility with RFC 2069): request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <"> H(A1) and H(A2) have been calculated above. The nonce-value is provided by the server in the challenge. From the definition of KD given in RFC2617 [3] it follows that the request-digest has value <"> H(12af60467a33e8518da5c68bbff12b11: dcd98b7102dd2f0e8b11d0f600bfb0c093: 13a14a3eb5e2c24732a1a04fff543e92) <"> or <"> H(313261663630343637613333653835313864613563363862626666 31326231313a646364393862373130326464326630653862313164 306636303062666230633039333a31336131346133656235653263 32343733326131613034666666353433653932) <"> This results in a final value of: Digest = "bf57e4e0d0bffc0fbaedce64d59add5e" Smith & Clarkson Expires - October 2004 [Page 10] Digest Authentication Examples for SIP April 2004 3.2 auth and algorithm unspecified (MD5 assumed) 3.2.1 Challenge SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen From: Bob ;tag=9483056782 To: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Length: 0 3.2.2 Authenticated Request INVITE sip:alice@atlanta.com.com SIP/2.0 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Bob To: Alice ;tag=8493745023 Call-ID: ab734d9e6b793b CSeq: 83952 INVITE Contact: Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", qop=auth, nc=00000001, cnonce="0a4f113b", response="89eb0059246c02b2f6ee02c7961d5ea3", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) Smith & Clarkson Expires - October 2004 [Page 11] Digest Authentication Examples for SIP April 2004 3.2.3 Digest Generation Process Firstly, it should be noted that the challenge contained two qop- options, "auth" and "auth-int", and the UAC chose to use a message- qop of "auth". Secondly, no algorithm is specified in the challenge so the default value of MD5 is used. Given these values of algorithm and QOP, RFC2617 [3] defines A1 as: If the "algorithm" directive's value is "MD5" or is unspecified, then A1 is: A1 = unq(username-value) ":" unq(realm-value) ":" passwd where passwd = < user's password > This value of A1 is: bob:biloxi.com:zanzibar Using the definition of H(A1) given in RFC2617 [3], H(A1) has the following value: 12af60467a33e8518da5c68bbff12b11 From RFC2617 [3], A2 is defined as follows: If the "qop" directive's value is "auth" or is unspecified, then A2 is: A2 = Method ":" digest-uri-value Thus the value of A2 is INVITE:sip:bob@biloxi.com H(A2) then has value: 13a14a3eb5e2c24732a1a04fff543e92 Smith & Clarkson Expires - October 2004 [Page 12] Digest Authentication Examples for SIP April 2004 Finally, the Digest is given by the following: If the "qop" value is "auth" or "auth-int": request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) <"> H(A1) and H(A2) have been calculated above. The nonce-value is provided by the server in the challenge. The nonce-count (nc-value) and cnonce-value are generated by the client as per RFC2617 [3] and the qop-value is chosen from the qop-options proposed by the server. From the definition of KD given in RFC2617 [3] it follows that the request-digest has value <"> H(12af60467a33e8518da5c68bbff12b11: dcd98b7102dd2f0e8b11d0f600bfb0c093: 00000001: 0a4f113b: auth: 13a14a3eb5e2c24732a1a04fff543e92) <"> This results in a final value of: Digest = "89eb0059246c02b2f6ee02c7961d5ea3" Smith & Clarkson Expires - October 2004 [Page 13] Digest Authentication Examples for SIP April 2004 3.3 auth and MD5 3.3.1 Challenge SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen From: Bob ;tag=9483056782 To: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", algorithm=MD5, nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Length: 0 3.3.2 Authenticated Request INVITE sip:alice@atlanta.com.com SIP/2.0 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Bob To: Alice ;tag=8493745023 Call-ID: ab734d9e6b793b CSeq: 83952 INVITE Contact: Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", qop=auth, algorithm=MD5, nc=00000001, cnonce="0a4f113b", response="89eb0059246c02b2f6ee02c7961d5ea3", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) Smith & Clarkson Expires - October 2004 [Page 14] Digest Authentication Examples for SIP April 2004 3.3.3 Digest Generation Process No choice is allowed in the selection of an algorithm. The challenge indicates one, and only one algorithm and the challenged party must accept this choice or fail to present an authenticated request. The presence of MD5 as an algorithm is exactly equivalent to no algorithm being specified. Given these values of algorithm and QOP, RFC2617 [3] defines A1 as: If the "algorithm" directive's value is "MD5" or is unspecified, then A1 is: A1 = unq(username-value) ":" unq(realm-value) ":" passwd where passwd = < user's password > This value of A1 is: bob:biloxi.com:zanzibar Using the definition of H(A1) given in RFC2617 [3], H(A1) has the following value: 12af60467a33e8518da5c68bbff12b11 From RFC2617 [3], A2 is defined as follows: If the "qop" directive's value is "auth" or is unspecified, then A2 is: A2 = Method ":" digest-uri-value Thus the value of A2 is INVITE:sip:bob@biloxi.com H(A2) then has value: 13a14a3eb5e2c24732a1a04fff543e92 Smith & Clarkson Expires - October 2004 [Page 15] Digest Authentication Examples for SIP April 2004 Finally, the Digest is given by the following: If the "qop" value is "auth" or "auth-int": request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) <"> H(A1) and H(A2) have been calculated above. The nonce-value is provided by the server in the challenge. The nonce-count (nc-value) and cnonce-value are generated by the client as per RFC2617 [3] and the qop-value is chosen from the qop-options proposed by the server. From the definition of KD given in RFC2617 [3] it follows that the request-digest has value <"> H(12af60467a33e8518da5c68bbff12b11: dcd98b7102dd2f0e8b11d0f600bfb0c093: 00000001: 0a4f113b: auth: 13a14a3eb5e2c24732a1a04fff543e92) <"> This results in a final value of: Digest = "89eb0059246c02b2f6ee02c7961d5ea3" Smith & Clarkson Expires - October 2004 [Page 16] Digest Authentication Examples for SIP April 2004 3.4 auth and MD5-Sess 3.4.1 Challenge SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen From: Bob ;tag=9483056782 To: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", algorithm=MD5-sess, nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Length: 0 3.4.2 Authenticated Request INVITE sip:alice@atlanta.com.com SIP/2.0 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Bob To: Alice ;tag=8493745023 Call-ID: ab734d9e6b793b CSeq: 83952 INVITE Contact: Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", qop=auth, algorithm=MD5-sess, nc=00000001, cnonce="0a4f113b", response="89eb0059246c02b2f6ee02c7961d5ea3", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) Smith & Clarkson Expires - October 2004 [Page 17] Digest Authentication Examples for SIP April 2004 3.4.3 Digest Generation Process Algorithm MD5-sess can be used to implement a SIP server that never knows the actual password for a given user. The SIP server is required to request the password, through an undefined mechanism, from a 3rd party authentication server, which returns a digest of the password which can then be used to authenticate the user. Given these values of algorithm and QOP, RFC2617 [3] defines A1 as: If the "algorithm" directive's value is "MD5-sess" then A1 = H( unq(username-value) ":" unq(realm-value) ":" passwd ) ":" unq(nonce-value) ":" unq(cnonce-value) where passwd = < user's password > Now the MD5 hash of username-value, realm-value and passwd would normally be returned by the authentication server. This has the following value. H(bob:biloxi.com:zanzibar) or 12af60467a33e8518da5c68bbff12b11 So the value of A1 is: 12af60467a33e8518da5c68bbff12b11: dcd98b7102dd2f0e8b11d0f600bfb0c093: 0a4f113b Using the definition of H(A1) given in RFC2617 [3], H(A1) has the following value: 4f36886771c77832be5c5a8de5a7ec82 From RFC2617 [3], A2 is defined as follows: If the "qop" directive's value is "auth" or is unspecified, then A2 is: A2 = Method ":" digest-uri-value Smith & Clarkson Expires - October 2004 [Page 18] Digest Authentication Examples for SIP April 2004 Thus the value of A2 is INVITE:sip:bob@biloxi.com H(A2) then has value: 13a14a3eb5e2c24732a1a04fff543e92 Finally, the Digest is given by the following: If the "qop" value is "auth" or "auth-int": request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) <"> H(A1) and H(A2) have been calculated above. The nonce-value is provided by the server in the challenge. The nonce-count (nc-value) and cnonce-value are generated by the client as per RFC2617 [3] and the qop-value is chosen from the qop-options proposed by the server. From the definition of KD given in RFC2617 [3] it follows that the request-digest has value <"> H(4f36886771c77832be5c5a8de5a7ec82: dcd98b7102dd2f0e8b11d0f600bfb0c093: 00000001: 0a4f113b: auth: 13a14a3eb5e2c24732a1a04fff543e92) <"> This results in a final value of: Digest = "e4e4ea61d186d07a92c9e1f6919902e9" Smith & Clarkson Expires - October 2004 [Page 19] Digest Authentication Examples for SIP April 2004 3.5 auth-int and MD5 The use of qop value auth-int indicates that integrity protection is required. This means that the calculated digest includes a hash of the body of the authenticated message, which allows a change to the body of the message to be detected. This may lead to possible problems traversing Network Address Translators (NATs), Back-to-back UAs (B2BUAs) and Application Level Gateways (ALGs), any of which may modify the body in order to permit the SIP request to traverse some form of network boundary. In this case, the NAT/B2BUA/ALG must also act as an endpoint and police and possibly modify the authentication header. 3.5.1 Challenge SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen From: Bob ;tag=9483056782 To: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", algorithm=MD5, nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Length: 0 3.5.2 Authenticated Request INVITE sip:alice@atlanta.com.com SIP/2.0 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Bob To: Alice ;tag=8493745023 Call-ID: ab734d9e6b793b CSeq: 83952 INVITE Contact: Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", qop=auth-int, algorithm=MD5, nc=00000001, cnonce="0a4f113b", response="89eb0059246c02b2f6ee02c7961d5ea3", Smith & Clarkson Expires - October 2004 [Page 20] Digest Authentication Examples for SIP April 2004 opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type: application/sdp Content-Length: 142 v=0 o=bob 2890844526 2890844526 IN IP4 media.biloxi.com s= c=IN IP4 media.biloxi.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 3.5.3 Digest Generation Process No choice is allowed in the selection of an algorithm. The challenge indicates one, and only one algorithm (and thus no double-quotes are present) and the challenged party must accept this choice or fail to present an authenticated request. The presence of MD5 as an algorithm is exactly equivalent to no algorithm being specified. Given these values of algorithm and QOP, RFC2617 [3] defines A1 as: If the "algorithm" directive's value is "MD5" or is unspecified, then A1 is: A1 = unq(username-value) ":" unq(realm-value) ":" passwd where passwd = < user's password > This value of A1 is: bob:biloxi.com:zanzibar Using the definition of H(A1) given in RFC2617 [3], H(A1) has the following value: 12af60467a33e8518da5c68bbff12b11 From RFC2617 [3], A2 is defined as follows: Smith & Clarkson Expires - October 2004 [Page 21] Digest Authentication Examples for SIP April 2004 If the "qop" value is "auth-int", then A2 is: A2 = Method ":" digest-uri-value ":" H(entity-body) Thus the value of A2 is INVITE:sip:bob@biloxi.com:H(entity-body) entity-body consists of every byte comprising the body after the blank line that separates the SIP headers from the SIP body, up to the limit imposed by Content-Length or the end of the UDP datagram if no Content-Length field is present. Note that white-space is relevant in this case. Be careful of the presence, or absence, carriage return an/or linefeeds at the end of the data! Thus H(entity-body) is given by H(v=0 o=bob 2890844526 2890844526 IN IP4 media.biloxi.com s= c=IN IP4 media.biloxi.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 ) or H(763d300d0a6f3d626f622032383930383434353236203238393038343435 323620494e20495034206d656469612e62696c6f78692e636f6d0d0a733d 0d0a633d494e20495034206d656469612e62696c6f78692e636f6d0d0a74 3d3020300d0a6d3d617564696f203439313730205254502f41565020300d 0a613d7274706d61703a302050434d552f383030300d0a6d3d766964656f 203531333732205254502f4156502033310d0a613d7274706d61703a3331 20483236312f39303030300d0a6d3d766964656f20353330303020525450 2f4156502033320d0a613d7274706d61703a3332204d50562f3930303030 0d0a) H(entity-body) has the value cdecec3e3cfb5adda424cf356fdfedda H(A2) has the value: Smith & Clarkson Expires - October 2004 [Page 22] Digest Authentication Examples for SIP April 2004 eb79eb48bbd4fb2e5a13941f8218c029 Finally, the Digest is given by the following: If the "qop" value is "auth" or "auth-int": request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) <"> H(A1) and H(A2) have been calculated above. The nonce-value is provided by the server in the challenge. The nonce-count (nc-value) and cnonce-value are generated by the client as per RFC2617 [3] and the qop-value is chosen from the qop-options proposed by the server. From the definition of KD given in RFC2617 [3] it follows that the request-digest has value <"> H(12af60467a33e8518da5c68bbff12b11: dcd98b7102dd2f0e8b11d0f600bfb0c093: 00000001: 0a4f113b: auth-int: eb79eb48bbd4fb2e5a13941f8218c029) <"> This results in a final value of: Digest = "41f1bde42dcddbee8ae7d65fd3474dc0" Smith & Clarkson Expires - October 2004 [Page 23] Digest Authentication Examples for SIP April 2004 3.6 auth-int and MD5-Sess 3.6.1 Challenge SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKfjsduen From: Bob ;tag=9483056782 To: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", algorithm=MD5-sess, nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Length: 0 3.6.2 Authenticated Request INVITE sip:alice@atlanta.com.com SIP/2.0 Via: SIP/2.0/UDP s19.biloxi.com;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Bob To: Alice ;tag=8493745023 Call-ID: ab734d9e6b793b CSeq: 83952 INVITE Contact: Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:bob@biloxi.com", qop=auth-int, algorithm=MD5-sess, nc=00000001, cnonce="0a4f113b", response="89eb0059246c02b2f6ee02c7961d5ea3", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type: application/sdp Content-Length: 142 v=0 o=bob 2890844526 2890844526 IN IP4 media.biloxi.com s= c=IN IP4 media.biloxi.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 Smith & Clarkson Expires - October 2004 [Page 24] Digest Authentication Examples for SIP April 2004 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 3.6.3 Digest Generation Process Note that no choice is allowed in the selection of an algorithm. The challenge indicates one, and only one algorithm (and thus no double- quotes are present) and the challenged party must accept this choice it fail to present an authenticated request. Also note that the presence of MD5 as an algorithm is exactly equivalent to no algorithm being specified. Given these values of algorithm and QOP, RFC2617 [3] defines A1 as: If the "algorithm" directive's value is "MD5-sess" then A1 = H( unq(username-value) ":" unq(realm-value) ":" passwd ) ":" unq(nonce-value) ":" unq(cnonce-value) where passwd = < user's password > Now the MD5 hash of username-value, realm-value and passwd would normally be returned by the authentication server. This has the following value. H(bob:biloxi.com:zanzibar) or 12af60467a33e8518da5c68bbff12b11 So the value of A1 is: 12af60467a33e8518da5c68bbff12b11: dcd98b7102dd2f0e8b11d0f600bfb0c093: 0a4f113b Using the definition of H(A1) given in RFC2617 [3], H(A1) has the following value: 4f36886771c77832be5c5a8de5a7ec82 From RFC2617 [3], A2 is defined as follows: Smith & Clarkson Expires - October 2004 [Page 25] Digest Authentication Examples for SIP April 2004 If the "qop" value is "auth-int", then A2 is: A2 = Method ":" digest-uri-value ":" H(entity-body) Thus the value of A2 is INVITE:sip:bob@biloxi.com:H(entity-body) H(entity-body) is given by H(v=0 o=bob 2890844526 2890844526 IN IP4 media.biloxi.com s= c=IN IP4 media.biloxi.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 ) H(entity-body) has the value cdecec3e3cfb5adda424cf356fdfedda Finally, the Digest is given by the following: If the "qop" value is "auth" or "auth-int": request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" H(A2) ) <"> H(A1) and H(A2) have been calculated above. The nonce-value is provided by the server in the challenge. The nonce-count (nc-value) and cnonce-value are generated by the client as per RFC2617 [3] and the qop-value is chosen from the qop-options proposed by the server. From the definition of KD given in RFC2617 [3] it follows that the request-digest has value <"> H(4f36886771c77832be5c5a8de5a7ec82: dcd98b7102dd2f0e8b11d0f600bfb0c093: 00000001: Smith & Clarkson Expires - October 2004 [Page 26] Digest Authentication Examples for SIP April 2004 0a4f113b: auth-int: eb79eb48bbd4fb2e5a13941f8218c029) <"> This results in a final value of: Digest = "10e4c79b16d21d51995ab98083d134d8" Smith & Clarkson Expires - October 2004 [Page 27] Digest Authentication Examples for SIP April 2004 Security Considerations This document introduces no new protocol elements and therefore has no effect on the security of SIP. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 3261, June 2002 3 Franks, J., et al., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 Sparks, R., et al., "Session Initiation Protocol Torture Test Messages", Internet Draft, October 2003, Work in progress. 6 Franks, J., et al., "Extension to HTTP : Digest Access Authenticationö, RFC 2069, January 1997 Acknowledgments Paul and Ian would like to thank their colleagues at Data Connection for their input during the production of this document. Smith & Clarkson Expires - October 2004 [Page 28] Digest Authentication Examples for SIP April 2004 Authors' Addresses Paul D.Smith Data Connection Ltd 100 Church Street Enfield Middlesex EN2 6BQ United Kingdom Email: paul.d.smith@dataconnection.com Ian Clarkson Data Connection Ltd 100 Church Street Enfield Middlesex EN2 6BQ United Kingdom Email: ian.clarkson@dataconnection.com Smith & Clarkson Expires - October 2004 [Page 29]