draft-ietf-sipcore-digest-scheme-03.txt   draft-ietf-sipcore-digest-scheme-04.txt 
SIP Core R. Shekh-Yusef SIP Core R. Shekh-Yusef
Internet-Draft Avaya Internet-Draft Avaya
Updates: 3261 (if approved) May 26, 2019 Updates: 3261 (if approved) May 28, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: November 27, 2019 Expires: November 29, 2019
The Session Initiation Protocol (SIP) Digest Authentication Scheme The Session Initiation Protocol (SIP) Digest Authentication Scheme
draft-ietf-sipcore-digest-scheme-03 draft-ietf-sipcore-digest-scheme-04
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 more secure the Session Initiation Protocol (SIP) to add support for more secure
digest algorithms, e.g. SHA-256 and SHA-512-256, to replace the digest algorithms, e.g. SHA-256 and SHA-512-256, to replace the
broken MD5 algorithm. broken MD5 algorithm.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 27, 2019. This Internet-Draft will expire on November 29, 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 4, line 23 skipping to change at page 4, line 23
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. UAS Behavior 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 received, 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 respectively. The UAS MAY include multiple WWW- header field respectively. The UAS MAY add multiple WWW-
Authenticate/Proxy-Authenticate header fields to allow the UAS to Authenticate/Proxy-Authenticate header fields to allow the UAS to
utilize the best available 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 header fields with the same realm, then each one of Authenticate header fields with the same realm, then each one of
these header fields MUST use a different digest algorithm. The UAS these header fields MUST use a different digest algorithm. The UAS
MUST add these header fields to the response in the order that it MUST add these header fields to the response in the order that it
would prefer to see them used, starting with the most preferred would prefer to see them used, starting with the most preferred
algorithm at the top, followed by the less preferred algorithms. The algorithm at the top, followed by the less preferred algorithms. The
UAS cannot assume that the client will use the algorithm specified at UAS cannot assume that the client will use the algorithm specified at
the topmost header field. the topmost header field.
2.4. UAC Behavior 2.4. UAC Behavior
When the UAC receives a response with multiple header fields with the When the UAC receives a response with multiple WWW-Authenticate/
same realm it SHOULD use the topmost header field that it supports, Proxy- Authenticate header fields with the same realm it SHOULD use
unless a local policy dictates otherwise. The client MUST ignore any the topmost header field that it supports, unless a local policy
challenge it does not understand. dictates otherwise. The client MUST ignore any 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 add 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.
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 or has stale credentials for any of the
realms, unless a local policy dictates otherwise.
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
that operation. that operation.
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
skipping to change at page 6, line 43 skipping to change at page 6, line 45
H(entity-body) = <algorithm>("") H(entity-body) = <algorithm>("")
For example, when the chosen algorithm is SHA-256, then: For example, when the chosen algorithm is SHA-256, then:
H(entity-body) = SHA-256("") = H(entity-body) = SHA-256("") =
"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
8. Servers MUST be able to properly handle "qop" parameter received 8. Servers MUST be able to properly handle "qop" parameter received
in an authorization header field, and clients MUST be able to in an authorization header field, and clients MUST be able to
properly handle "qop" parameter received in WWW-Authenticate and properly handle "qop" parameter received in WWW-Authenticate and
Proxy-Authenticate header fields. Servers MUST always send a "qop" Proxy-Authenticate header fields. However, for backward
parameter in WWW-Authenticate and Proxy-Authenticate header field compatibility reasons, the "qop" parameter is optional for
values, and clients MUST send the "qop" parameter in any resulting RFC3261-based clients and servers to receive.
authorization header field.
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 The usage of the Authentication-Info header field continue to be
allowed, since it provides integrity checks over the bodies and allowed, since it provides integrity checks over the bodies and
provides mutual authentication. provides mutual authentication.
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.
 End of changes. 10 change blocks. 
17 lines changed or deleted 22 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/