SIPCORE Working Group R. Shekh-Yusef
INTERNET-DRAFT Avaya
Intended Status: Standards Track January 17, 2014
Expires: July 21, 2014
The Session Initiation Protocol (SIP) Digest Authentication Scheme
draft-yusef-sipcore-digest-scheme-02
Abstract
This document updates the Digest Access Authentication scheme used by
the Session Initiation Protocol (SIP) to add support for SHA2 digest
algorithms to replace the MD5 algorithm.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Shekh-Yusef Expires July 21, 2014 [Page 1]
INTERNET DRAFT SIP Digest Authentication Scheme January 17, 2014
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 The SIP Digest Authentication Scheme . . . . . . . . . . . . . 4
2.1 Hash Algorithms . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Representation of Digest Values . . . . . . . . . . . . . . 4
2.3 The Authenticate Response Header . . . . . . . . . . . . . 4
2.4 The Authorization Request Header . . . . . . . . . . . . . 5
2.5 Forking . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6 HTTP Modifications . . . . . . . . . . . . . . . . . . . . 5
3 Augmented BNF for the SIP Protocol . . . . . . . . . . . . . . 7
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Normative References . . . . . . . . . . . . . . . . . . . 8
7.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Shekh-Yusef Expires July 21, 2014 [Page 2]
INTERNET DRAFT SIP Digest Authentication Scheme January 17, 2014
1 Introduction
The SIP protocol [RFC3261] uses the same mechanism used by the HTTP
protocol for authenticating users, which is a simple challenge-
response authentication mechanism that allows a server to challenge a
client request and allows a client to provide authentication
information in response to that challenge.
The SIP protocol uses the Digest Authentication scheme that is used
with the HTTP authentication mechanism, which by default uses MD5 as
the default algorithm.
The HTTP Digest Access Authentication [HTTP-DIGEST] document defines
the challenge-response authentication mechanism and the Digest
Authentication scheme, and defines few algorithms that could be used
with the Digest Authentication scheme, and establishes a registry for
these algorithms to allow for additional algorithms to be added in
the future.
In 2008 the US-CERT issued a note that MD5 "should be considered
cryptographically broken and unsuitable for further use" [CERT-VU].
This document updates the Digest Access Authentication scheme used by
SIP to add support for SHA2 digest algorithms to replace the MD5
algorithm.
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 RFC 2119 [RFC2119].
Shekh-Yusef Expires July 21, 2014 [Page 3]
INTERNET DRAFT SIP Digest Authentication Scheme January 17, 2014
2 The SIP Digest Authentication Scheme
This section describes the modifications to the operation of the
Digest mechanism as specified in RFC3261.
2.1 Hash Algorithms
The Digest scheme has an 'algorithm' parameter that specifies the
algorithm to be used to compute the digest of the response.
RFC3261 specifies only one algorithm, MD5, which is used by default.
This document adds two new algorithms, to align with the [HTTP-
DIGEST], that SHOULD be used instead of MD5: SHA2-256 & SHA2-512/256.
This document defines the following preference list, starting with
the most preferred algorithm:
* SHA2-256 (most preferred)
* SHA2-512/256
* MD5 (least preferred)
2.2 Representation of Digest Values
The size of the digest depends on the algorithm used. The bits in
the digest are converted from the most significant to the least
significant bit, four bits at a time to the ASCII representation as
follows. Each four bits is represented by its familiar hexadecimal
notation from the characters 0123456789abcdef, that is binary 0000 is
represented by the character '0', 0001 by '1' and so on up to the
representation of 1111 as 'f'. If the MD5 algorithm is used to
calculate the digest, then the digest will be represented as 32
hexadecimal characters, SHA2-256 and SHA2-512/256 by 64 hexadecimal
characters.
2.3 The Authenticate Response Header
When a UAS receives a request from a UAC, and an acceptable
Authorization header is not sent, the UAS can challenge the
originator to provide credentials by rejecting the request with a
401/407 status code with the WWW-Authenticate/Proxy-Authenticate
header field. The UAS MAY include multiple WWW-Authenticate/Proxy-
Authenticate headers to allow the UAS to utilize the best available
algorithm supported by the client.
If the UAS challenges with multiple WWW-Authenticate/Proxy-
Shekh-Yusef Expires July 21, 2014 [Page 4]
INTERNET DRAFT SIP Digest Authentication Scheme January 17, 2014
Authenticate headers, then each one of these headers MUST use a
different digest algorithm. The UAS MUST add these headers to the
response in order of strength of the algorithm, starting with the
strongest algorithm, followed by the less strong algorithms.
2.4 The Authorization Request Header
When the UAC receives the response it SHOULD use the topmost header
that it supports, unless a local policy dictates otherwise. The
client should ignore any challenge it does not understand.
If the UAC does not support any of the algorithms in the response,
then it should abandon attempts to send the request.
2.5 Forking
RFC3261, section 22.3, discusses the operation of the proxy-to-user
authentication, which describes the operation of the proxy when it
forks a request. This section introduces some clarification to that
operation.
If a request is forked, various proxy servers and/or UAs may wish to
challenge the UAC. In this case, the forking proxy server is
responsible for aggregating these challenges into a single response.
Each WWW-Authenticate and Proxy-Authenticate value received in
responses to the forked request MUST be placed into the single
response that is sent by the forking proxy to the UA.
When the forking proxy places multiple WWW-Authenticate and Proxy-
Authenticate header fields from one proxy into the single response it
MUST maintain the order of these header fields. The ordering of the
header field values from the various proxies is not significant.
2.6 HTTP Modifications
This section describes the modifications and clarifications required
to apply the HTTP Digest authentication scheme to SIP. The SIP scheme
usage is almost completely identical to that for HTTP.
SIP clients and servers MUST NOT accept or request Basic
authentication.
The rules for Digest authentication follow those defined in HTTP,
with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following
differences:
Shekh-Yusef Expires July 21, 2014 [Page 5]
INTERNET DRAFT SIP Digest Authentication Scheme January 17, 2014
1. The URI included in the challenge has the following BNF:
URI = SIP-URI / SIPS-URI
2. The BNF for digest-uri-value is:
digest-uri-value = Request-URI ; as defined in Section 25
3. The example procedure for choosing a nonce based on Etag does not
work for SIP.
4. The text in RFC 2617 [17] regarding cache operation does not
apply to SIP.
5. RFC 2617 requires that a server check that the URI in the
request line and the URI included in the Authorization header
field point to the same resource. In a SIP context, these two
URIs may refer to different users, due to forwarding at some
proxy. Therefore, in SIP, a server MAY check that the
Request-URI in the Authorization header field value
corresponds to a user for whom the server is willing to accept
forwarded or direct requests, but it is not necessarily a
failure if the two fields are not equivalent.
6. As a clarification to the calculation of the A2 value for
message integrity assurance in the Digest authentication
scheme, implementers should assume, when the entity-body is
empty (that is, when SIP messages have no body) that the hash
of the entity-body resolves to the hash of an empty
string, or:
H(entity-body) = MD5("") =
"d41d8cd98f00b204e9800998ecf8427e"
H(entity-body) = SHA2-256("") =
"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
H(entity-body) = SHA2-512-256("") =
"c672b8d1ef56ed28ab87c3622c5114069bdd3ad7b8f9737498d0c01ecef0967a"
Shekh-Yusef Expires July 21, 2014 [Page 6]
INTERNET DRAFT SIP Digest Authentication Scheme January 17, 2014
7. Servers MUST be able to properly handle "qop" parameter received
in an authorization header field, and clients MUST be able to
properly handle "qop" parameter received in WWW-Authenticate and
Proxy-Authenticate header fields.
Servers MUST always send a "qop" parameter in WWW-Authenticate
and Proxy-Authenticate header field values, and clients MUST
send the "qop" parameter in any resulting authorization header
field.
The usage of the Authentication-Info header field continue to be
allowed, since it provides integrity checks over the bodies and
provides mutual authentication.
[OPEN ISSUE]
This section does NOT maintain backward compatibility with RFC 2543.
3 Augmented BNF for the SIP Protocol
This document updates the Augmented BNF for the SIP Protocol as
follows.
It extends the request-digest as follows to allow for different
digest sizes:
request-digest = LDQUOT 32LHEX RDQUOT / LDQUOT 64LHEX RDQUOT
It extends the algorithm parameter as follows to allow for SHA2
algorithms to be used:
algorithm = "algorithm" EQUAL (
"MD5" / "MD5-sess" /
"SHA2-256" / "SHA2-256-sess" /
"SHA2-512-256" / "SHA2-512-256-sess" /
token )
4 Security Considerations
<Security considerations text>
Shekh-Yusef Expires July 21, 2014 [Page 7]
INTERNET DRAFT SIP Digest Authentication Scheme January 17, 2014
5 IANA Considerations
The [HTTP-DIGEST] defines an IANA registry named "HTTP Digest Hash
Algorithms" to simplify the introduction of new algorithms in the
future. This document will use the algorithms defined in that
registry.
6 Acknowledgments
<Acknowledgments text>
7 References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[HTTP-DIGEST] Shekh-Yusef, R., Ahrens, D., and Bremer, S., "HTTP
Digest Access Authentication", Work in Progress, January
2014.
https://datatracker.ietf.org/doc/draft-ietf-httpauth-
digest/
7.2 Informative References
Authors' Addresses
Rifaat Shekh-Yusef
Avaya
250 Sydney Street
Belleville, Ontario
Canada
Phone: +1-613-967-5267
Email: rifaat.ietf@gmail.com
Shekh-Yusef Expires July 21, 2014 [Page 8]
INTERNET DRAFT SIP Digest Authentication Scheme January 17, 2014
Shekh-Yusef Expires July 21, 2014 [Page 9]