draft-ietf-sipcore-digest-scheme-02.txt   draft-ietf-sipcore-digest-scheme-03.txt 
SIP Core R. Shekh-Yusef SIP Core R. Shekh-Yusef
Internet-Draft Avaya Internet-Draft Avaya
Updates: 3261 (if approved) May 9, 2019 Updates: 3261 (if approved) May 26, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: November 10, 2019 Expires: November 27, 2019
The Session Initiation Protocol (SIP) Digest Authentication Scheme The Session Initiation Protocol (SIP) Digest Authentication Scheme
draft-ietf-sipcore-digest-scheme-02 draft-ietf-sipcore-digest-scheme-03
Abstract Abstract
This document updates the Digest Access Authentication scheme used by This document updates the Digest Access Authentication scheme used by
the Session Initiation Protocol (SIP) to add support for secure the Session Initiation Protocol (SIP) to add support for more secure
digest algorithms to replace the broken MD5 algorithm. digest algorithms, e.g. SHA-256 and SHA-512-256, to replace the
broken MD5 algorithm.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2019. This Internet-Draft will expire on November 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Updated SIP Digest Authentication Scheme . . . . . . . . 3 2. SIP Digest Authentication Scheme Updates . . . . . . . . . . 3
2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3 2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3
2.2. Representation of Digest Values . . . . . . . . . . . . . 3 2.2. Representation of Digest Values . . . . . . . . . . . . . 4
2.3. The Authenticate Response Header Field . . . . . . . . . 4 2.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 4
2.4. The Authorization Request Header Field . . . . . . . . . 4 2.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6. HTTP Modifications . . . . . . . . . . . . . . . . . . . 5 2.6. HTTP Modifications . . . . . . . . . . . . . . . . . . . 5
2.7. Augmented BNF for the SIP Protocol . . . . . . . . . . . 6 2.7. Augmented BNF for the SIP Protocol . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The SIP protocol [RFC3261] uses the same mechanism used by the HTTP The SIP protocol [RFC3261] uses the same mechanism used by the HTTP
protocol for authenticating users, which is a simple challenge- protocol for authenticating users, which is a simple challenge-
response authentication mechanism that allows a server to challenge a response authentication mechanism that allows a server to challenge a
client request and allows a client to provide authentication client request and allows a client to provide authentication
information in response to that challenge. information in response to that challenge.
The SIP protocol uses the Digest Authentication scheme that is used The SIP protocol uses the Digest Authentication scheme that is used
with the HTTP authentication mechanism, which by default uses MD5 as with the HTTP authentication mechanism, which uses MD5 as the default
the default algorithm. algorithm.
The HTTP Digest Access Authentication [RFC7616] document defines the The HTTP Digest Access Authentication [RFC7616] document defines the
Digest Authentication scheme and defines a few algorithms that could Digest Authentication scheme and defines a few algorithms that could
be used with the Digest Authentication scheme, and establishes a be used with the Digest Authentication scheme, and establishes a
registry for these algorithms to allow for additional algorithms to registry for these algorithms to allow for additional algorithms to
be added in the future. be added in the future.
This document updates the Digest Access Authentication scheme used by This document updates the Digest Access Authentication scheme used by
SIP to support the list of digest algorithms defined in the "Hash SIP to support the algorithms defined in the "Hash Algorithms for
Algorithms for HTTP Digest Authentication" registry defined by HTTP Digest Authentication" registry defined by [RFC7616].
[RFC7616].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. The Updated SIP Digest Authentication Scheme 2. SIP Digest Authentication Scheme Updates
This section describes the modifications to the operation of the This section describes the modifications to the operation of the
Digest mechanism as specified in [RFC3261] in order to support the Digest mechanism as specified in [RFC3261] in order to support the
SHA- 256 and SHA-512/256 algorithms as described in [RFC7616], and algorithms defined in the "Hash Algorithms for HTTP Digest
also to require support for the "qop" option." Authentication" registry described in [RFC7616].
It replaces the reference to [RFC2617] with a reference to [RFC7616]
in [RFC3261], and describes the modifications to the usage of the
Digest mechanism in [RFC3261] resulting from that reference update.
It adds support for the SHA-256 and SHA-512/256 algorithms. It adds
required support for the "qop" option. It provides additional UAC
and UAS procedures regarding usage of multiple SIP Authorization,
WWW-Authenticate and Proxy-Authenticate header fields, including in
which order to insert and process them. It provides guidance
regarding forking. Finally, it updates the SIP protocol BNF as
required by the updates.
2.1. Hash Algorithms 2.1. Hash Algorithms
The Digest scheme has an 'algorithm' parameter that specifies the The Digest scheme has an 'algorithm' parameter that specifies the
algorithm to be used to compute the digest of the response. The IANA algorithm to be used to compute the digest of the response. The IANA
registry named "HTTP Digest Hash Algorithms" specifies the algorithms registry named "HTTP Digest Hash Algorithms" specifies the algorithms
that correspond to 'algorithm' values, and specifies a priority for that correspond to 'algorithm' values, and specifies a priority for
each algorithm. each algorithm.
[RFC3261] specifies only one algorithm, MD5, which is used by [RFC3261] specifies only one algorithm, MD5, which is used by
default. This document extends [RFC3261] to allow use of any default. This document extends [RFC3261] to allow use of any
registered algorithm. registered algorithm.
The priority of the algorithm defines its usage preference. UAs A UAS prioritizes which algorithm to use based on the ordering of the
SHOULD prefer algorithms with higher priorities. challenge header fields in the response it is processing. That
process is specified in section 2.3 and parallels the process used in
Note that [RFC7616] defines a -sess variant for each algorithm; the HTTP specified by [RFC7616].
-sess variants are not used with SIP.
2.2. Representation of Digest Values 2.2. Representation of Digest Values
The size of the digest depends on the algorithm used. The bits in The size of the digest depends on the algorithm used. The bits in
the digest are converted from the most significant to the least the digest are converted from the most significant to the least
significant bit, four bits at a time to the ASCII representation as significant bit, four bits at a time to the ASCII representation as
follows. Each four bits is represented by its familiar hexadecimal follows. Each four bits is represented by its familiar hexadecimal
notation from the characters 0123456789abcdef, that is binary 0000 is notation from the characters 0123456789abcdef, that is binary 0000 is
represented by the character '0', 0001 by '1' and so on up to the 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 representation of 1111 as 'f'. If the MD5 algorithm is used to
calculate the digest, then the digest will be represented as 32 calculate the digest, then the digest will be represented as 32
hexadecimal characters, SHA-256 and SHA-512/256 by 64 hexadecimal hexadecimal characters, SHA-256 and SHA-512/256 by 64 hexadecimal
characters. characters.
2.3. The Authenticate Response Header Field 2.3. UAS Behavior
When a UAS receives a request from a UAC, and an acceptable When a UAS receives a request from a UAC, and an acceptable
Authorization header field is not sent, the UAS can challenge the Authorization header field is not sent, the UAS can challenge the
originator to provide credentials by rejecting the request with a originator to provide credentials by rejecting the request with a
401/407 status code with the WWW-Authenticate/Proxy-Authenticate 401/407 status code with the WWW-Authenticate/Proxy-Authenticate
header field. The UAS MAY include multiple WWW-Authenticate/Proxy- header field respectively. The UAS MAY include multiple WWW-
Authenticate headers to allow the UAS to utilize the best available Authenticate/Proxy-Authenticate header fields to allow the UAS to
algorithm supported by the client. utilize the best available algorithm supported by the client.
If the UAS challenges with multiple WWW-Authenticate/Proxy- If the UAS challenges with multiple WWW-Authenticate/Proxy-
Authenticate headers with the same realm, then each one of these Authenticate header fields with the same realm, then each one of
headers MUST use a different digest algorithm. The UAS MUST add these header fields MUST use a different digest algorithm. The UAS
these headers to the response in the order that it would prefer to MUST add these header fields to the response in the order that it
see them used, starting with the most preferred algorithm at the top, would prefer to see them used, starting with the most preferred
followed by the less preferred algorithms. algorithm at the top, followed by the less preferred algorithms. The
UAS cannot assume that the client will use the algorithm specified at
the topmost header field.
2.4. The Authorization Request Header Field 2.4. UAC Behavior
When the UAC receives a response with multiple header fields with the When the UAC receives a response with multiple header fields with the
same realm it SHOULD use the topmost header field that it supports, same realm it SHOULD use the topmost header field that it supports,
unless a local policy dictates otherwise. The client MUST ignore any unless a local policy dictates otherwise. The client MUST ignore any
challenge it does not understand. challenge it does not understand.
When the UAC receives a 401 response with multiple WWW-Authenticate When the UAC receives a 401 response with multiple WWW-Authenticate
header fields with different realms it SHOULD retry and include an header fields with different realms it SHOULD retry and include an
Authorization header field containing credentials that match the Authorization header field containing credentials that match the
topmost header field of any one of the realms. topmost header field of any one of the realms.
skipping to change at page 6, line 49 skipping to change at page 7, line 15
2.7. Augmented BNF for the SIP Protocol 2.7. Augmented BNF for the SIP Protocol
This document updates the Augmented BNF for the SIP Protocol as This document updates the Augmented BNF for the SIP Protocol as
follows. follows.
It extends the request-digest as follows to allow for different It extends the request-digest as follows to allow for different
digest sizes: digest sizes:
request-digest = LDQUOT *LHEX RDQUOT request-digest = LDQUOT *LHEX RDQUOT
The number of hex digits must be specified by the specification of The number of hex digits is implied by the length of the value of the
the algorithm used. algorithm used.
It extends the algorithm parameter as follows to allow for SHA2 It extends the algorithm parameter as follows to allow for any
algorithms to be used: algorithm in the registry to be used:
algorithm = "algorithm" EQUAL ( "MD5" / "SHA-512-256" / "SHA-256" algorithm = "algorithm" EQUAL ( "MD5" / "SHA-512-256" / "SHA-256"
/ token ) / token )
3. Security Considerations 3. Security Considerations
This specification adds new secure algorithms to be used to with the This specification adds new secure algorithms to be used to with the
Digest mechanism to authenticate users, but leaves the broken MD5 Digest mechanism to authenticate users, but leaves the broken MD5
algorithm for backward compatibility. algorithm for backward compatibility.
skipping to change at page 7, line 30 skipping to change at page 7, line 43
or remove the support for backward compatibility by not supporting or remove the support for backward compatibility by not supporting
MD5. MD5.
See section 5 of [RFC7616] for a detailed security discussion of the See section 5 of [RFC7616] for a detailed security discussion of the
Digest scheme. Digest scheme.
4. IANA Considerations 4. IANA Considerations
[RFC7616] defines an IANA registry named "Hash Algorithms for HTTP [RFC7616] defines an IANA registry named "Hash Algorithms for HTTP
Digest Authentication" to simplify the introduction of new algorithms Digest Authentication" to simplify the introduction of new algorithms
in the future. This document will use the algorithms defined in that in the future. This document specifies that algorithms defined in
registry. that registry may be used in SIP digest authentication.
5. Acknowledgments 5. Acknowledgments
The author would like to thank the following individuals for their The author would like to thank the following individuals for their
careful reviews, comments, and suggestions: Paul Kyzivat, Olle careful reviews, comments, and suggestions: Paul Kyzivat, Olle
Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga
Asveren, Christer Holmberg, and Brian Rosen. Asveren, Christer Holmberg, and Brian Rosen.
6. Normative References 6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June
2014. 2014.
[RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest [RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
Access Authentication", RFC 7616, September 2015. Access Authentication", RFC 7616, September 2015.
6.2. Informative References
[RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D.
Lawrence, S., J. Leach, P., Luotonen, A., and L. C.
Stewart, "HTTP Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999.
Author's Address Author's Address
Rifaat Shekh-Yusef Rifaat Shekh-Yusef
Avaya Avaya
425 Legget Dr. 425 Legget Dr.
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Phone: +1-613-595-9106 Phone: +1-613-595-9106
EMail: rifaat.ietf@gmail.com EMail: rifaat.ietf@gmail.com
 End of changes. 23 change blocks. 
44 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/