sipping
Internet Draft Paul D.Smith
Expires: November 2005 Data Connection Ltd
Ian Clarkson
Data Connection Ltd
June 2005
Digest Authentication Examples for Session Initiation Protocol (SIP)
draft-smith-sipping-auth-examples-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 in November, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). 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 - November 2005 [Page 1]
Digest Authentication Examples for SIP June 2005
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
4. Changes.......................................................27
4.1 Changes since draft-smith-sip-auth-digest-00...............27
4.2 Changes since draft-smith-sipping-auth-digest-00...........27
Security Considerations..........................................28
IANA Considerations..............................................28
Normative References.............................................28
Informative 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 <hex> representations introduced in
draft-ietf-sipping-torture-tests [5] to specify the input and output
from cryptographic operations.
Smith & Clarkson Expires - November 2005 [Page 2]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 3]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 4]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 5]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 6]
Digest Authentication Examples for SIP June 2005
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 <hex>
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
<hex>7a616e7a69626172</hex>
Smith & Clarkson Expires - November 2005 [Page 7]
Digest Authentication Examples for SIP June 2005
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 <sip:bob@biloxi.com>;tag=9483056782
To: Alice <sip:alice@atlanta.com>;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 <sip:bob@biloxi.com>
To: Alice <sip:alice@atlanta.com>;tag=8493745023
Call-ID: ab734d9e6b793b
CSeq: 83952 INVITE
Contact: <sip:bob@s19.biloxi.com>
Authorization: Digest username="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:bob@biloxi.com",
nc=00000001,
cnonce="0a4f113b",
response="bf57e4e0d0bffc0fbaedce64d59add5e",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
Smith & Clarkson Expires - November 2005 [Page 8]
Digest Authentication Examples for SIP June 2005
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
<hex>626f623a62696c6f78692e636f6d3a7a616e7a69626172</hex>
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 - November 2005 [Page 9]
Digest Authentication Examples for SIP June 2005
or
<hex>494e564954453a7369703a626f624062696c6f78692e636f6d</hex>
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(<hex>313261663630343637613333653835313864613563363862626666
31326231313a646364393862373130326464326630653862313164
306636303062666230633039333a31336131346133656235653263
32343733326131613034666666353433653932</hex>) <">
This results in a final value of:
Digest = "bf57e4e0d0bffc0fbaedce64d59add5e"
Smith & Clarkson Expires - November 2005 [Page 10]
Digest Authentication Examples for SIP June 2005
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 <sip:bob@biloxi.com>;tag=9483056782
To: Alice <sip:alice@atlanta.com>;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 <sip:bob@biloxi.com>
To: Alice <sip:alice@atlanta.com>;tag=8493745023
Call-ID: ab734d9e6b793b
CSeq: 83952 INVITE
Contact: <sip:bob@s19.biloxi.com>
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 - November 2005 [Page 11]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 12]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 13]
Digest Authentication Examples for SIP June 2005
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 <sip:bob@biloxi.com>;tag=9483056782
To: Alice <sip:alice@atlanta.com>;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 <sip:bob@biloxi.com>
To: Alice <sip:alice@atlanta.com>;tag=8493745023
Call-ID: ab734d9e6b793b
CSeq: 83952 INVITE
Contact: <sip:bob@s19.biloxi.com>
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 - November 2005 [Page 14]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 15]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 16]
Digest Authentication Examples for SIP June 2005
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 <sip:bob@biloxi.com>;tag=9483056782
To: Alice <sip:alice@atlanta.com>;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 <sip:bob@biloxi.com>
To: Alice <sip:alice@atlanta.com>;tag=8493745023
Call-ID: ab734d9e6b793b
CSeq: 83952 INVITE
Contact: <sip:bob@s19.biloxi.com>
Authorization: Digest username="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:bob@biloxi.com",
qop=auth,
algorithm=MD5-sess,
nc=00000001,
cnonce="0a4f113b",
response="e4e4ea61d186d07a92c9e1f6919902e9",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
Smith & Clarkson Expires - November 2005 [Page 17]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 18]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 19]
Digest Authentication Examples for SIP June 2005
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 <sip:bob@biloxi.com>;tag=9483056782
To: Alice <sip:alice@atlanta.com>;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 <sip:bob@biloxi.com>
To: Alice <sip:alice@atlanta.com>;tag=8493745023
Call-ID: ab734d9e6b793b
CSeq: 83952 INVITE
Contact: <sip:bob@s19.biloxi.com>
Authorization: Digest username="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:bob@biloxi.com",
qop=auth-int,
algorithm=MD5,
nc=00000001,
cnonce="0a4f113b",
response="bdbeebb2da6adb6bca02599c2239e192",
Smith & Clarkson Expires - November 2005 [Page 20]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 21]
Digest Authentication Examples for SIP June 2005
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(<hex>763D300D0A6F3D626F622032383930383434353236203238393038343435
323620494E20495034206D656469612E62696C6F78692E636F6D0D0A733D
2D0D0A633D494E20495034206D656469612E62696C6F78692E636F6D0D0A
743D3020300D0A6D3D617564696F203439313730205254502F4156502030
0D0A613D7274706D61703A302050434D552F383030300D0A6D3D76696465
6F203531333732205254502F4156502033310D0A613D7274706D61703A33
3120483236312F39303030300D0A6D3D766964656F203533303030205254
502F4156502033320D0A613D7274706D61703A3332204D50562F39303030
300D0A</hex>)
H(entity-body) has the value
c1ed018b8ec4a3b170c0921f5b564e48
H(A2) has the value:
Smith & Clarkson Expires - November 2005 [Page 22]
Digest Authentication Examples for SIP June 2005
3e8ec46a56447dbb073e1171b1be0683
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:
3e8ec46a56447dbb073e1171b1be0683) <">
This results in a final value of:
Digest = "bdbeebb2da6adb6bca02599c2239e192"
Smith & Clarkson Expires - November 2005 [Page 23]
Digest Authentication Examples for SIP June 2005
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 <sip:bob@biloxi.com>;tag=9483056782
To: Alice <sip:alice@atlanta.com>;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 <sip:bob@biloxi.com>
To: Alice <sip:alice@atlanta.com>;tag=8493745023
Call-ID: ab734d9e6b793b
CSeq: 83952 INVITE
Contact: <sip:bob@s19.biloxi.com>
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="91984da2d8663716e91554859c22ca70",
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 - November 2005 [Page 24]
Digest Authentication Examples for SIP June 2005
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 - November 2005 [Page 25]
Digest Authentication Examples for SIP June 2005
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)
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
)
H(entity-body) has the value
c1ed018b8ec4a3b170c0921f5b564e48
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.
Smith & Clarkson Expires - November 2005 [Page 26]
Digest Authentication Examples for SIP June 2005
From the definition of KD given in RFC2617 [3] it follows that the
request-digest has value
<"> H(4f36886771c77832be5c5a8de5a7ec82:
dcd98b7102dd2f0e8b11d0f600bfb0c093:
00000001:
0a4f113b:
auth-int:
3e8ec46a56447dbb073e1171b1be0683) <">
This results in a final value of:
Digest = "91984da2d8663716e91554859c22ca70"
4. Changes
*** [Note to RFC editor. Please remove this entire section when this
draft is published as an RFC.] ***
4.1 Changes since draft-smith-sip-auth-digest-00
Moved to Sipping WG and renamed draft-smith-sipping-auth-digest-00.
Corrections to SDP subject field and resultant digest values.
Updated boiler place in accordance with RFC 3667 and RFC 3668.
4.2 Changes since draft-smith-sipping-auth-digest-00
Corrected calculated digests for sections 3.1 and 3.2.
Updated boiler place in accordance with RFC 3978 and RFC 3979.
Smith & Clarkson Expires - November 2005 [Page 27]
Digest Authentication Examples for SIP June 2005
Security Considerations
This document introduces no new protocol elements and therefore has
no effect on the security of SIP.
IANA Considerations
This document has no actions for IANA.
Normative 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
Informative References
None.
Acknowledgments
Paul and Ian would like to thank their colleagues at Data Connection
for their input during the production of this document, and WG
members for useful feedback.
Smith & Clarkson Expires - November 2005 [Page 28]
Digest Authentication Examples for SIP June 2005
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
Disclaimer of validity
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.
Smith & Clarkson Expires - November 2005 [Page 29]
Digest Authentication Examples for SIP June 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
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.
Smith & Clarkson Expires - November 2005 [Page 30]