< draft-ietf-sipcore-digest-scheme-00.txt   draft-ietf-sipcore-digest-scheme-01.txt >
SIP Core R. Shekh-Yusef SIP Core R. Shekh-Yusef
Internet-Draft Avaya Internet-Draft Avaya
Updates: 3261 (if approved) April 18, 2019 Updates: 3261 (if approved) May 7, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: October 20, 2019 Expires: November 8, 2019
The Session Initiation Protocol (SIP) Digest Authentication Scheme The Session Initiation Protocol (SIP) Digest Authentication Scheme
draft-ietf-sipcore-digest-scheme-00 draft-ietf-sipcore-digest-scheme-01
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 secure
digest algorithms to replace the broken MD5 algorithm. digest algorithms 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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 October 20, 2019. This Internet-Draft will expire on November 8, 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 24 skipping to change at page 2, line 24
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 SIP Digest Authentication Scheme . . . . . . . . . . . . 3 2. The SIP Digest Authentication Scheme . . . . . . . . . . . . 3
2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3 2.1. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 3
2.2. Representation of Digest Values . . . . . . . . . . . . . 3 2.2. Representation of Digest Values . . . . . . . . . . . . . 3
2.3. The Authenticate Response Header . . . . . . . . . . . . 4 2.3. The Authenticate Response Header Field . . . . . . . . . 4
2.4. The Authorization Request Header . . . . . . . . . . . . 4 2.4. The Authorization Request Header Field . . . . . . . . . 4
2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.5. Forking . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6. HTTP Modifications . . . . . . . . . . . . . . . . . . . 5 2.6. HTTP Modifications . . . . . . . . . . . . . . . . . . . 5
3. Augmented BNF for the SIP Protocol . . . . . . . . . . . . . 6 3. Augmented BNF for the SIP Protocol . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
skipping to change at page 4, line 9 skipping to change at page 4, line 9
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 2.3. The Authenticate Response Header Field
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 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. The UAS MAY include multiple WWW-Authenticate/Proxy-
Authenticate headers to allow the UAS to utilize the best available Authenticate headers to allow the UAS to utilize the best available
algorithm supported by the client. 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 headers with the same realm, then each one of these
headers MUST use a different digest algorithm. The UAS MUST add headers MUST use a different digest algorithm. The UAS MUST add
these headers to the response in the order that it would prefer to these headers to the response in the order that it would prefer to
see them used, starting with the most preferred algorithm at the top, see them used, starting with the most preferred algorithm at the top,
followed by the less preferred algorithms. followed by the less preferred algorithms.
2.4. The Authorization Request Header 2.4. The Authorization Request Header Field
When the UAC receives a response with multiple headers with the same When the UAC receives a response with multiple header fields with the
realm it SHOULD use the topmost header that it supports, unless a same realm it SHOULD use the topmost header field that it supports,
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
headers with different realms it SHOULD retry and include an header fields with different realms it SHOULD retry and include an
Authorization header containing credentials that match the topmost Authorization header field containing credentials that match the
header of any one of the realms. topmost header field of any one of the realms.
If the UAC cannot respond to any of the challenges in the response, If the UAC cannot respond to any of the challenges in the response,
then it should abandon attempts to send the request; e.g., if the UAC then it should abandon attempts to send the request; e.g., if the UAC
does not have credentials for any of the realms. does not have credentials for any of the realms.
2.5. Forking 2.5. Forking
Section 22.3 of [RFC3261] discusses the operation of the proxy-to- Section 22.3 of [RFC3261] discusses the operation of the proxy-to-
user authentication, which describes the operation of the proxy when user authentication, which describes the operation of the proxy when
it forks a request. This section introduces some clarification to it forks a request. This section introduces some clarification to
skipping to change at page 5, line 22 skipping to change at page 5, line 22
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 the header field values from the various proxies is not
significant. significant.
2.6. HTTP Modifications 2.6. HTTP 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. The changes specified here scheme usage is similar to that for HTTP. For completeness, the
are mostly copied from section 22.4 of [RFC3261] with few changes. bullets specified below are mostly copied from section 22.4 of
[RFC3261]; the only semantic changes are specified in bullets 7 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" replaced by "SIP/2.0" in addition to the following with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following
differences: differences:
1. The URI included in the challenge has the following BNF: 1. The URI included in the challenge has the following BNF:
URI = Request-URI 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
4. The example procedure for choosing a nonce based on Etag does not 4. The example procedure for choosing a nonce based on Etag does not
work for SIP. work for SIP.
 End of changes. 12 change blocks. 
18 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/