RFC 8760 - The Session Initiation Protocol (SIP) Digest Authentication Scheme 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8760.html
タイトル : RFC 8760 - セッション開始プロトコル（SIP）ダイジェスト認証スキーム
翻訳編集 : 自動生成

[要約] RFC 8760は、SIPのダイジェスト認証スキームに関する仕様であり、SIPセッションのセキュリティを向上させるために設計されています。このRFCの目的は、SIPサーバーとクライアント間の認証プロセスを強化し、不正なアクセスやデータの改ざんを防ぐことです。

Internet Engineering Task Force (IETF)                    R. Shekh-Yusef
Request for Comments: 8760                                         Avaya
Updates: 3261                                                 March 2020
Category: Standards Track
ISSN: 2070-1721

The Session Initiation Protocol (SIP) Digest Access Authentication Scheme

セッション開始プロトコル（SIP）ダイジェストアクセス認証方式

Abstract

概要

This document updates RFC 3261 by modifying the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g., SHA-256 and SHA-512/256, to replace the obsolete MD5 algorithm.

このドキュメントでは、Session Initiation Protocol（SIP）で使用されるダイジェストアクセス認証スキームを変更してRFC 3261を更新し、より安全なダイジェストアルゴリズム（SHA-256やSHA-512 / 256など）のサポートを追加して、廃止されたMD5アルゴリズムを置き換えます。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8760.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8760で入手できます。

著作権表示

著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。

Table of Contents

   1.  Introduction
     1.1.  Terminology
   2.  Updates to the SIP Digest Access Authentication Scheme
     2.1.  Hash Algorithms
     2.2.  Representation of Digest Values
     2.3.  UAS Behavior
     2.4.  UAC Behavior
     2.5.  Forking
     2.6.  HTTP Digest Authentication Scheme Modifications
     2.7.  ABNF for SIP
   3.  Security Considerations
   4.  IANA Considerations
   5.  References
     5.1.  Normative References
     5.2.  Informative References
   Acknowledgments
   Author's Address

1. Introduction

1. はじめに

The Session Initiation Protocol [RFC3261] uses the same mechanism as the Hypertext Transfer Protocol (HTTP) does for authenticating users. This mechanism is called "Digest Access Authentication". It is a simple challenge-response mechanism that allows a server to challenge a client request and allows a client to provide authentication information in response to that challenge. The version of Digest Access Authentication that [RFC3261] references is specified in [RFC2617].

セッション開始プロトコル[RFC3261]は、ユーザーの認証にハイパーテキスト転送プロトコル（HTTP）と同じメカニズムを使用します。このメカニズムは「ダイジェストアクセス認証」と呼ばれます。これは、サーバーがクライアント要求にチャレンジし、クライアントがそのチャレンジに応答して認証情報を提供できるようにする単純なチャレンジ/レスポンスメカニズムです。 [RFC3261]が参照するダイジェストアクセス認証のバージョンは、[RFC2617]で指定されています。

The default hash algorithm for Digest Access Authentication is MD5. However, it has been demonstrated that the MD5 algorithm is not collision resistant and is now considered a bad choice for a hash function (see [RFC6151]).

ダイジェストアクセス認証のデフォルトのハッシュアルゴリズムはMD5です。ただし、MD5アルゴリズムは衝突耐性がなく、ハッシュ関数の不適切な選択肢と見なされていることが実証されています（[RFC6151]を参照）。

The HTTP Digest Access Authentication document [RFC7616] obsoletes [RFC2617] and adds stronger algorithms that can be used with the Digest Access Authentication scheme and establishes a registry for these algorithms, known as the "Hash Algorithms for HTTP Digest Authentication" IANA registry, so that algorithms can be added in the future.

HTTPダイジェストアクセス認証ドキュメント[RFC7616]は廃止され[RFC2617]、ダイジェストアクセス認証スキームで使用できるより強力なアルゴリズムを追加し、「HTTPダイジェスト認証のハッシュアルゴリズム」IANAレジストリと呼ばれるこれらのアルゴリズムのレジストリを確立します。そのアルゴリズムは将来追加される可能性があります。

This document updates the Digest Access Authentication scheme used by SIP to support the algorithms listed in the "Hash Algorithms for HTTP Digest Authentication" IANA registry defined by [RFC7616].

このドキュメントは、[RFC7616]で定義されている「HTTPダイジェスト認証のハッシュアルゴリズム」IANAレジストリにリストされているアルゴリズムをサポートするために、SIPで使用されるダイジェストアクセス認証方式を更新します。

1.1. Terminology

1.1. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

2. Updates to the SIP Digest Access Authentication Scheme

2. SIPダイジェストアクセス認証スキームの更新

This section describes the modifications to the operation of the Digest mechanism as specified in [RFC3261] in order to support the algorithms defined in the "Hash Algorithms for HTTP Digest Authentication" IANA registry described in [RFC7616].

このセクションでは、[RFC7616]で説明されている「HTTPダイジェスト認証のハッシュアルゴリズム」IANAレジストリで定義されているアルゴリズムをサポートするために、[RFC3261]で指定されているダイジェストメカニズムの操作の変更について説明します。

It replaces the reference used in [RFC3261] for Digest Access Authentication, substituting [RFC7616] for the obsolete [RFC2617], 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 [SHA2]. It adds required support for the "qop" parameter. It provides additional User Agent Client (UAC) and User Agent Server (UAS) procedures regarding usage of multiple SIP Authorization, WWW-Authenticate, and Proxy-Authenticate header fields, including the order in which to insert and process them. It provides guidance regarding forking. Finally, it updates the SIP ABNF as required by the updates.

[RFC3261]でダイジェストアクセス認証に使用されていた参照を置き換え、[RFC7616]を廃止された[RFC2617]に置き換え、その参照の更新による[RFC3261]のダイジェストメカニズムの使用法の変更について説明します。 SHA-256およびSHA-512 / 256アルゴリズム[SHA2]のサポートを追加します。「qop」パラメーターに必要なサポートを追加します。複数のSIP Authorization、WWW-Authenticate、およびProxy-Authenticateヘッダーフィールドの使用に関する追加のユーザーエージェントクライアント（UAC）およびユーザーエージェントサーバー（UAS）の手順を、それらを挿入して処理する順序を含めて提供します。フォークに関するガイダンスを提供します。最後に、更新の必要に応じてSIP ABNFを更新します。

2.1. Hash Algorithms

2.1. ハッシュアルゴリズム

The Digest Access Authentication scheme has an "algorithm" parameter that specifies the algorithm to be used to compute the digest of the response. The "Hash Algorithms for HTTP Digest Authentication" IANA registry specifies the algorithms that correspond to 'algorithm' values.

ダイジェストアクセス認証方式には、応答のダイジェストを計算するために使用されるアルゴリズムを指定する「アルゴリズム」パラメータがあります。「HTTPダイジェスト認証のハッシュアルゴリズム」IANAレジストリは、「アルゴリズム」値に対応するアルゴリズムを指定します。

[RFC3261] specifies only one algorithm, MD5, which is used by default. This document extends [RFC3261] to allow use of any algorithm listed in the "Hash Algorithms for HTTP Digest Authentication" IANA registry.

[RFC3261]は、デフォルトで使用される1つのアルゴリズムMD5のみを指定します。このドキュメントは、[RFC3261]を拡張して、「HTTPダイジェスト認証のハッシュアルゴリズム」IANAレジストリにリストされているアルゴリズムを使用できるようにします。

A UAS prioritizes which algorithm to use based on its policy, which is specified in Section 2.3 and parallels the process used in HTTP specified by [RFC7616].

UASはセクション2.3で指定されているポリシーに基づいて、使用するアルゴリズムに優先順位を付け、[RFC7616]で指定されているHTTPで使用されるプロセスに対応します。

2.2. Representation of Digest Values

2.2. ダイジェスト値の表現

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 set of four bits is represented by its familiar hexadecimal notation from the characters 0123456789abcdef; that is, binary 0000 is represented by the character '0', 0001 is represented by '1', and so on up to the representation of 1111 as 'f'. If the SHA-256 or SHA-512/256 algorithm is used to calculate the digest, then the digest will be represented as 64 hexadecimal characters.

ダイジェストのサイズは、使用するアルゴリズムによって異なります。ダイジェストのビットは、次のように、一度に4ビットずつ、最上位ビットから最下位ビットに変換され、ASCII表現に変換されます。 4ビットの各セットは、文字0123456789abcdefからのよく知られた16進表記で表されます。つまり、バイナリ0000は文字「0」で表され、0001は「1」で表され、1111が「f」として表されるまで続きます。 SHA-256またはSHA-512 / 256アルゴリズムを使用してダイジェストを計算する場合、ダイジェストは64桁の16進文字として表されます。

2.3. UAS Behavior

2.3. UASの動作

When a UAS receives a request from a UAC, and an acceptable Authorization header field is not received, 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, respectively. The UAS MAY add multiple WWW-Authenticate/Proxy-Authenticate header fields to allow the UAS to utilize the best available algorithm supported by the client.

UASがUACから要求を受信し、受け入れ可能なAuthorizationヘッダーフィールドが受信されない場合、UASは、WWW-Authenticate / Proxy-Authenticateヘッダーを持つ401/407ステータスコードで要求を拒否することにより、発信者にクレデンシャルの提供を要求できます。それぞれフィールド。 UASは複数のWWW-Authenticate / Proxy-Authenticateヘッダーフィールドを追加して、UASがクライアントでサポートされている利用可能な最良のアルゴリズムを利用できるようにする場合があります。

If the UAS challenges the originator using multiple WWW-Authenticate/ Proxy-Authenticate header fields with the same realm, then each of these header fields MUST use a different digest algorithm. The UAS MUST add these header fields to the response in the order in which it would prefer to see them used, starting with the most preferred algorithm at the top. The UAS cannot assume that the client will use the algorithm specified in the topmost header field.

UASが同じレルムを持つ複数のWWW-Authenticate / Proxy-Authenticateヘッダーフィールドを使用して発信者にチャレンジする場合、これらの各ヘッダーフィールドは異なるダイジェストアルゴリズムを使用する必要があります。 UASは、これらのヘッダーフィールドを、最も使用されているアルゴリズムを先頭にして、使用する順序で応答に追加する必要があります（MUST）。 UASは、クライアントが最上位のヘッダーフィールドで指定されたアルゴリズムを使用するとは想定できません。

2.4. UAC Behavior

2.4. UACの動作

When the UAC receives a response with multiple WWW-Authenticate/ Proxy-Authenticate header fields with the same realm, it SHOULD use the topmost header field that it supports unless a local policy dictates otherwise. The client MUST ignore any challenge it does not understand.

UACが、同じレルムを持つ複数のWWW-Authenticate / Proxy-Authenticateヘッダーフィールドを含む応答を受信した場合、ローカルポリシーで別の指示がない限り、サポートする最上位のヘッダーフィールドを使用する必要があります。クライアントは、理解できないチャレンジを無視する必要があります。

When the UAC receives a 401 response with multiple WWW-Authenticate header fields with different realms, it SHOULD retry and add an Authorization header field containing credentials that match the topmost header field of any of the realms unless a local policy dictates otherwise.

UACは、レルムが異なる複数のWWW-Authenticateヘッダーフィールドを含む401応答を受信すると、ローカルポリシーで特に指示されていない限り、任意のレルムの最上位のヘッダーフィールドと一致する資格情報を含むAuthorizationヘッダーフィールドを再試行して追加する必要があります。

If the UAC cannot respond to any of the challenges in the response, then it SHOULD abandon attempts to send the request unless a local policy dictates otherwise, e.g., the policy might indicate the use of non-Digest mechanisms. For example, if the UAC does not have credentials or has stale credentials for any of the realms, the UAC will abandon the request.

UACが応答のチャレンジのいずれにも応答できない場合は、ローカルポリシーで他の指示がない限り（たとえば、ポリシーで非ダイジェストメカニズムの使用が示されている可能性がある場合）、リクエストの送信を中止する必要があります（SHOULD）。たとえば、UACに資格情報がないか、いずれかのレルムの失効した資格情報がある場合、UACは要求を破棄します。

2.5. Forking

2.5. フォーク

Section 22.3 of [RFC3261] discusses the operation of the proxy-to-user authentication, which describes the operation of the proxy when it forks a request. This section clarifies that operation.

[RFC3261]のセクション22.3は、プロキシからユーザーへの認証の動作について説明しています。これは、プロキシがリクエストをフォークしたときの動作を説明しています。このセクションでは、その操作について説明します。

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 response to the forked request MUST be placed into the single response that is sent by the forking proxy to the UAC.

リクエストがフォークされた場合、さまざまなプロキシサーバーやUAがUACにチャレンジすることを望みます。この場合、フォーキングプロキシサーバーは、これらの課題を単一の応答に集約する役割を果たします。 forkされたリクエストへの応答として受信された各WWW-AuthenticateおよびProxy-Authenticateの値は、forkプロキシによってUACに送信される単一の応答に配置する必要があります。

When the forking proxy places multiple WWW-Authenticate and Proxy-Authenticate header fields received from one downstream proxy into a single response, it MUST maintain the order of these header fields. The ordering of values received from different downstream proxies is not significant.

フォークプロキシが、1つのダウンストリームプロキシから受信した複数のWWW-AuthenticateおよびProxy-Authenticateヘッダーフィールドを単一の応答に配置する場合、これらのヘッダーフィールドの順序を維持する必要があります。異なるダウンストリームプロキシから受信した値の順序は重要ではありません。

2.6. HTTP Digest Authentication Scheme Modifications

2.6. HTTPダイジェスト認証スキームの変更

This section describes the modifications and clarifications required to apply the HTTP Digest Access Authentication scheme to SIP. The SIP scheme usage is similar to that for HTTP. For completeness, the bullets specified below are mostly copied from Section 22.4 of [RFC3261]; the only semantic changes are specified in bullets 1, 7, and 8 below.

このセクションでは、HTTPダイジェストアクセス認証スキームをSIPに適用するために必要な変更と説明について説明します。 SIPスキームの使用法は、HTTPの場合と同様です。完全を期すために、以下に指定されている箇条書きは、[RFC3261]のセクション22.4からほとんどコピーされています。唯一の意味上の変更は、以下の箇条書き1、7、および8で指定されています。

SIP clients and servers MUST NOT accept or request Basic authentication.

SIPクライアントおよびサーバーは、基本認証を受け入れたり要求したりしてはなりません。

The rules for Digest Access Authentication follow those defined in HTTP, with "HTTP/1.1" [RFC7616] replaced by "SIP/2.0" in addition to the following differences:

ダイジェストアクセス認証のルールは、HTTPで定義されたルールに従い、以下の違いに加えて、「HTTP / 1.1」[RFC7616]が「SIP / 2.0」に置き換えられています。

1. The URI included in the challenge has the following ABNF [RFC5234]:

1. チャレンジに含まれるURIには、次のABNF [RFC5234]があります。

URI = Request-URI ; as defined in RFC 3261, Section 25

URI = Request-URI; RFC 3261、セクション25で定義されているとおり

2. The "uri" parameter of the Authorization header field MUST be enclosed in quotation marks.

2. Authorizationヘッダーフィールドの「uri」パラメータは、引用符で囲む必要があります。

3. The ABNF for digest-uri-value is:

3. digest-uri-valueのABNFは次のとおりです。

               digest-uri-value  =  Request-URI

4. The example procedure for choosing a nonce based on ETag does not work for SIP.

4. ETagに基づいてnonceを選択する手順の例は、SIPでは機能しません。

5. The text in [RFC7234] regarding cache operation does not apply to SIP.

5. [RFC7234]のキャッシュ操作に関するテキストはSIPには適用されません。

6. [RFC7616] 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 UAS MUST check if the Request-URI in the Authorization/Proxy-Authorization header field value corresponds to a user for whom the UAS is willing to accept forwarded or direct requests; however, it MAY still accept it if the two fields are not equivalent.

6. [RFC7616]では、サーバーがリクエスト行のURIとAuthorizationヘッダーフィールドに含まれるURIが同じリソースを指していることを確認する必要があります。 SIPコンテキストでは、これらの2つのURIは、いくつかのプロキシでの転送により、異なるユーザーを参照する場合があります。したがって、SIPでは、UASは、Authorization / Proxy-Authorizationヘッダーフィールド値のRequest-URIが、UASが転送または直接の要求を受け入れる用意があるユーザーに対応するかどうかを確認する必要があります。ただし、2つのフィールドが同等でない場合でも、それを受け入れる場合があります。

7. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest Access Authentication scheme, implementers should assume that the hash of the entity-body resolves to the hash of an empty string when the entity-body is empty (that is, when SIP messages have no body):

7. ダイジェストアクセス認証方式でのメッセージ整合性保証のA2値の計算の明確化として、実装者は、エンティティボディが空の場合、エンティティボディのハッシュが空の文字列のハッシュに解決されると想定する必要があります（つまり、、SIPメッセージに本文がない場合）：

       H(entity-body) = <algorithm>("")

For example, when the chosen algorithm is SHA-256, then:

たとえば、選択したアルゴリズムがSHA-256の場合、次のようになります。

       H(entity-body) = SHA-256("") =
      "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"

8. A UAS MUST be able to properly handle a "qop" parameter received in an Authorization/Proxy-Authorization header field, and a UAC MUST be able to properly handle a "qop" parameter received in WWW-Authenticate and Proxy-Authenticate header fields. However, for backward compatibility reasons, the "qop" parameter is optional for clients and servers based on [RFC3261] to receive. If the "qop" parameter is not specified, then the default value is "auth".

8. UASは、Authorization / Proxy-Authorizationヘッダーフィールドで受信した「qop」パラメーターを適切に処理できなければならず、UACは、WWW-AuthenticateおよびProxy-Authenticateヘッダーフィールドで受信した「qop」パラメーターを適切に処理できなければなりません。ただし、下位互換性の理由から、[qop]パラメータは、[RFC3261]に基づくクライアントとサーバーが受信するオプションです。「qop」パラメーターが指定されていない場合、デフォルト値は「auth」です。

A UAS MUST always send a "qop" parameter in WWW-Authenticate and Proxy-Authenticate header field values, and a UAC MUST send the "qop" parameter in any resulting authorization header field.

UASは、WWW-AuthenticateおよびProxy-Authenticateヘッダーフィールドの値で常に「qop」パラメーターを送信する必要があり、UACは、結果の承認ヘッダーフィールドで「qop」パラメーターを送信する必要があります。

The usage of the Authentication-Info header field continues to be allowed, since it provides integrity checks over the bodies and provides mutual authentication.

本文の整合性チェックを提供し、相互認証を提供するため、Authentication-Infoヘッダーフィールドの使用は引き続き許可されます。

2.7. ABNF for SIP

2.7. SIPのABNF

This document updates the ABNF [RFC5234] for SIP as follows.

このドキュメントでは、SIPのABNF [RFC5234]を次のように更新します。

It extends the request-digest as follows to allow for different digest sizes:

リクエストダイジェストを次のように拡張して、さまざまなダイジェストサイズに対応します。

request-digest = LDQUOT *LHEX RDQUOT

request-digest = LDQUOT * LHEX RDQUOT

The number of hex digits is implied by the length of the value of the algorithm used, with a minimum size of 32. A parameter with an empty value (empty string) is allowed when the UAC has not yet received a challenge.

16進数の数は、使用されるアルゴリズムの値の長さによって暗示され、最小サイズは32です。UACがまだチャレンジを受信していない場合、空の値（空の文字列）を持つパラメーターが許可されます。

It extends the algorithm parameter as follows to allow any algorithm in the registry to be used:

次のようにアルゴリズムパラメータを拡張して、レジストリ内の任意のアルゴリズムを使用できるようにします。

   algorithm =  "algorithm" EQUAL ( "MD5" / "MD5-sess" / "SHA-256" /
   "SHA-256-sess" /
   "SHA-512-256" /  "SHA-512-256-sess" / token )

3. Security Considerations

3. セキュリティに関する考慮事項

This specification adds new secure algorithms to be used with the Digest mechanism to authenticate users. The obsolete MD5 algorithm remains only for backward compatibility with [RFC2617], but its use is NOT RECOMMENDED.

この仕様では、ダイジェストメカニズムでユーザーを認証するために使用される新しい安全なアルゴリズムが追加されています。廃止されたMD5アルゴリズムは、[RFC2617]との下位互換性のためにのみ残されていますが、その使用は推奨されません。

This opens the system to the potential for a downgrade attack by an on-path attacker. The most effective way of dealing with this type of attack is to either validate the client and challenge it accordingly or remove the support for backward compatibility by not supporting MD5.

これにより、システムはパス上の攻撃者によるダウングレード攻撃の可能性にさらされます。このタイプの攻撃に対処する最も効果的な方法は、クライアントを検証してそれに応じてチャレンジするか、MD5をサポートしないことにより下位互換性のサポートを削除することです。

See Section 5 of [RFC7616] for a detailed security discussion of the Digest Access Authentication scheme.

ダイジェストアクセス認証スキームのセキュリティの詳細については、[RFC7616]のセクション5をご覧ください。

4. IANA Considerations

4. IANAに関する考慮事項

[RFC7616] defines an IANA registry named "Hash Algorithms for HTTP Digest Authentication" to simplify the introduction of new algorithms in the future. This document specifies that algorithms defined in that registry may be used in SIP digest authentication.

[RFC7616]は、「HTTPダイジェスト認証のハッシュアルゴリズム」というIANAレジストリを定義して、将来の新しいアルゴリズムの導入を簡素化します。このドキュメントでは、そのレジストリで定義されたアルゴリズムをSIPダイジェスト認証で使用できることを規定しています。

This document has no actions for IANA.

このドキュメントには、IANAに対するアクションはありません。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.

[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.

[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<https://www.rfc-editor.org/info/rfc7234>。

[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>.

[RFC7616] Shekh-Yusef、R.、Ed。、Ahrens、D。、およびS. Bremer、「HTTP Digest Access Authentication」、RFC 7616、DOI 10.17487 / RFC7616、2015年9月、<https：//www.rfc- editor.org/info/rfc7616>。

[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>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[SHA2] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4, FIPS 180-4, August 2015, <https://doi.org/10.6028/NIST.FIPS.180-4>.

[SHA2]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、DOI 10.6028 / NIST.FIPS.180-4、FIPS 180-4、2015年8月、<https://doi.org/10.6028/NIST .FIPS.180-4>。

5.2. Informative References

5.2. 参考引用

[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, DOI 10.17487/RFC2617, June 1999, <https://www.rfc-editor.org/info/rfc2617>.

[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP Authentication：Basic and Digest Access Authentication」、RFC 2617、DOI 10.17487 / RFC2617、1999年6月、<https://www.rfc-editor.org/info/rfc2617>。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。

[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.

[RFC6151]ターナーS.およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、DOI 10.17487 / RFC6151、2011年3月、<https：//www.rfc- editor.org/info/rfc6151>。

Acknowledgments

謝辞

The author would like to thank the following individuals for their careful review, comments, and suggestions: Paul Kyzivat, Olle Johansson, Dale Worley, Michael Procter, Inaki Baz Castillo, Tolga Asveren, Christer Holmberg, Brian Rosen, Jean Mahoney, Adam Roach, Barry Leiba, Roni Even, Eric Vyncke, Benjamin Kaduk, Alissa Cooper, Roman Danyliw, Alexey Melnikov, and Maxim Sobolev.

著者は、慎重なレビュー、コメント、および提案を行った次の個人に感謝します。バリー・レイバ、ロニ・イーブン、エリック・ヴィンケ、ベンジャミン・カドゥック、アリッサ・クーパー、ローマン・ダニリュー、アレクセイ・メルニコフ、マキシム・ソボレフ。

Author's Address

著者のアドレス

Rifaat Shekh-Yusef Avaya 425 Legget Dr. Ottawa Ontario Canada

リファトシェイクユセフオタワオンタリオカナダ

   Phone: +1-613-595-9106
   Email: rifaat.ietf@gmail.com