RFC 7615 - HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7615
タイトル : RFC 7615 - HTTP Authentication-InfoおよびProxy-Authentication-Info応答ヘッダーフィールド
翻訳編集 : 自動生成

[要約] RFC 7615は、HTTP認証情報とプロキシ認証情報のレスポンスヘッダーフィールドに関する仕様です。このRFCの目的は、認証情報の追加のセキュリティと機能を提供することです。

Internet Engineering Task Force (IETF)                        J. Reschke
Request for Comments: 7615                                    greenbytes
Obsoletes: 2617                                           September 2015
Category: Standards Track
ISSN: 2070-1721

HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields

HTTP Authentication-InfoおよびProxy-Authentication-Info応答ヘッダーフィールド

Abstract

概要

This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in Hypertext Transfer Protocol (HTTP) authentication schemes that need to return information once the client's authentication credentials have been accepted.

この仕様は、クライアントの認証資格情報が受け入れられると情報を返す必要があるハイパーテキスト転送プロトコル（HTTP）認証方式で使用するための「Authentication-Info」および「Proxy-Authentication-Info」応答ヘッダーフィールドを定義します。

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

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

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

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

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://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標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   3
   3.  The Authentication-Info Response Header Field . . . . . . . .   3
     3.1.  Parameter Value Format  . . . . . . . . . . . . . . . . .   4
   4.  The Proxy-Authentication-Info Response Header Field . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction

1. はじめに

This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HTTP authentication schemes ([RFC7235]) that need to return information once the client's authentication credentials have been accepted.

この仕様は、クライアントの認証資格情報が受け入れられると情報を返す必要があるHTTP認証スキーム（[RFC7235]）で使用するための「Authentication-Info」および「Proxy-Authentication-Info」応答ヘッダーフィールドを定義します。

Both were previously defined in Section 3 of [RFC2617], defining the HTTP "Digest" authentication scheme. This document generalizes the description for use not only in "Digest" ([RFC7616]), but also in other future schemes that might have the same requirements for carrying additional information during authentication.

どちらも[RFC2617]のセクション3で以前に定義されており、HTTP「ダイジェスト」認証スキームを定義しています。このドキュメントでは、「ダイジェスト」（[RFC7616]）だけでなく、認証中に追加情報を運ぶための同じ要件を持つ他の将来のスキームでも使用するために説明を一般化しています。

2. Notational Conventions

2. 表記規則

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). The ABNF production for "auth-param" is defined in Section 2.1 of [RFC7235].

この仕様では、[RFC7230]のセクション7で定義されている、リスト拡張子付きの[RFC5234]の拡張バッカスナウア記法（ABNF）表記を使用します。これにより、「＃」演算子を使用してコンマ区切りリストをコンパクトに定義できます（「*」演算子が繰り返しを示す方法）。「auth-param」のABNFプロダクションは、[RFC7235]のセクション2.1で定義されています。

3. The Authentication-Info Response Header Field

3. Authentication-Info応答ヘッダーフィールド

HTTP authentication schemes can use the Authentication-Info response header field to communicate information after the client's authentication credentials have been accepted. This information can include a finalization message from the server (e.g., it can contain the server authentication).

HTTP認証スキームは、Authentication-Info応答ヘッダーフィールドを使用して、クライアントの認証資格情報が受け入れられた後に情報を通信できます。この情報には、サーバーからの終了メッセージを含めることができます（たとえば、サーバー認証を含めることができます）。

The field value is a list of parameters (name/value pairs), using the "auth-param" syntax defined in Section 2.1 of [RFC7235]. This specification only describes the generic format; authentication schemes using Authentication-Info will define the individual parameters. The "Digest" Authentication Scheme, for instance, defines multiple parameters in Section 3.5 of [RFC7616].

フィールド値は、[RFC7235]のセクション2.1で定義されている「auth-param」構文を使用したパラメーター（名前/値のペア）のリストです。この仕様では、一般的な形式のみを説明しています。 Authentication-Infoを使用する認証スキームは、個々のパラメーターを定義します。たとえば、「ダイジェスト」認証スキームは、[RFC7616]のセクション3.5で複数のパラメータを定義します。

     Authentication-Info = #auth-param

The Authentication-Info header field can be used in any HTTP response, independently of request method and status code. Its semantics are defined by the authentication scheme indicated by the Authorization header field ([RFC7235], Section 4.2) of the corresponding request.

Authentication-Infoヘッダーフィールドは、リクエストメソッドやステータスコードに関係なく、任意のHTTP応答で使用できます。そのセマンティクスは、対応するリクエストのAuthorizationヘッダーフィールド（[RFC7235]、セクション4.2）で示される認証スキームによって定義されます。

A proxy forwarding a response is not allowed to modify the field value in any way.

応答を転送するプロキシは、いかなる方法でもフィールド値を変更できません。

Authentication-Info can be used inside trailers ([RFC7230], Section 4.1.2) when the authentication scheme explicitly allows this.

Authentication-Infoは、認証スキームで明示的に許可されている場合、トレーラー（[RFC7230]、セクション4.1.2）内で使用できます。

3.1. Parameter Value Format

3.1. パラメータ値の形式

Parameter values can be expressed either as "token" or as "quoted-string" (Section 3.2.6 of [RFC7230]).

パラメータ値は、「トークン」または「引用文字列」のいずれかで表すことができます（[RFC7230]のセクション3.2.6）。

Authentication scheme definitions need to allow both notations, both for senders and recipients. This allows recipients to use generic parsing components, independent of the authentication scheme in use.

認証方式の定義では、送信者と受信者の両方に対して、両方の表記を許可する必要があります。これにより、受信者は、使用中の認証方式に関係なく、汎用の解析コンポーネントを使用できます。

For backwards compatibility, authentication scheme definitions can restrict the format for senders to one of the two variants. This can be important when it is known that deployed implementations will fail when encountering one of the two formats.

下位互換性のために、認証スキーム定義では、送信者の形式を2つのバリアントのいずれかに制限できます。これは、2つの形式のいずれかに遭遇したときにデプロイされた実装が失敗することがわかっている場合に重要になります。

4. The Proxy-Authentication-Info Response Header Field

4. Proxy-Authentication-Info応答ヘッダーフィールド

The Proxy-Authentication-Info response header field is equivalent to Authentication-Info, except that it applies to proxy authentication ([RFC7235], Section 2) and its semantics are defined by the authentication scheme indicated by the Proxy-Authorization header field ([RFC7235], Section 4.4) of the corresponding request:

Proxy-Authentication-Info応答ヘッダーフィールドは、Authentication-Infoと同等ですが、プロキシ認証に適用され（[RFC7235]、セクション2）、そのセマンティクスは、Proxy-Authorizationヘッダーフィールド（[ RFC7235]、セクション4.4）、対応するリクエスト：

     Proxy-Authentication-Info = #auth-param

However, unlike Authentication-Info, the Proxy-Authentication-Info header field applies only to the next outbound client on the response chain. This is because only the client that chose a given proxy is likely to have the credentials necessary for authentication. However, when multiple proxies are used within the same administrative domain, such as office and regional caching proxies within a large corporate network, it is common for credentials to be generated by the user agent and passed through the hierarchy until consumed. Hence, in such a configuration, it will appear as if Proxy-Authentication-Info is being forwarded because each proxy will send the same field value.

ただし、Authentication-Infoとは異なり、Proxy-Authentication-Infoヘッダーフィールドは、応答チェーンの次の送信クライアントにのみ適用されます。これは、特定のプロキシを選択したクライアントのみが、認証に必要な資格情報を持つ可能性があるためです。ただし、大規模な企業ネットワーク内のオフィスやリージョナルキャッシングプロキシなど、同じ管理ドメイン内で複数のプロキシが使用される場合、資格情報はユーザーエージェントによって生成され、消費されるまで階層を通過するのが一般的です。したがって、このような構成では、各プロキシが同じフィールド値を送信するため、Proxy-Authentication-Infoが転送されているように見えます。

5. Security Considerations

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

Adding information to HTTP responses that are sent over an unencrypted channel can affect security and privacy. The presence of the header fields alone indicates that HTTP authentication is in use. Additional information could be exposed by the contents of the authentication-scheme specific parameters; this will have to be considered in the definitions of these schemes.

暗号化されていないチャネルを介して送信されるHTTP応答に情報を追加すると、セキュリティとプライバシーに影響を与える可能性があります。ヘッダーフィールドのみの存在は、HTTP認証が使用されていることを示します。認証方式固有のパラメーターの内容によって、追加情報が公開される可能性があります。これは、これらのスキームの定義で考慮する必要があります。

6. IANA Considerations

6. IANAに関する考慮事項

HTTP header fields are registered within the "Message Headers" registry located at <http://www.iana.org/assignments/ message-headers>, as defined by [BCP90].

HTTPヘッダーフィールドは、[BCP90]で定義されているように、<http://www.iana.org/assignments/message-headers>にある「メッセージヘッダー」レジストリ内に登録されています。

This document updates the definitions of the "Authentication-Info" and "Proxy-Authentication-Info" header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly:

このドキュメントでは、「Authentication-Info」および「Proxy-Authentication-Info」ヘッダーフィールドの定義を更新しているため、「Permanent Message Header Field Names」レジストリはそれに応じて更新されています。

   +---------------------------+----------+----------+-----------------+
   | Header Field Name         | Protocol | Status   | Reference       |
   +---------------------------+----------+----------+-----------------+
   | Authentication-Info       | http     | standard | Section 3 of    |
   |                           |          |          | this document   |
   | Proxy-Authentication-Info | http     | standard | Section 4 of    |
   |                           |          |          | this document   |
   +---------------------------+----------+----------+-----------------+

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

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

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

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.

[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.

[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<http://www.rfc-editor.org/info/rfc7235>。

7.2. Informative References

7.2. 参考引用

[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004, <http://www.rfc-editor.org/info/bcp90>.

[BCP90] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月、<http://www.rfc-editor.org/info / bcp90>。

[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, <http://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月、<http://www.rfc-editor.org/info/rfc2617>。

[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://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月、<http：//www.rfc- editor.org/info/rfc7616>。

Acknowledgements

謝辞

This document is based on the header field definitions in RFCs 2069 and 2617, whose authors are: John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, Eric W. Sink, and Lawrence C. Stewart.

このドキュメントは、RFC 2069および2617のヘッダーフィールド定義に基づいています。その著者は、John Franks、Phillip M. Hallam-Baker、Jeffery L. Hostetler、Scott D. Lawrence、Paul J. Leach、Ari Luotonen、Eric W.です。シンク、およびローレンスC.スチュワート。

Additional thanks go to the members of the HTTPAUTH and HTTPBIS Working Groups, namely, Amos Jeffries, Benjamin Kaduk, Alexey Melnikov, Mark Nottingham, Yutaka Oiwa, Rifaat Shekh-Yusef, and Martin Thomson.

さらに、HTTPAUTHおよびHTTPBISワーキンググループのメンバー、すなわちAmos Jeffries、Benjamin Kaduk、Alexey Melnikov、Mark Nottingham、Yutaka Oiwa、Rifaat Shekh-Yusef、Martin Thomsonに感謝します。

Author's Address

著者のアドレス

Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany

Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster、NW 48155ドイツ

   Email: julian.reschke@greenbytes.de
   URI:   http://greenbytes.de/tech/webdav/