draft-ietf-sipcore-digest-scheme-08.txt   draft-ietf-sipcore-digest-scheme-09.txt 
SIP Core R. Shekh-Yusef SIP Core R. Shekh-Yusef
Internet-Draft Avaya Internet-Draft Avaya
Updates: 3261 (if approved) July 3, 2019 Updates: 3261 (if approved) September 16, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: January 4, 2020 Expires: March 19, 2020
The Session Initiation Protocol (SIP) Digest Authentication Scheme The Session Initiation Protocol (SIP) Digest Authentication Scheme
draft-ietf-sipcore-digest-scheme-08 draft-ietf-sipcore-digest-scheme-09
Abstract Abstract
This document updates RFC 3261 by updating the Digest Access This document updates RFC 3261 by updating the Digest Access
Authentication scheme used by the Session Initiation Protocol (SIP) Authentication scheme used by the Session Initiation Protocol (SIP)
to add support for more secure digest algorithms, e.g. SHA-256 and to add support for more secure digest algorithms, e.g. SHA-256 and
SHA-512-256, to replace the broken MD5 algorithm, which might be used SHA-512-256, to replace the broken MD5 algorithm, which might be used
for backward compatibility reasons only. for backward compatibility reasons only.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 January 4, 2020. This Internet-Draft will expire on March 19, 2020.
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 3, line 22 skipping to change at page 3, line 22
future. 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 algorithms listed in the "Hash Algorithms for HTTP SIP to support the algorithms listed in the "Hash Algorithms for HTTP
Digest Authentication" registry defined by [RFC7616]. Digest Authentication" registry defined by [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 [RFC8174].
2. SIP Digest Authentication Scheme Updates 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
algorithms defined in the "Hash Algorithms for HTTP Digest algorithms defined in the "Hash Algorithms for HTTP Digest
Authentication" registry described in [RFC7616]. Authentication" registry described in [RFC7616].
It replaces the reference to [RFC2617] with a reference to [RFC7616] It replaces the reference to [RFC2617] with a reference to [RFC7616]
in [RFC3261], and describes the modifications to the usage of the in [RFC3261], and describes the modifications to the usage of the
skipping to change at page 5, line 39 skipping to change at page 5, line 39
If a request is forked, various proxy servers and/or UAs may wish to 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 challenge the UAC. In this case, the forking proxy server is
responsible for aggregating these challenges into a single response. responsible for aggregating these challenges into a single response.
Each WWW-Authenticate and Proxy-Authenticate value received in Each WWW-Authenticate and Proxy-Authenticate value received in
responses to the forked request MUST be placed into the single responses to the forked request MUST be placed into the single
response that is sent by the forking proxy to the UAC. response that is sent by the forking proxy to the UAC.
When the forking proxy places multiple WWW-Authenticate and Proxy- When the forking proxy places multiple WWW-Authenticate and Proxy-
Authenticate header fields from one received response into the single Authenticate header fields from one received response into the single
response it MUST maintain the order of these header fields. The response it MUST maintain the order of these header fields. The
ordering of the header field values from the various proxies is not ordering of values received from proxies relative to values received
significant. from other proxies is not significant.
2.6. HTTP Digest Authentication Scheme Modifications 2.6. HTTP Digest Authentication Scheme Modifications
This section describes the modifications and clarifications required This section describes the modifications and clarifications required
to apply the HTTP Digest authentication scheme to SIP. The SIP to apply the HTTP Digest authentication scheme to SIP. The SIP
scheme usage is similar to that for HTTP. For completeness, the scheme usage is similar to that for HTTP. For completeness, the
bullets specified below are mostly copied from section 22.4 of bullets specified below are mostly copied from section 22.4 of
[RFC3261]; the only semantic changes are specified in bullets 1, 7, [RFC3261]; the only semantic changes are specified in bullets 1, 7,
and 8 below. and 8 below.
SIP clients and servers MUST NOT accept or request Basic SIP clients and servers MUST NOT accept or request Basic
authentication. authentication.
The rules for Digest authentication follow those defined in HTTP, The rules for Digest authentication follow those defined in HTTP,
with "HTTP/1.1" [RFC7616] replaced by "SIP/2.0" in addition to the with "HTTP/1.1" [RFC7616] replaced by "SIP/2.0" in addition to the
following differences: following differences:
1. The URI included in the challenge has the following BNF: 1. The URI included in the challenge has the following BNF
[RFC5234]:
URI = Request-URI ; as defined in [RFC3261], Section 25 URI = Request-URI ; as defined in [RFC3261], Section 25
2. The 'uri' parameter of the Authorization header field MUST be 2. The 'uri' parameter of the Authorization header field MUST be
enclosed in quotation marks. enclosed in quotation marks.
3. The BNF for digest-uri-value is: 3. The BNF for digest-uri-value is:
digest-uri-value = Request-URI digest-uri-value = Request-URI
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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 with the This specification adds new secure algorithms to be used 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.
This opens the system to the potential of a downgrade attack by man- This opens the system to the potential of a downgrade attack by an
in-the-middle. The most effective way of dealing with this type of on-path attacker. The most effective way of dealing with this type
attack is to either validate the client and challenge it accordingly, of attack is to either validate the client and challenge it
or remove the support for backward compatibility by not supporting accordingly, or remove the support for backward compatibility by not
MD5. supporting 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 specifies that algorithms defined in in the future. This document specifies that algorithms defined in
that registry may be used in SIP digest authentication. that registry may be used in SIP digest authentication.
This document has no actions for IANA. This document has no actions for IANA.
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, Brian Rosen, and Jean Mahoney. Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, and Adam
Roach.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References 6.2. Informative References
[RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D. [RFC2617] Franks, J., M. Hallam-Baker, P., L. Hostetler, J., D.
Lawrence, S., J. Leach, P., Luotonen, A., and L. C. Lawrence, S., J. Leach, P., Luotonen, A., and L. C.
Stewart, "HTTP Authentication: Basic and Digest Access Stewart, "HTTP Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999. Authentication", RFC 2617, June 1999.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
 End of changes. 11 change blocks. 
17 lines changed or deleted 20 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/