Network Working Group B. Sterman
Request for Comments: 5090 Kayote Networks
Obsoletes: 4590 D. Sadolevsky
Category: Standards Track SecureOL, Inc.
D. Schwartz
Kayote Networks
D. Williams
Cisco Systems
W. Beck
Deutsche Telekom AG
February 2008
RADIUS Extension for Digest Authentication
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP.
この文書では、セッション開始プロトコル（SIP）およびHTTPのようなHTTP形式のプロトコルで使用するためのダイジェスト認証のサポートを、有効にするには、リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコルへの拡張を定義します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. Terminology ................................................3
1.3. Overview ...................................................4
2. Detailed Description ............................................6
2.1. RADIUS Client Behavior .....................................6
2.2. RADIUS Server Behavior .....................................9
3. New RADIUS Attributes ..........................................12
3.1. Digest-Response Attribute .................................12
3.2. Digest-Realm Attribute ....................................13
3.3. Digest-Nonce Attribute ....................................13
3.4. Digest-Response-Auth Attribute ............................14
3.5. Digest-Nextnonce Attribute ................................14
3.6. Digest-Method Attribute ...................................15
3.7. Digest-URI Attribute ......................................15
3.8. Digest-Qop Attribute ......................................15
3.9. Digest-Algorithm Attribute ................................16
3.10. Digest-Entity-Body-Hash Attribute ........................16
3.11. Digest-CNonce Attribute ..................................17
3.12. Digest-Nonce-Count Attribute .............................17
3.13. Digest-Username Attribute ................................17
3.14. Digest-Opaque Attribute ..................................18
3.15. Digest-Auth-Param Attribute ..............................18
3.16. Digest-AKA-Auts Attribute ................................19
3.17. Digest-Domain Attribute ..................................19
3.18. Digest-Stale Attribute ...................................20
3.19. Digest-HA1 Attribute .....................................20
3.20. SIP-AOR Attribute ........................................21
4. Diameter Compatibility .........................................21
5. Table of Attributes ............................................21
6. Examples .......................................................23
7. IANA Considerations ............................................27
8. Security Considerations ........................................28
8.1. Denial of Service .........................................28
8.2. Confidentiality and Data Integrity ........................28
9. References .....................................................29
9.1. Normative References ......................................29
9.2. Informative References ....................................30
Appendix A - Changes from RFC 4590 ................................31
Acknowledgements ..................................................31
The HTTP Digest Authentication mechanism, defined in [RFC2617], was subsequently adapted for use with SIP [RFC3261]. Due to the limitations and weaknesses of Digest Authentication (see [RFC2617], Section 4), additional authentication and encryption mechanisms are defined in SIP [RFC3261], including Transport Layer Security (TLS) [RFC4346] and Secure MIME (S/MIME) [RFC3851]. However, Digest Authentication support is mandatory in SIP implementations, and Digest Authentication is the preferred way for a SIP UA to authenticate itself to a proxy server. Digest Authentication is used in other protocols as well.
[RFC2617]で定義されたHTTPダイジェスト認証機構が、その後SIP [RFC3261]での使用に適合しました。ダイジェスト認証（[RFC2617]、セクション4を参照）の限界と弱点に、追加の認証と暗号化のメカニズムは、SIPで定義されている[RFC3261]、トランスポート層セキュリティ（TLS）[RFC4346]およびSecure MIME（S / MIME）を含みます[RFC3851]。しかし、ダイジェスト認証サポートは、SIP実装に必須であり、ダイジェスト認証は、SIP UAプロキシサーバに対して自身を認証するための好ましい方法です。ダイジェスト認証は、他のプロトコルで使用されています。
To simplify the provisioning of users, there is a need to support this authentication mechanism within Authentication, Authorization, and Accounting (AAA) protocols such as RADIUS [RFC2865] and Diameter [RFC3588].
ユーザーのプロビジョニングを簡素化するために、そこに認証、認可内この認証メカニズムをサポートする必要があり、そのようなRADIUS [RFC2865]とDiameter [RFC3588]としてアカウンティング（AAA）プロトコル。
This document defines an extension to the RADIUS protocol to enable support of Digest Authentication for use with SIP, HTTP, and other HTTP-style protocols using this authentication method. Support for Digest mechanisms such as Authentication and Key Agreement (AKA) [RFC3310] is also supported. A companion document [RFC4740] defines support for Digest Authentication within Diameter.
この文書は、SIP、HTTP、この認証方法を使用して他のHTTP形式のプロトコルで使用するためのダイジェスト認証のサポートを可能にするために、RADIUSプロトコルの拡張を定義します。このような認証および鍵合意（AKA）[RFC3310]としてダイジェストメカニズムのサポートもサポートされています。仲間ドキュメント[RFC4740]は径内ダイジェスト認証のためのサポートを定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The use of normative requirement key words in this document shall apply only to RADIUS client and RADIUS server implementations that include the features described in this document. This document creates no normative requirements for existing implementations.
この文書の規範的要件のキーワードの使用は、この文書で説明する機能を備えたRADIUSクライアントとRADIUSサーバの実装に適用しなければなりません。この文書では、既存の実装のための規範的要件を作成しません。
HTTP-style protocol The term "HTTP-style" denotes any protocol that uses HTTP-like headers and uses HTTP Digest Authentication as described in [RFC2617]. Examples are HTTP and the Session Initiation Protocol (SIP).
HTTP形式のプロトコル用語「HTTPスタイルは、」HTTPのようなヘッダを使用して、[RFC2617]に記載されているように、HTTPダイジェスト認証を使用する任意のプロトコルです。例としては、HTTPとセッション開始プロトコル（SIP）です。
NAS (Network Access Server) The RADIUS client.
NAS（ネットワークアクセスサーバ）RADIUSクライアント。
nonce An unpredictable value used to prevent replay attacks. The nonce generator may use cryptographic mechanisms to produce nonces it can recognize without maintaining state.
ナンスリプレイ攻撃を防ぐために使用される予測不可能な値。ノンス生成部は、状態を維持することなく認識することができるノンスを生成する暗号化メカニズムを使用することができます。
protection space HTTP-style protocols differ in their definition of the protection space. For HTTP, it is defined as the combination of the realm and canonical root URL of the requested resource for which the use is authorized by the RADIUS server. In the case of SIP, the realm string alone defines the protection space.
保護空間HTTP形式のプロトコルは、保護空間のその定義が異なります。 HTTPのためには、使用がRADIUSサーバによって許可されているため、要求されたリソースの領域と正規のルートURLの組み合わせとして定義されます。 SIPの場合、realm文字列だけでは保護空間を定義します。
SIP UA (SIP User Agent) An Internet endpoint that uses the Session Initiation Protocol.
SIP UA（SIPユーザーエージェント）セッション開始プロトコルを使用してインターネットエンドポイント。
SIP UAS (SIP User Agent Server) A logical entity that generates a response to a SIP (Session Initiation Protocol) request.
SIP UAS（SIPユーザエージェントサーバ）SIP（セッション開始プロトコル）要求に対する応答を生成する論理エンティティ。
HTTP Digest is a challenge-response protocol used to authenticate a client's request to access some resource on a server. Figure 1 shows a single HTTP Digest transaction.
HTTPダイジェストは、サーバー上のいくつかのリソースにアクセスするためのクライアントの要求を認証するために使用されるチャレンジ - レスポンスプロトコルです。図1は、単一のHTTPダイジェストトランザクションを示しています。
HTTP/SIP..
+------------+ (1) +------------+
| |--------->| |
| HTTP-style | (2) | HTTP-style |
| client |<---------| server |
| | (3) | |
| |--------->| |
| | (4) | |
| |<---------| |
+------------+ +------------+
Figure 1: Digest Operation without RADIUS
図1：RADIUSなしのダイジェスト操作
If the client sends a request without any credentials (1), the server will reply with an error response (2) containing a nonce. The client creates a cryptographic digest from parts of the request, from the nonce it received from the server, and from a shared secret. The client retransmits the request (3) to the server, but now includes the digest within the packet. The server does the same digest calculation as the client and compares the result with the digest it received in (3). If the digest values are identical, the server grants access to the resource and sends a positive response to the client (4). If the digest values differ, the server sends a negative response to the client (4).
クライアントが任意の資格情報（1）せずに要求を送信した場合、サーバはnonceを含むエラー応答（2）で応答します。クライアントは、サーバから受信したナンスから、および共有秘密から、要求の部分から暗号ダイジェストを作成します。クライアントがサーバに要求（3）を再送信するが、今は、パケット内のダイジェストを含んでいます。サーバは、クライアントと同じダイジェストの計算を行い、それが（3）で受信されたダイジェストとの結果を比較します。ダイジェスト値が同一である場合は、サーバーの助成金は、リソースにアクセスし、クライアント（4）への肯定応答を送信します。ダイジェスト値が異なる場合、サーバはクライアント（4）への否定応答を送信します。
Instead of maintaining a local user database, the server could use RADIUS to access a centralized user database. However, RADIUS [RFC2865] does not include support for HTTP Digest Authentication. The RADIUS client cannot use the User-Password Attribute, since it does not receive a password from the HTTP-style client. The CHAP-Challenge and CHAP-Password attributes described in [RFC1994] are also not suitable since the Challenge Handshake Authentication Protocol (CHAP) algorithm is not compatible with HTTP Digest.
代わりに、ローカルユーザデータベースを維持する、サーバーは、集中ユーザデータベースにアクセスするためにRADIUSを使用することができます。しかし、RADIUS [RFC2865]はHTTPダイジェスト認証をサポートしていません。それはHTTP形式のクライアントからのパスワードを受信しないため、RADIUSクライアントは、ユーザー・パスワード属性を使用することはできません。チャレンジハンドシェイク認証プロトコル（CHAP）アルゴリズムは、HTTPダイジェストと互換性がないので、[RFC1994]に記載のCHAPチャレンジとCHAP-パスワード属性も適していません。
This document defines new attributes that enable the RADIUS server to perform the digest calculation defined in [RFC2617], providing support for Digest Authentication as a native authentication mechanism within RADIUS.
この文書では、半径内ネイティブ認証メカニズムとしてダイジェスト認証のためのサポートを提供し、[RFC2617]で定義されたダイジェストの計算を実行するためにRADIUSサーバを有効に新しい属性を定義します。
The nonces required by the digest algorithm are generated by the RADIUS server. Generating them in the RADIUS client would save a round-trip, but introduce security and operational issues. Some digest algorithms -- e.g., AKA [RFC3310] -- would not work.
ダイジェストアルゴリズムに必要ナンスは、RADIUSサーバによって生成されます。 RADIUSクライアントでそれらを生成するとの往復を保存しますが、セキュリティと運用上の問題を紹介します。いくつかのダイジェストアルゴリズム - 例えば、AKA [RFC3310] - 動作しないでしょう。
Figure 2 depicts a scenario in which the HTTP-style server defers authentication to a RADIUS server. Entities A and B communicate using HTTP or SIP, while entities B and C communicate using RADIUS.
図2は、HTTP形式のサーバがRADIUSサーバに認証を延期するシナリオを描いています。エンティティB及びCは、RADIUSを使用して通信しながら、エンティティAとBは、HTTPまたはSIPを使用して通信します。
HTTP/SIP RADIUS
HTTP / SIP RADIUS
+-----+ (1) +-----+ +-----+
| |==========>| | (2) | |
| | | |---------->| |
| | | | (3) | |
| | (4) | |<----------| |
| |<==========| | | |
| | (5) | | | |
| |==========>| | | |
| A | | B | (6) | C |
| | | |---------->| |
| | | | (7) | |
| | | |<----------| |
| | (8) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
====> HTTP/SIP
----> RADIUS
Figure 2: HTTP Digest over RADIUS
図2：RADIUS経由HTTPダイジェスト
The entities have the following roles:
エンティティは以下の役割を持っています：
A: HTTP client / SIP UA
：HTTPクライアント/ SIP UA
B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} acting also as a RADIUS NAS
B：RADIUS NASとしても{HTTPサーバ/ HTTPプロキシサーバ/ SIPプロキシサーバ/ SIP UAS}演技
C: RADIUS server
C：RADIUSサーバ
The following messages are sent in this scenario:
以下のメッセージは、このシナリオに送信されます。
A sends B an HTTP/SIP request without an Authorization header (step 1). B sends an Access-Request packet with the newly defined Digest-Method and Digest-URI attributes but without a Digest-Nonce Attribute to the RADIUS server, C (step 2). C chooses a nonce and responds with an Access-Challenge (step 3). This Access-Challenge contains Digest attributes, from which B takes values to construct an HTTP/SIP "(Proxy) Authorization required" response. B sends this response to A (step 4). A resends its request with its credentials (step 5). B sends an Access-Request to C (step 6). C checks the credentials and replies with Access-Accept or Access-Reject (step 7). Depending on C's result, B processes A's request or rejects it with a "(Proxy) Authorization required" response (step 8).
Aは、AuthorizationヘッダなしのHTTP / SIPリクエスト（ステップ1）Bを送信します。 Bは、新たに定義されたダイジェスト・メソッドによるアクセス要求パケットを送信し、ダイジェスト-URIは、RADIUSサーバにダイジェスト・ナンス属性を持たないが、属性、C（ステップ2）。 Cは、ノンスを選択し、アクセス・チャレンジ（ステップ3）で応答します。このアクセスチャレンジHTTP / SIP構築するための値をとるBからダイジェスト属性、応答「（プロキシ）認証が必要」を含みます。 Bは、（ステップ4）にこの応答を送ります。 Aは、そのクレデンシャル（ステップ5）との要求を再送します。 Bは、C（ステップ6）へのアクセス要求を送信します。 Cは、資格情報を確認し、接続許可またはアクセス拒否（ステップ7）で応答します。 Cの結果に応じて、BはAの要求を処理し、または「（プロキシ）認証に必要な」応答（ステップ8）でそれを拒否します。
The attributes described in this document are sent in cleartext. Therefore, were a RADIUS client to accept secure connections (HTTPS or SIPS) from HTTP-style clients, this could result in information intentionally protected by HTTP-style clients being sent in the clear during RADIUS exchange.
この文書で説明する属性はクリアテキストで送信されます。そのため、HTTP風のクライアントからのセキュアな接続（HTTPSまたはSIPS）を受け入れるようにRADIUSクライアントでした、これは意図的にRADIUS交換中に平文で送信されたHTTP形式のクライアントで保護された情報につながる可能性があります。
On reception of an HTTP-style request message, the RADIUS client checks whether it is authorized to authenticate the request. Where an HTTP-style request traverses several proxies, and each of the proxies requests to authenticate the HTTP-style client, the request at the HTTP-style server may contain multiple credential sets.
HTTP形式のリクエストメッセージを受信すると、その要求を認証するために許可されたRADIUSクライアントをチェックしているかどうか。 HTTP形式のリクエストは、いくつかのプロキシを横断し、プロキシ要求のそれぞれは、HTTP形式のクライアントを認証する場合は、HTTPスタイルのサーバーでの要求は、複数の資格情報のセットが含まれていてもよいです。
The RADIUS client can use the realm directive in HTTP to determine which credentials are applicable. Where none of the realms are of interest, the RADIUS client MUST behave as though no relevant credentials were sent. In all situations, the RADIUS client MUST send zero or exactly one credential to the RADIUS server. The RADIUS client MUST choose the credential of the (Proxy-)Authorization header if the realm directive matches its locally configured realm.
RADIUSクライアントは、適用可能な資格情報を決定するためにHTTPレルムディレクティブを使用することができます。王国のどれも興味深いものでない場合は、RADIUSクライアントには、関連する資格情報が送信されなかったかのように振る舞う必要があります。すべての状況では、RADIUSクライアントは、RADIUSサーバにゼロか正確に一つの証明書を送らなければなりません。レルムディレクティブはそのローカルに設定さレルムを一致する場合、RADIUSクライアントは、（Proxy-）Authorizationヘッダーの資格情報を選択する必要があります。
If a matching (Proxy-)Authorization header is present and contains HTTP Digest information, the RADIUS client checks the nonce parameter.
マッチング（Proxy-）Authorizationヘッダが存在し、HTTPダイジェスト情報が含まれている場合は、RADIUSクライアントはナンスパラメータをチェックします。
If the RADIUS client recognizes the nonce, it takes the header directives and puts them into a RADIUS Access-Request packet. It puts the response directive into a Digest-Response Attribute and the realm, nonce, digest-uri, qop, algorithm, cnonce, nc, username, and opaque directives into the respective Digest-Realm, Digest-Nonce, Digest-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce, Digest-Nonce-Count, Digest-Username, and Digest-Opaque attributes. The RADIUS client puts the request method into the Digest-Method Attribute.
RADIUSクライアントはnonceを認識した場合、それはヘッダーディレクティブを取り、RADIUSアクセス要求パケットにそれらを置きます。これは、それぞれのダイジェスト・レルム、ダイジェスト・ノンス、ダイジェスト-URI、ダイジェストにダイジェストレスポンス属性およびレルム、ナンス、ダイジェスト-URIを、QOP、アルゴリズム、cnonce、NC、ユーザ名、および不透明ディレクティブに応答ディレクティブを置きます-Qop、ダイジェスト・アルゴリズム、ダイジェスト-CNonce、ダイジェスト・ナンス・カウント、ダイジェスト・ユーザー名、およびダイジェスト・不透明な属性。 RADIUSクライアントは、ダイジェスト-method属性にリクエストメソッドを置きます。
Due to HTTP syntactic requirements, quoted strings found in HTTP Digest directives may contain escaped quote and backslash characters. When translating these directives into RADIUS attributes, the RADIUS client only removes the leading and trailing quote characters which surround the directive value, it does not unescape anything within the string. See Section 3 for an example.
HTTP構文の要件に、エスケープ引用符やバックスラッシュ文字を含めることができHTTPダイジェストディレクティブで見つかった文字列を引用しました。これらのディレクティブを翻訳するとRADIUSアトリビュートに、RADIUSクライアントのみディレクティブの値を囲む先頭と末尾の引用符を削除し、それが文字列の中で何かをエスケープ解除しません。例えば第3節を参照してください。
If the Quality of Protection (qop) directive's value is 'auth-int', the RADIUS client calculates H(entity-body) as described in [RFC2617], Section 3.2.1, and puts the result in a Digest-Entity-Body-Hash Attribute.
保護品質（QOP）ディレクティブの値が 'のauth-int型である場合には、RADIUSクライアントは[RFC2617]で説明したように、H（エンティティボディ）を算出し、セクション3.2.1、およびダイジェスト・エンティティボディに結果を置きます-hash属性。
The RADIUS client adds a Message-Authenticator Attribute, defined in [RFC3579], and sends the Access-Request packet to the RADIUS server.
RADIUSクライアントは[RFC3579]で定義されたMessage-Authenticatorアトリビュートを追加し、RADIUSサーバへのアクセス要求パケットを送信します。
The RADIUS server processes the packet and responds with an Access-Accept or an Access-Reject.
RADIUSサーバは、パケットを処理し、Access-受け入れるか、またはアクセス拒否で応答します。
After having received an Access-Accept from the RADIUS server, the RADIUS client constructs an Authentication-Info header:
受信した後、RADIUSサーバからのアクセスを承諾、RADIUSクライアントは認証-Infoヘッダを構築します。
o If the Access-Accept packet contains a Digest-Response-Auth Attribute, the RADIUS client checks the Digest-Qop Attribute:
アクセス - 受け入れパケットはダイジェスト・レスポンス認証属性が含まれている場合は、O、RADIUSクライアントがダイジェストQOP属性をチェックします。
* If the Digest-Qop Attribute's value is 'auth' or not specified, the RADIUS client puts the Digest-Response-Auth Attribute's content into the Authentication-Info header's rspauth directive of the HTTP-style response.
ダイジェストQOP属性の値が指定された「認証」またはされていない場合*、RADIUSクライアントは、HTTP形式のレスポンスの認証 - インフォメーションヘッダーのrspauthディレクティブにダイジェスト・レスポンス認証属性の内容を置きます。
* If the Digest-Qop Attribute's value is 'auth-int', the RADIUS client ignores the Access-Accept packet and behaves as if it had received an Access-Reject packet (Digest-Response-Auth can't be correct as the RADIUS server does not know the contents of the HTTP-style response's body).
*ダイジェストQOP属性の値が 'のauth-int型である場合には、RADIUSクライアントは、接続許可パケットを無視し、それは（ダイジェスト・レスポンス認証はRADIUSとして正しいことはできませんアクセス拒否パケットを受信したかのように振る舞いますサーバーは）HTTP形式のレスポンスのボディの内容を知りません。
o If the Access-Accept packet contains a Digest-HA1 Attribute, the RADIUS client checks the qop and algorithm directives in the Authorization header of the HTTP-style request it wants to authorize:
アクセス - 受け入れパケットがダイジェスト-HA1属性が含まれている場合は、O、RADIUSクライアントは、それが認可したいHTTP形式のリクエストのAuthorizationヘッダ内QOPとアルゴリズムのディレクティブをチェックします。
* If the qop directive is missing or its value is 'auth', the RADIUS client ignores the Digest-HA1 Attribute. It does not include an Authentication-Info header in its HTTP-style response.
qopのディレクティブが存在しないか、その値が「認証」の場合*、RADIUSクライアントがダイジェスト-HA1属性を無視します。それは、そのHTTP形式の応答での認証-Infoヘッダーが含まれていません。
* If the qop directive's value is 'auth-int' and at least one of the following conditions is true, the RADIUS client calculates the contents of the HTTP-style response's rspauth directive:
* QOPディレクティブの値は 'のauth-int型であり、次の条件の少なくともいずれかに該当する、RADIUSクライアントは、HTTP形式のレスポンスのrspauth指令の内容を計算した場合：
+ The algorithm directive's value is 'MD5-sess' or 'AKAv1- MD5-sess'.
+アルゴリズムディレクティブの値は「MD5-SESの」または「AKAv1- MD5-のSES」です。
+ IP Security (IPsec) is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see Section 8).
+ IPセキュリティ（IPSec）をIPsecでRADIUSクライアントとRADIUSサーバ間のトラフィックを保護するように構成されている（セクション8を参照）。
The RADIUS client creates the HTTP-style response message and calculates the hash of this message's body. It uses the result and the Digest-URI Attribute's value of the corresponding Access-Request packet to perform the H(A2) calculation. It takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce, and Digest-Qop values of the corresponding Access-Request and the Digest-HA1 Attribute's value to finish the computation of the rspauth value.
RADIUSクライアントは、HTTP形式の応答メッセージを作成し、このメッセージのボディのハッシュを計算します。これは、H（A2）の計算を実行するために結果とそれに対応するアクセス要求パケットのダイジェスト-URI属性の値を使用しています。それはrspauth値の計算を終了するダイジェスト・ナンス、ダイジェスト・ナンス・カウント、ダイジェスト-CNonce、および対応するアクセス要求のダイジェストQOP値とダイジェスト-HA1属性の値をとります。
o If the Access-Accept packet contains neither a Digest-Response-Auth nor a Digest-HA1 Attribute, the RADIUS client will not create an Authentication-Info header for its HTTP-style response.
アクセス - 受け入れパケットはダイジェスト・レスポンス認証やダイジェスト-HA1属性のいずれもが含まれている場合は、O、RADIUSクライアントはHTTP形式のレスポンスの認証-Infoヘッダーを作成しません。
When the RADIUS server provides a Digest-Nextnonce Attribute in the Access-Accept packet, the RADIUS client puts the contents of this attribute into a nextnonce directive. Now it can send an HTTP-style response.
RADIUSサーバは、アクセス・受け入れパケット内のダイジェストNextnonce属性を提供する場合、RADIUSクライアントはnextnonceディレクティブには、この属性の内容を置きます。今ではHTTP形式のレスポンスを送信することができます。
If the RADIUS client did receive an HTTP-style request without a (Proxy-)Authorization header matching its locally configured realm value, it obtains a new nonce and sends an error response (401 or 407) containing a (Proxy-)Authenticate header.
RADIUSクライアントがローカルに設定レルム値と一致する（Proxy-）AuthorizationヘッダなしHTTP形式のリクエストを受信した場合、それは新たなnonceを取得し（Proxy-）認証ヘッダを含むエラー応答（401又は407）を送信します。
If the RADIUS client receives an Access-Challenge packet in response to an Access-Request containing a Digest-Nonce Attribute, the RADIUS server did not accept the nonce. If a Digest-Stale Attribute is present in the Access-Challenge and has a value of 'true' (without surrounding quotes), the RADIUS client sends an error response (401 or 407) containing a WWW-/Proxy-Authenticate header with the stale directive set to 'true' and the digest directives derived from the Digest-* attributes.
RADIUSクライアントがダイジェスト・ナンスの属性を含むアクセス要求に応じて、アクセスチャレンジパケットを受信した場合、RADIUSサーバは、nonceを受け入れませんでした。ダイジェスト古い項目がアクセスチャレンジに存在し、（周囲の引用符なし）「真」の値を有する場合、RADIUSクライアントが有するWWW-/プロキシ認証ヘッダを含むエラー応答（401又は407）を送信します古いディレクティブは、「真」に設定し、ダイジェストディレクティブはDigest- *属性から派生します。
If the RADIUS client receives an Access-Reject from the RADIUS server, it sends an error response to the HTTP-style request it has received. If the RADIUS client does not receive a response, it retransmits or fails over to another RADIUS server as described in [RFC2865].
RADIUSクライアントは、RADIUSサーバから拒否アクセスを受信した場合、それが受信したHTTPスタイルの要求にエラー応答を送信します。 RADIUSクライアントが応答を受信しない場合は、[RFC2865]で説明したように、それは再送したり、別のRADIUSサーバーにフェールオーバーします。
The RADIUS client has two ways to obtain nonces: it has received one in a Digest-Nextnonce Attribute of a previously received Access-Accept packet, or it asks the RADIUS server for one. To do the latter, it sends an Access-Request containing a Digest-Method and a Digest-URI Attribute, but without a Digest-Nonce Attribute. It adds a Message-Authenticator (see [RFC3579]) Attribute to the Access-Request packet. The RADIUS server chooses a nonce and responds with an Access-Challenge containing a Digest-Nonce Attribute.
RADIUSクライアントは、ナンスを得るには二つの方法があります。それは、以前に受信したAccess-受け入れパケットのダイジェスト-Nextnonce属性の1を受信している、またはそれは1のためのRADIUSサーバを要求します。後者を行うには、それはダイジェスト・メソッドとダイジェスト-URI属性を含むアクセス要求を送信しますが、ダイジェスト・ナンス属性を持ちません。これは、メッセージ認証（[RFC3579]を参照）のAccess-Requestパケットに属性を追加します。 RADIUSサーバは、nonceを選択し、ダイジェスト-Nonceの属性を含むアクセスチャレンジで応答します。
The RADIUS client constructs a (Proxy-)Authenticate header using the received Digest-Nonce and Digest-Realm attributes to fill the nonce and realm directives. The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-Domain, and Digest-Opaque attributes in the Access-Challenge carrying the nonce. If these attributes are present, the client MUST use them.
RADIUSクライアントは、受信したダイジェストノンスとダイジェストレルムを使用して（Proxy-）認証ヘッダはナンスとレルムディレクティブを充填する属性構築物。 RADIUSサーバは、ダイジェストQOP、ダイジェスト・アルゴリズム、ダイジェスト・ドメイン、およびナンスを運ぶアクセスチャレンジでのダイジェスト-不透明な属性を送ることができます。これらの属性が存在する場合、クライアントはそれらを使用しなければなりません。
If the RADIUS server receives an Access-Request packet with a Digest-Method and a Digest-URI Attribute but without a Digest-Nonce Attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce Attribute and sends it in an Access-Challenge packet to the RADIUS client. The RADIUS server MUST add Digest-Realm, Message-Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm and one or
RADIUSサーバは、ダイジェスト・メソッドとダイジェスト-URI属性ではなくダイジェスト・ナンス属性なしのAccess-Requestパケットを受信した場合、それはnonceを選択します。これは、ダイジェスト・ナンス属性にnonceを置き、RADIUSクライアントにアクセスチャレンジパケットで送信します。 RADIUSサーバはダイジェストレルム、メッセージ認証を追加しなければならない（参照[RFC3579]）は、ダイジェストアルゴリズムおよび一つまたはを追加すべきです
more Digest-Qop, and MAY add Digest-Domain or Digest-Opaque attributes to the Access-Challenge packet.
ダイジェストQOP以上、およびAccess-Challengeパケットにダイジェスト・ドメインまたはダイジェスト-不透明な属性を追加することができます。
If the RADIUS server receives an Access-Request packet containing a Digest-Response Attribute, it looks for the following attributes:
RADIUSサーバはダイジェスト・レスポンス属性を含むアクセス要求パケットを受信した場合、それは次の属性を検索します。
Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, Digest-Algorithm, and Digest-Username. Depending on the content of Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body-Hash, Digest-CNonce, and Digest-AKA-Auts, too. See [RFC2617] and [RFC3310] for details. If the Digest-Algorithm Attribute is missing, 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque Attribute along with the nonce, the Access-Request MUST have a matching Digest-Opaque Attribute.
ダイジェスト・レルム、ダイジェスト・ノンス、ダイジェスト・メソッド、ダイジェスト-URI、ダイジェスト-QOP、ダイジェスト・アルゴリズム、およびダイジェスト・ユーザー名。ダイジェスト・アルゴリズムとダイジェストQOPの内容によっては、それはあまりにも、ダイジェスト・エンティティボディ - ハッシュ、ダイジェスト-CNonce、およびダイジェスト-AKA-AUTSを探します。詳細については、[RFC2617]と[RFC3310]を参照してください。ダイジェスト・アルゴリズムの属性が欠落している場合は、「MD5」は想定されます。 RADIUSサーバは、ナンスと一緒にダイジェスト-不透明属性を発行した場合、アクセス要求は、一致するダイジェスト-不透明な属性を持たなければなりません。
If mandatory attributes are missing, it MUST respond with an Access-Reject packet.
必須属性が欠落している場合は、アクセス拒否パケットで応じなければなりません。
The RADIUS server removes '\' characters that escape quote and '\' characters from the text values it has received in the Digest-* attributes.
RADIUSサーバは、テキストがDigest- *属性で、受信した値からの引用と「\」文字をエスケープ「\」文字を削除します。
If the mandatory attributes are present, the RADIUS server MUST check if the RADIUS client is authorized to serve users of the realm mentioned in the Digest-Realm Attribute. If the RADIUS client is not authorized, the RADIUS server MUST send an Access-Reject. The RADIUS server SHOULD log the event so as to notify the operator, and MAY take additional action such as sending an Access-Reject in response to all future requests from this client, until this behavior is reset by management action.
必須属性が存在している場合はRADIUSクライアントがダイジェスト-realm属性に言及した分野のユーザーにサービスを提供するために許可されている場合は、RADIUSサーバがチェックしなければなりません。 RADIUSクライアントが許可されていない場合、RADIUSサーバーはアクセス拒否を送らなければなりません。 RADIUSサーバは、オペレータに通知するようにイベントをログに記録しなければならず、この動作は、管理アクションによってリセットされるまでは、そのようなこのクライアントからのすべての将来の要求に応じて、アクセス拒否を送信するように、追加措置を取ってもよいです。
The RADIUS server determines the age of the nonce in the Digest-Nonce by using an embedded timestamp or by looking it up in a local table. The RADIUS server MUST check the integrity of the nonce if it embeds the timestamp in the nonce. Section 2.2.2 describes how the server handles old nonces.
RADIUSサーバは、埋め込まれたタイムスタンプを使用するか、またはローカルテーブルでそれを見ることによって、ダイジェスト-Nonceの中ナンスの年齢を決定します。それはナンスにタイムスタンプを埋め込む場合、RADIUSサーバは、ナンスの整合性をチェックしなければなりません。 2.2.2項では、サーバが古いナンスを処理する方法について説明します。
If the Access-Request message passes the checks described above, the RADIUS server calculates the digest response as described in [RFC2617]. To look up the password, the RADIUS server uses the RADIUS User-Name Attribute. The RADIUS server MUST check if the user identified by the User-Name Attribute:
Access-Requestメッセージは、上記のチェックをパスした場合、[RFC2617]に記載されているように、RADIUSサーバがダイジェスト応答を算出します。パスワードを検索するには、RADIUSサーバは、RADIUS User-Name属性を使用しています。 RADIUSサーバは、User-Name属性で識別されるユーザーかどうかを確認しなければなりません：
o is authorized to access the protection space and o is authorized to use the URI included in the SIP-AOR Attribute, if this attribute is present.
Oは、保護空間へのアクセスを許可されるとoがこの属性が存在する場合URIは、SIP-AOR属性に含まれて使用することが許可されています。
If any of those checks fails, the RADIUS server MUST send an Access-Reject.
これらのチェックのいずれかが失敗した場合、RADIUSサーバーはアクセス拒否を送らなければなりません。
Correlation between User-Name and SIP-AOR AVP values is required just to avoid any user from registering or misusing a SIP-AOR that has been allocated to a different user.
ユーザ名及びSIP-AOR AVP値の間の相関は、単に登録又は異なるユーザに割り当てられたSIP-AORを悪用から任意のユーザを回避するために必要とされます。
All values required for the digest calculation are taken from the Digest attributes described in this document. If the calculated digest response equals the value received in the Digest-Response Attribute, the authentication was successful.
ダイジェスト計算に必要なすべての値は、この文書で説明するダイジェスト属性から取得されます。計算されたダイジェストレスポンスがダイジェスト・レスポンス属性で受信した値に等しい場合は、認証が成功しました。
If the response values match, but the RADIUS server considers the nonce in the Digest-Nonce Attribute too old, it sends an Access-Challenge packet containing a new nonce and a Digest-Stale Attribute with a value of 'true' (without surrounding quotes).
応答値は一致しますが、RADIUSサーバはダイジェスト・ナンスでnonceがあまりにも古い属性とみなし、それは引用符を囲むことなく、新しいナンスと（「真」の値を持つダイジェスト・古くなった属性を含むアクセスチャレンジパケットを送信した場合）。
If the response values don't match, the RADIUS server responds with an Access-Reject.
応答値が一致しない場合は、RADIUSサーバーはアクセス拒否で応答します。
If the authentication was successful, the RADIUS server adds an attribute to the Access-Accept packet that can be used by the RADIUS client to construct an Authentication-Info header:
認証が成功した場合、RADIUSサーバは、認証-Infoヘッダーを構築するためにRADIUSクライアントで使用することができ、接続許可パケットに属性を追加します。
o If the Digest-Qop Attribute's value is 'auth' or unspecified, the RADIUS server SHOULD put a Digest-Response-Auth Attribute into the Access-Accept packet.
ダイジェストQOP属性の値が「認証」または指定されていない場合は、O、RADIUSサーバは、接続許可パケットにダイジェスト・レスポンス認証属性を置くべきです。
o If the Digest-Qop Attribute's value is 'auth-int' and at least one of the following conditions is true, the RADIUS server SHOULD put a Digest-HA1 Attribute into the Access-Accept packet:
OダイジェストQOP属性の値が 'のauth-int型の場合は、次の条件の少なくともいずれかに該当する、RADIUSサーバがダイジェスト-HA1を置くべきは、接続許可パケットに属性：
* The Digest-Algorithm Attribute's value is 'MD5-sess' or 'AKAv1-MD5-sess'.
*ダイジェスト・アルゴリズムの属性の値は「MD5-SESの」または「AKAv1-MD5-のSES」です。
* IPsec is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see Section 8).
* IPsecが（セクション8を参照）のIPsecとRADIUSクライアントとRADIUSサーバ間のトラフィックを保護するように構成されています。
In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be sent.
他のすべてのケースでは、ダイジェスト・レスポンス認証やダイジェスト-HA1を送ってはいけません。
RADIUS servers MAY construct a Digest-Nextnonce Attribute and add it to the Access-Accept packet. This is useful to limit the lifetime of a nonce and to save a round-trip in future requests (see nextnonce discussion in [RFC2617], Section 3.2.3). The RADIUS server adds a Message-Authenticator Attribute (see [RFC3579]) and sends the Access-Accept packet to the RADIUS client.
RADIUSサーバは、ダイジェスト-Nextnonce属性を構築し、Access-受け入れパケットに追加してもよい（MAY）。これは、ナンスの寿命を制限し、将来の要求（[RFC2617]でnextnonce議論、3.2.3項を参照）での往復を保存するのに便利です。 RADIUSサーバは、（参照[RFC3579]）Message-Authenticatorアトリビュートを追加し、RADIUSクライアントへのアクセスは、受け入れパケットを送信します。
If the RADIUS server does not accept the nonce received in an Access-Request packet but authentication was successful, the RADIUS server MUST send an Access-Challenge packet containing a Digest-Stale Attribute set to 'true' (without surrounding quotes). The RADIUS server MUST add Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm, SHOULD add Digest-Algorithm and one or more Digest-Qops, and MAY add Digest-Domain or Digest-Opaque attributes to the Access-Challenge packet.
nonceを受け入れないRADIUSサーバがアクセス要求パケットで受信したが、認証が成功した場合、RADIUSサーバは、（引用符を囲むなし）「真」に設定さダイジェスト古い属性を含むアクセスチャレンジパケットを送らなければなりません。 RADIUSサーバは、メッセージ認証を（[RFC3579]を参照）を追加する必要があり、ダイジェスト・ノンス、ダイジェスト・レルムは、ダイジェスト・アルゴリズムと1つまたは複数のダイジェスト-のQOPを追加する必要があり、Accessにダイジェスト・ドメインまたはダイジェスト-不透明な属性を追加することができます-Challengeパケット。
If not stated otherwise, the attributes have the following format:
特に明記していない場合、属性の形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Quote and backslash characters in Digest-* attributes representing HTTP-style directives with a quoted-string syntax are escaped. The surrounding quotes are removed. They are syntactical delimiters that are redundant in RADIUS. For example, the directive
Digest- *での見積もりとバックスラッシュ文字は引用符で囲まれた文字列の構文で表すHTTP形式の指令がエスケープされている属性。周囲の引用符が削除されます。彼らは、RADIUSで重複している構文の区切り文字です。たとえば、ディレクティブ
realm="the \"example\" value"
レルムは=「\」例の\「値」
is represented as follows:
次のように表されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest-Realm | 23 | the \"example\" value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description If this attribute is present in an Access-Request message, a RADIUS server implementing this specification MUST treat the Access-Request as a request for Digest Authentication. When a RADIUS client receives a (Proxy-)Authorization header, it puts the request-digest value into a Digest-Response Attribute. This attribute (which enables the user to prove possession of the password) MUST only be used in Access-Request packets.
説明この属性は、Access-Requestメッセージに存在している場合は、この仕様を実装するRADIUSサーバは、ダイジェスト認証のための要求として、アクセス要求を扱わなければなりません。 RADIUSクライアント（Proxy-）Authorizationヘッダを受信すると、ダイジェストレスポンス属性に要求ダイジェスト値を置きます。この属性（パスワードの所有を証明するためにユーザを可能にします）のみのAccess-Requestパケットで使用する必要があります。
Type 103 for Digest-Response. Length >= 3 Text When using HTTP Digest, the text field is 32 octets long and contains a hexadecimal representation of a 16-octet digest value as it was calculated by the authenticated client. Other digest algorithms MAY define different digest lengths. The text field MUST be copied from request-digest of digest-response [RFC2617] without surrounding quotes.
ダイジェスト・レスポンスのために103を入力します。 HTTPダイジェストを使用して、長さ> = 3テキストは、テキストフィールドは、32オクテットの長さであり、それは認証されたクライアントによって計算されたように16オクテットの16進表現をダイジェスト値が含まれています。他のアルゴリズムが異なるダイジェストの長さを定義するかもしれダイジェスト。テキストフィールドは、引用符を囲むことなくダイジェストレスポンス[RFC2617]の要求ダイジェストからコピーされなければなりません。
Description This attribute describes a protection space component of the RADIUS server. HTTP-style protocols differ in their definition of the protection space. See [RFC2617], Section 1.2, for details. It MUST only be used in Access-Request, Access-Challenge, and Accounting-Request packets. Type 104 for Digest-Realm Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the realm directive (realm-value according to [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the RADIUS server puts the expected realm value into this attribute.
説明この属性は、RADIUSサーバの保護空間のコンポーネントについて説明します。 HTTP形式のプロトコルは、保護空間のその定義が異なります。詳細については、[RFC2617]、セクション1.2を参照してください。それが唯一のアクセス要求、アクセスチャレンジ、およびアカウンティング要求パケットで使用されなければなりません。アクセス・リクエストで> = 3テキストダイジェスト・レルムの長さのために104を入力し、RADIUSクライアントは、それが認証したいHTTP形式のリクエストから引用符を囲むことなく、（[RFC2617]によると、レルム値）レルムディレクティブの値をとります。アクセスチャレンジパケットでは、RADIUSサーバは、この属性に期待レルム値を置きます。
Description This attribute holds a nonce to be used in the HTTP Digest calculation. If the Access-Request had a Digest-Method and a Digest-URI but no Digest-Nonce Attribute, the RADIUS server MUST put a Digest-Nonce Attribute into its Access-Challenge packet. This attribute MUST only be used in Access-Request and Access-Challenge packets. Type 105 for Digest-Nonce Length >= 3
説明この属性は、HTTPダイジェスト計算に使用するnonceを保持しています。アクセス要求がダイジェスト・メソッドとダイジェスト-URIが、無ダイジェスト-Nonceの属性を持っていた場合、RADIUSサーバは、そのアクセスチャレンジパケットにダイジェスト-Nonceの属性を置く必要があります。この属性は、アクセス要求とアクセスチャレンジパケットで使用されなければなりません。ダイジェスト・ナンス長さ> = 3 105を入力
Text In Access-Requests, the RADIUS client takes the value of the nonce directive (nonce-value in [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the attribute contains the nonce selected by the RADIUS server.
アクセス - 要求内のテキスト、RADIUSクライアントは、それが認証したいHTTP形式のリクエストから引用符を囲むことなく、ナンスディレクティブ（[RFC2617]でナンス値）の値をとります。アクセスチャレンジパケットでは、属性は、RADIUSサーバによって選択されたナンスが含まれています。
Description This attribute enables the RADIUS server to prove possession of the password. If the previously received Digest-Qop Attribute was 'auth-int' (without surrounding quotes), the RADIUS server MUST send a Digest-HA1 Attribute instead of a Digest-Response-Auth Attribute. The Digest-Response-Auth Attribute MUST only be used in Access-Accept packets. The RADIUS client puts the attribute value without surrounding quotes into the rspauth directive of the Authentication-Info header. Type 106 for Digest-Response-Auth. Length >= 3 Text The RADIUS server calculates a digest according to Section 3.2.3 of [RFC2617] and copies the result into this attribute. Digest algorithms other than the one defined in [RFC2617] MAY define digest lengths other than 32.
説明この属性は、パスワードの所有を証明するためにRADIUSサーバを有効にします。以前に受信したダイジェストQOP属性は、（周囲の引用符なし） "のauth-int型だった場合、RADIUSサーバは、ダイジェスト-HA1はなくダイジェスト・レスポンス認証属性の属性送らなければなりません。ダイジェスト・レスポンス認証属性のみで使用する必要がありますAccess-Acceptパケット。 RADIUSクライアントは認証-Infoヘッダーのrspauthディレクティブの中に引用符を囲むことなく、属性値を置きます。ダイジェスト・レスポンス認証のために106を入力します。長さ> = 3テキストRADIUSサーバは、[RFC2617]のセクション3.2.3と、この属性にコピー結果に応じてダイジェストを計算します。 [RFC2617]で定義されたもの以外のダイジェストアルゴリズムは、ダイジェストが32以外の長さを定義するかもしれません。
This attribute holds a nonce to be used in the HTTP Digest calculation.
この属性は、HTTPダイジェスト計算に使用するnonceを保持しています。
Description The RADIUS server MAY put a Digest-Nextnonce Attribute into an Access-Accept packet. If this attribute is present, the RADIUS client MUST put the contents of this attribute into the nextnonce directive of an Authentication-Info header in its HTTP-style response. This attribute MUST only be used in Access-Accept packets. Type 107 for Digest-Nextnonce Length >= 3 Text It is recommended that this text be base64 or hexadecimal data.
説明RADIUSサーバは、接続許可パケットにダイジェストNextnonce属性を置いてもよいです。この属性が存在する場合、RADIUSクライアントはHTTP形式の応答での認証-Infoヘッダーのnextnonceディレクティブには、この属性の内容を置く必要があります。この属性のみで使用する必要がありますAccess-Acceptパケット。このテキストは、BASE64または16進数のデータにすることをお勧めしダイジェスト-Nextnonceの長さ> = 3のテキストのために107を入力します。
Description This attribute holds the method value to be used in the HTTP Digest calculation. This attribute MUST only be used in Access-Request and Accounting-Request packets. Type 108 for Digest-Method Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the request method from the HTTP-style request it wants to authenticate.
説明この属性は、HTTPダイジェスト計算に使用するメソッドの値を保持しています。この属性は、アクセス要求およびアカウンティング要求パケットで使用されなければなりません。アクセス - 要求でダイジェスト・メソッドの長さ> = 3テキストのために108を入力し、RADIUSクライアントは、それが認証したいHTTP形式のリクエストからのリクエストメソッドの値をとります。
Description This attribute is used to transport the contents of the digest-uri directive or the URI of the HTTP-style request. It MUST only be used in Access-Request and Accounting-Request packets. Type 109 for Digest-URI Length >= 3 Text If the HTTP-style request has an Authorization header, the RADIUS client puts the value of the uri directive found in the HTTP-style request Authorization header (known as "digest-uri-value" in Section 3.2.2 of [RFC2617]) without surrounding quotes into this attribute. If there is no Authorization header, the RADIUS client takes the value of the request URI from the HTTP-style request it wants to authenticate.
説明この属性は、ダイジェスト-URIディレクティブまたはHTTP形式のリクエストのURIの内容を転送するために使用されます。それが唯一のアクセス要求およびアカウンティング要求パケットで使用されなければなりません。 HTTP形式のリクエストがAuthorizationヘッダを持っている場合は、RADIUSクライアントは、「ダイジェスト-uriの値として知られているHTTP-スタイルリクエストのAuthorizationヘッダ（で見つかったURIディレクティブの値を置くダイジェスト-URIの長さ> = 3テキストのために109を入力します"）[RFC2617]のセクション3.2.2でこの属性に引用符を囲むなし。何Authorizationヘッダがない場合は、RADIUSクライアントは、それが認証したいHTTP形式のリクエストからリクエストURIの値をとります。
Description This attribute holds the Quality of Protection parameter that influences the HTTP Digest calculation. This attribute MUST only be used in Access-Request, Access-Challenge, and Accounting-Request packets. A RADIUS client SHOULD insert one of the Digest-Qop attributes it has received in a previous Access-Challenge packet. RADIUS servers SHOULD insert at least one Digest-Qop Attribute in an Access-Challenge packet. Digest-Qop is optional in order to preserve backward compatibility with a minimal implementation of [RFC2069].
説明この属性は、HTTPダイジェスト計算に影響を与える保護パラメータの品質を保持しています。この属性は、アクセス要求、アクセスチャレンジ、およびアカウンティング要求パケットで使用されなければなりません。 RADIUSクライアントは、ダイジェストQOPの一つは、それが以前のAccess-Challengeパケットで受信した属性を挿入する必要があり。 RADIUSサーバは、アクセスチャレンジパケット内の少なくとも1つのダイジェストQOP属性を挿入する必要があります。ダイジェストQOPは、[RFC2069]の最小限の実装との下位互換性を維持するためにオプションです。
Type 110 for Digest-Qop Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the qop directive (qop-value as described in [RFC2617]) from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the RADIUS server puts a desired qop-value into this attribute. If the RADIUS server supports more than one "quality of protection" value, it puts each qop-value into a separate Digest-Qop Attribute.
ダイジェストQOP長アクセス - 要求で> = 3テキストのために110を入力し、RADIUSクライアントは、それが認証したいHTTP形式のリクエストから（[RFC2617]で説明したようにQOP値）QOPディレクティブの値をとります。アクセスチャレンジパケットに、RADIUSサーバは、この属性に所望QOP値を置きます。 RADIUSサーバが複数の「品質保護の」値をサポートしている場合、それは別のダイジェストQOP属性に各QOP値を置きます。
Description This attribute holds the algorithm parameter that influences the HTTP Digest calculation. It MUST only be used in Access-Request, Access-Challenge and Accounting-Request packets. If this attribute is missing, MD5 is assumed. Type 111 for Digest-Algorithm Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the algorithm directive (as described in [RFC2617], Section 3.2.1) from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the RADIUS server SHOULD put the desired algorithm into this attribute.
説明この属性は、HTTPダイジェスト計算に影響を与えるアルゴリズムパラメータを保持しています。それが唯一のアクセス要求、アクセスチャレンジおよびアカウンティング要求パケットで使用されなければなりません。この属性が欠落している場合は、MD5が想定されます。それが認証したいHTTP形式のリクエストから（[RFC2617]、セクション3.2.1で説明したように）アクセス - 要求でダイジェスト・アルゴリズムの長さ> = 3テキストのために111を入力し、RADIUSクライアントは、アルゴリズムのディレクティブの値をとります。アクセスチャレンジパケットでは、RADIUSサーバは、この属性に必要なアルゴリズムを置くべきです。
Description When using the qop-value 'auth-int', a hash of the HTTP-style message body's contents is required for digest calculation. Instead of sending the complete body of the message, only its hash value is sent. This hash value can be used directly in the digest calculation.
説明QOP値「のauth-INT」を使用する場合、HTTP形式のメッセージ本文の内容のハッシュダイジェストの計算に必要です。代わりに、メッセージの完全なボディを送信する、唯一そのハッシュ値が送信されます。このハッシュ値は、ダイジェスト計算に直接使用することができます。
The clarifications described in section 22.4 of [RFC3261] about the hash of empty entity bodies apply to the Digest-Entity-Body-Hash Attribute. This attribute MUST only be sent in Access-Request packets. Type 112 for Digest-Entity-Body-Hash Length >= 3
空のエンティティボディのハッシュについて[RFC3261]のセクション22.4で説明の明確化は、ダイジェスト・エンティティボディ - ハッシュ属性に適用されます。この属性は、アクセス要求パケットで送らなければなりません。ダイジェスト・エンティティボディ - ハッシュの長さ> = 3のために112を入力します
Text The attribute holds the hexadecimal representation of H(entity-body). This hash is required by certain authentication mechanisms, such as HTTP Digest with quality of protection set to 'auth-int'. RADIUS clients MUST use this attribute to transport the hash of the entity body when HTTP Digest is the authentication mechanism and the RADIUS server requires that the integrity of the entity body (e.g., qop parameter set to 'auth-int') be verified. Extensions to this document may define support for authentication mechanisms other than HTTP Digest.
テキスト属性は、H（エンティティボディ）の16進表現を保持しています。このハッシュは「AUTH-INT」に設定保護の品質で、このようなHTTPダイジェストなどの特定の認証メカニズムによって必要とされます。 RADIUSクライアントは、HTTPダイジェスト認証メカニズムであり、RADIUSサーバがエンティティボディ（「のauth-INT」に設定例えば、QOPパラメータ）の整合性を検証することを必要とするときにエンティティボディのハッシュを輸送するために、この属性を使用する必要があります。このドキュメントへの拡張は、HTTPダイジェスト以外の認証メカニズムのサポートを定義することがあります。
Description This attribute holds the client nonce parameter that is used in the HTTP Digest calculation. It MUST only be used in Access-Request packets. Type 113 for Digest-CNonce Length >= 3 Text This attribute includes the value of the cnonce-value [RFC2617] without surrounding quotes, taken from the HTTP-style request.
説明この属性は、HTTPダイジェスト計算に使用されているクライアントナンスパラメータを保持しています。それが唯一のAccess-Requestパケットで使用する必要があります。 HTTP形式のリクエストから取られた引用符を、周囲ずにダイジェスト-CNonceの長さ> = 3テキストこの属性はcnonce値の値を含んでいる[RFC2617]のために113を入力します。
Description This attribute includes the nonce count parameter that is used to detect replay attacks. The attribute MUST only be used in Access-Request packets. Type 114 for Digest-Nonce-Count Length 10 Text In Access-Requests, the RADIUS client takes the value of the nc directive (nc-value according to [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate.
説明この属性は、リプレイ攻撃を検出するために使用されるナンスカウントパラメータを含んでいます。属性は、唯一のAccess-Requestパケットで使用する必要があります。アクセス - 要求でダイジェスト・ノンス-カウント長10文字のために114を入力し、RADIUSクライアントは、それが認証したいHTTP形式のリクエストから引用符を囲むことなく、（[RFC2617]に係るNC-値）NC指令の値をとります。
Description This attribute holds the user name used in the HTTP Digest calculation. The RADIUS server MUST use this attribute only for the purposes of calculating the digest. In order to determine the appropriate user credentials, the RADIUS server
説明この属性は、HTTPダイジェスト計算に使用されるユーザー名を保持しています。 RADIUSサーバはダイジェストを計算する目的のために、この属性を使用する必要があります。適切なユーザーの資格情報を決定するために、RADIUSサーバ
MUST use the User-Name (1) Attribute, and MUST NOT use the Digest-Username Attribute. This attribute MUST only be used in Access-Request and Accounting-Request packets. Type 115 for Digest-Username Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the username directive (username-value according to [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate.
ユーザー名（1）属性を使用する必要があります、とダイジェスト・ユーザー名属性を使用してはなりません。この属性は、アクセス要求およびアカウンティング要求パケットで使用されなければなりません。アクセス - 要求でダイジェストユーザ名の長さ> = 3テキストのために115を入力し、RADIUSクライアントは、それが認証したいHTTP形式のリクエストから引用符を囲むことなく、（[RFC2617]によると、ユーザ名、値）のユーザ名ディレクティブの値をとります。
Description This attribute holds the opaque parameter that is passed to the HTTP-style client. The HTTP-style client will pass this value back to the server (i.e., the RADIUS client) without modification. This attribute MUST only be used in Access-Request and Access-Challenge packets. Type 116 for Digest-Opaque Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the opaque directive (opaque-value according to [RFC2617]) without surrounding quotes from the HTTP-style request it wants to authenticate and puts it into this attribute. In Access-Challenge packets, the RADIUS server MAY include this attribute.
説明この属性は、HTTPスタイルのクライアントに渡される不透明なパラメータを保持しています。 HTTP形式のクライアントは、変更せずにサーバー（すなわち、RADIUSクライアント）にこの値を渡します。この属性は、アクセス要求とアクセスチャレンジパケットで使用されなければなりません。アクセス - 要求でダイジェスト-不透明な長さ> = 3テキストのために116を入力し、RADIUSクライアントは（[RFC2617]によると、不透明値）不透明なディレクティブの値をとることが認証したいHTTPスタイルの要求から、周囲の引用符なしとこの属性に格納します。アクセスチャレンジパケットでは、RADIUSサーバは、この属性を含むかもしれません。
Description This attribute is a placeholder for future extensions and corresponds to the auth-param parameter defined in Section 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism whereby the RADIUS client and RADIUS server can exchange auth-param extension parameters contained within Digest headers that are not understood by the RADIUS client and for which there are no corresponding stand-alone attributes.
説明この属性は、将来の拡張のためのプレースホルダであり、[RFC2617]のセクション3.2.1で定義されたAUTH-paramパラメータに相当します。ダイジェスト-AUTH-paramがRADIUSクライアントとRADIUSサーバはAUTH-PARAMをRADIUSクライアントによって理解されていないダイジェストヘッダ内に含まれる拡張パラメータを交換することができる機構であり、そのため、該当するスタンドアロン属性が存在しません。
Unlike the previously listed Digest-* attributes, the Digest-Auth-Param contains not only the value but also the parameter name, since the parameter name is unknown to the RADIUS client. If the Digest header contains several unknown parameters, then the RADIUS implementation MUST repeat this attribute, and each instance MUST contain one different unknown Digest parameter/value combination. This attribute MUST ONLY be used in Access-Request, Access-Challenge, Access-Accept, and Accounting-Request packets. Type 117 for Digest-Auth-Param Length >= 3 Text The text consists of the whole parameter, including its name, the equal sign ('='), and quotes.
パラメータ名は、RADIUSクライアントには未知であるため、以前に記載されているDigest- *属性とは異なり、ダイジェスト認証-paramが、値だけでなく、パラメータ名だけでなく、含まれています。ダイジェストヘッダは、いくつかの未知のパラメータが含まれている場合、RADIUSの実装は、この属性を繰り返す必要があり、各インスタンスは、1つの異なる未知のダイジェストパラメータ/値の組み合わせを含まなければなりません。この属性は、専用アクセス-受け入れ、およびアカウンティング要求パケットを、アクセス要求、アクセスチャレンジに使用しなければなりません。ダイジェスト-AUTH-Paramの長さ117を入力> = 3本文テキストは、名前、等号（「=」）、および引用符を含む、全体のパラメータで構成されています。
Description This attribute holds the auts parameter that is used in the Digest AKA [RFC3310] calculation. It is only used if the algorithm of the digest-response denotes a version of AKA Digest [RFC3310]. This attribute MUST only be used in Access-Request packets. Type 118 for Digest-AKA-Auts Length >= 3 Text In Access-Requests, the RADIUS client takes the value of the auts directive (auts-param according to Section 3.4 of [RFC3310]) without surrounding quotes from the HTTP-style request it wants to authenticate.
説明この属性は、ダイジェストAKA [RFC3310]の計算に使用されているAUTSパラメータを保持しています。ダイジェスト応答のアルゴリズムは、AKAダイジェスト[RFC3310]のバージョンを示している場合にのみ使用されます。この属性は、唯一のAccess-Requestパケットで使用する必要があります。ダイジェストAKA-AUTS長アクセス - 要求内> = 3テキストの118を入力し、RADIUSクライアントはHTTP形式のリクエストから周囲の引用符（[RFC3310]のセクション3.4に従ってAUTS-PARAM）AUTS指令の値をとりますそれが認証したいです。
Description When a RADIUS client has asked for a nonce, the RADIUS server MAY send one or more Digest-Domain attributes in its Access-Challenge packet. The RADIUS client puts them into the quoted, space-separated list of URIs of the domain directive of a WWW-Authenticate header. Together with Digest-Realm, the URIs in the list define the protection space (see [RFC2617], Section 3.2.1) for some HTTP-style protocols. This attribute MUST only be used in Access-Challenge and Accounting-Request packets. Type 119 for Digest-Domain Length 3
説明RADIUSクライアントがナンスを求めた場合、RADIUSサーバはダイジェスト・ドメインは、そのアクセスチャレンジパケットの属性一つ以上を送信することができます。 RADIUSクライアントは、WWW-AuthenticateヘッダのドメインディレクティブのURIの引用された、スペース区切りのリストにそれらを置きます。一緒にダイジェスト・レルムで、リスト中のURIは、いくつかのHTTP形式のプロトコルのために（[RFC2617]、セクション3.2.1を参照）保護空間を定義します。この属性は、アクセスチャレンジおよびアカウンティング要求パケットで使用されなければなりません。ダイジェスト・ドメインの長さ3のために119を入力します
Text This attribute consists of a single URI that defines a protection space component.
テキストこの属性は、保護空間のコンポーネントを定義する単一のURIで構成されています。
Description This attribute is sent by a RADIUS server in order to notify the RADIUS client whether it has accepted a nonce. If the nonce presented by the RADIUS client was stale, the value is 'true' and is 'false' otherwise. The RADIUS client puts the content of this attribute into a stale directive of the WWW-Authenticate header in the HTTP-style response to the request it wants to authenticate. The attribute MUST only be used in Access-Challenge packets. Type 120 for Digest-Stale Length 3 Text The attribute has either the value 'true' or 'false' (both values without surrounding quotes).
説明この属性は、それがnonceを受け入れたかどうかをRADIUSクライアントに通知するために、RADIUSサーバによって送信されます。 RADIUSクライアントによって提示されたnonceが古くなった場合は、値が「真」であるとそうでない場合は「false」です。 RADIUSクライアントは、それが認証したい要求にHTTP形式の応答におけるWWW-Authenticateヘッダの古いディレクティブには、この属性の内容を置きます。属性は、アクセスチャレンジパケットで使用されなければなりません。属性が値「真」または「偽」（引用符を囲むことなく、両方の値）のいずれかを有するダイジェスト古い長3テキスト120を入力します。
Description This attribute is used to allow the generation of an Authentication-Info header, even if the HTTP-style response's body is required for the calculation of the rspauth value. It SHOULD be used in Access-Accept packets if the required quality of protection (qop) is 'auth-int'.
説明この属性は、HTTP形式のレスポンスのボディがrspauth値の計算のために必要な場合でも、認証-Infoヘッダーの生成を可能にするために使用されます。保護（QOP）の必要な品質は "のauth-int型である場合は、接続許可パケットで使用する必要があります。
This attribute MUST NOT be sent if the qop parameter was not
specified or has a value of 'auth' (in this case, use Digest-
Response-Auth instead).
The Digest-HA1 Attribute MUST only be sent by the RADIUS server or processed by the RADIUS client if at least one of the following conditions is true:
ダイジェスト-HA1属性のみRADIUSサーバによって送信されるか、以下の条件の少なくともいずれかに該当する場合、RADIUSクライアントによって処理しなければなりません。
+ The Digest-Algorithm Attribute's value is 'MD5-sess' or 'AKAv1-MD5-sess'.
+ダイジェスト・アルゴリズムの属性の値は「MD5-SESの」または「AKAv1-MD5-のSES」です。
+ IPsec is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see Section 8).
+ IPsecはIPsecの持つRADIUSクライアントとRADIUSサーバ間のトラフィックを保護するように構成されている（セクション8を参照）。
This attribute MUST only be used in Access-Accept packets.
この属性のみで使用する必要がありますAccess-Acceptパケット。
Type 121 for Digest-HA1 Length >= 3 Text This attribute contains the hexadecimal representation of H(A1) as described in [RFC2617], Sections 3.1.3, 3.2.1, and 3.2.2.2.
ダイジェスト-HA1長さ> = 3テキスト[RFC2617]に記載されているように、この属性は、H（A1）の16進表現が含まれ、セクション3.1.3、3.2.1および3.2.2.2 121を入力します。
Description This attribute is used for the authorization of SIP messages. The SIP-AOR Attribute identifies the URI, the use of which must be authenticated and authorized. The RADIUS server uses this attribute to authorize the processing of the SIP request. The SIP-AOR can be derived from, for example, the To header field in a SIP REGISTER request (user under registration), or the From header field in other SIP requests. However, the exact mapping of this attribute to SIP can change due to new developments in the protocol. This attribute MUST only be used when the RADIUS client wants to authorize SIP users and MUST only be used in Access-Request packets. Type 122 for SIP-AOR Length >= 3 Text The syntax of this attribute corresponds either to a SIP URI (with the format defined in [RFC3261] or a tel URI (with the format defined in [RFC3966]).
説明この属性は、SIPメッセージの認証に使用されます。 SIP-AOR属性は、URIを特定の使用が認証され、許可されなければなりません。 RADIUSサーバは、SIP要求の処理を許可するために、この属性を使用しています。 SIP-AORは、SIP REGISTERリクエスト（登録ユーザ下）のフィールドをヘッダには、例えば、由来する、または他のSIP要求のヘッダフィールドから得ることができます。しかし、SIPにこの属性の正確なマッピングが原因プロトコルでの新たな発展に変更することができます。この属性は、RADIUSクライアントは、SIPユーザーを認可したい場合にのみ使用されなければならないだけのAccess-Requestパケットで使用する必要があります。 SIP-AOR長さ> = 3テキストの122を入力し、この属性の構文は、[RFC3261]またはTEL [RFC3966]で定義されたフォーマットを有するURI（）で定義された形式で（SIP URIのいずれかに相当します。
The SIP-AOR Attribute holds the complete URI, including
parameters and other parts. It is up to the RADIUS server as
to which components of the URI are regarded in the
authorization decision.
This document defines support for Digest Authentication in RADIUS. A companion document "Diameter Session Initiation Protocol (SIP) Application" [RFC4740] defines support for Digest Authentication in Diameter, and addresses compatibility issues between RADIUS and Diameter.
このドキュメントでは、RADIUSでのダイジェスト認証のサポートを定義します。コンパニオン文書「直径セッション開始プロトコル（SIP）アプリケーション」[RFC4740]は、直径がダイジェスト認証のためのサポートを定義し、RADIUSと直径との間の互換性の問題に対処します。
The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity.
以下の表は、属性パケットの種類のもので、どのような量で見出されてもよいためのガイドを提供します。
Access- Access- Access- Access- Acct-Request Accept Reject Challenge Req # Attribute 0-1 0 0 0 0-1 1 User-Name 0-1 0 0 1 0 24 State [4] 1 1 1 1 0-1 80 Message-Authenticator 0-1 0 0 0 0 103 Digest-Response 0-1 0 0 1 0-1 104 Digest-Realm 0-1 0 0 1 0 105 Digest-Nonce 0 0-1 0 0 0 106 Digest-Response-Auth [1][2] 0 0-1 0 0 0 107 Digest-Nextnonce 1 0 0 0 0-1 108 Digest-Method 0-1 0 0 0 0-1 109 Digest-URI 0-1 0 0 0+ 0-1 110 Digest-Qop 0-1 0 0 0-1 0-1 111 Digest-Algorithm [3] 0-1 0 0 0 0 112 Digest-Entity-Body-Hash 0-1 0 0 0 0 113 Digest-CNonce 0-1 0 0 0 0 114 Digest-Nonce-Count 0-1 0 0 0 0-1 115 Digest-Username 0-1 0 0 0-1 0 116 Digest-Opaque 0+ 0+ 0 0+ 0+ 117 Digest-Auth-Param 0-1 0 0 0 0 118 Digest-AKA-Auts 0 0 0 0+ 0+ 119 Digest-Domain 0 0 0 0-1 0 120 Digest-Stale 0 0-1 0 0 0 121 Digest-HA1 [1][2] 0-1 0 0 0 0 122 SIP-AOR
Access- Access- Access- Access-アカウンティング - 要求は、チャレンジ必須＃項目0-1 0 0 0-1 1ユーザ名0-1 0 0 1 0 24ステート[4] 1 1 1 1 0-1 80を受け入れ拒否しますメッセージ認証0-1 0 0 0 0 103ダイジェストレスポンス0-1 0 0 1 0-1 104ダイジェストレルム0-1 0 0 1 0 105ダイジェストノンス0 0-1 0 0 106ダイジェスト対応 - AUTH [1] [2] 0 0-1 0 0 107ダイジェストNextnonce 1 0 0 0 0-1 108ダイジェストメソッド0-1 0 0 0-1 109ダイジェスト-URI 0-1 0 0 0 0+ -1 110ダイジェストQOP 0-1 0 0-1 0-1 111ダイジェストアルゴリズム[3] 0 0 0 0 112 0-1ダイジェストエンティティボディ・ハッシュ0-1 0 0 0 0 113ダイジェストCNonce 0 0 0 0 114 0-1ダイジェストノンス・カウント0-1 0 0 0-1 115ダイジェストユーザ名0-1 0 0-1 0 116ダイジェスト不透明0+ 0+ 0 0+ 0+ 117ダイジェスト-auth-のParam 0-1 0 0 0 0 118ダイジェストAKA-AUTS 0 0 0+ 0+ 119ダイジェストドメイン0 0 0-1 0 120ダイジェスト古い0 0-1 0 0 121ダイジェスト-HA1 [1] [2] 0-1 0 0 0 0 122 SIP-AOR
The following table defines the meaning of the above table entries.
次の表は、上記テーブルエントリの意味を定義します。
0 This attribute MUST NOT be present in the packet. 0+ Zero or more instances of this attribute MAY be present in the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet.
0この属性は、パケット内に存在してはなりません。 0+この属性のゼロ以上のインスタンスがパケットに存在してもよいです。この属性の0-1ゼロまたは1つのインスタンスがパケットに存在してもよいです。
[Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if Digest-Qop is 'auth-int'.
ダイジェスト-HA1は、ダイジェストQOP 'はAUTH-INT' がある場合、ダイジェスト・レスポンス認証の代わりに使用しなければならない[注1]。
[Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if Digest-Qop is 'auth'.
[注2]ダイジェストQOPが「認証」である場合、ダイジェスト・レスポンス認証ではなくダイジェスト-HA1を用いなければなりません。
[Note 3] If Digest-Algorithm is missing, 'MD5' is assumed.
[注3]ダイジェストアルゴリズムがない場合、「MD5」が想定されます。
[Note 4] An Access-Challenge MUST contain a State attribute, which is copied to the subsequent Access-Request. A server receiving an Access-Request that contains a State attribute MUST respond with either an Access-Accept or an Access-Reject; the server MUST NOT respond with an Access-Challenge.
アクセスチャレンジは、後続のアクセス要求にコピーされている状態の属性を含まなければならない[注4]。アクセス-受け入れるか、またはアクセスが拒否のいずれかで応じなければなりませんState属性が含まれているアクセス要求を受信するサーバ。サーバーはアクセスチャレンジで応答してはなりません。
This is an example selected from the traffic between a softphone (A), a Proxy Server (B), and an example.com RADIUS server (C). The communication between the Proxy Server and a SIP Public Switched Telephone Network (PSTN) gateway is omitted for brevity. The SIP messages are not shown completely.
これは、ソフトフォン（A）、プロキシサーバー（B）、およびexample.com RADIUSサーバ（C）間のトラフィックから選択例です。プロキシサーバとSIPパブリック間の通信は、電話網（PSTN）ゲートウェイを簡潔にするために省略されているスイッチ。 SIPメッセージが完全に表示されません。
The password of user '12345678' is 'secret'. The shared secret between the RADIUS client and server is 'secret'. To ease testing, only the last byte of the RADIUS authenticator changes between requests. In a real implementation, this would be a serious flaw.
ユーザーのパスワード「12345678」は「秘密」です。 RADIUSクライアントとサーバ間の共有秘密は、「秘密」です。テスト、要求間のRADIUS認証の変更の最後のバイトを容易にするために。実際の実装では、これは重大な欠陥になります。
A->B
A-> B
INVITE sip:97226491335@example.com SIP/2.0 From: <sip:12345678@example.com> To: <sip:97226491335@example.com>
INVITE SIP：97226491335@example.com SIP / 2.0から：<SIP：12345678@example.com>宛先：<SIP：97226491335@example.com>
B->A
B-> A
SIP/2.0 100 Trying
SIP / 2.0 100試行
B->C
B-> C
Code = Access-Request (1) Packet identifier = 0x7c (124) Length = 97 Authenticator = F5E55840E324AA49D216D9DBD069807C NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = INVITE Digest-URI = sip:97226491335@example.com Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B
コード=アクセス要求（1）パケット識別子= 0x7c（124）の長さ= 97認証= F5E55840E324AA49D216D9DBD069807C NAS-IPアドレス= 192.0.2.38 NASポート= 5ユーザー名= 12345678ダイジェスト-METHOD = INVITEダイジェスト-URI = SIP ：97226491335@example.comメッセージ認証= 7600D5B0BDC33987A60D5C6167B28B3B
C->B
C-> B
Code = Access-challenge (11) Packet identifier = 0x7c (124) Length = 72 Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D Digest-Nonce = 3bada1a0 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3
コード=アクセスチャレンジ（11）パケット識別子= 0x7c（124）長さ= 72認証= EBE20199C26EFEAD69BF8AB0E786CA4Dダイジェストノンス= 3bada1a0ダイジェストレルム= example.comダイジェストQOP = AUTHダイジェストアルゴリズム= MD5メッセージ・オーセンティケータ= 5DA18ED3BBC9513DCBDE0A37F51B7DE3
B->A
B-> A
SIP/2.0 407 Proxy Authentication Required Proxy-Authenticate: Digest realm="example.com" ,nonce="3bada1a0",qop=auth,algorithm=MD5 Content-Length: 0
SIP / 2.0 407プロキシ認証が必要プロキシ認証：ダイジェストレルム= "example.com"、ノンス= "3bada1a0"、QOP = AUTH、アルゴリズム= MD5のContent-Length：0
A->B
A-> B
ACK sip:97226491335@example.com SIP/2.0
ACKのSIP：97226491335@example.com SIP / 2.0
A->B
A-> B
INVITE sip:97226491335@example.com SIP/2.0 Proxy-Authorization: Digest nonce="3bada1a0" ,realm="example.com" ,response="756933f735fcd93f90a4bbdd5467f263" ,uri="sip:97226491335@example.com",username="12345678" ,qop=auth,algorithm=MD5 ,cnonce="56593a80,nc="00000001"
=、ユーザ名97226491335@example.com SIP / 2.0プロキシ認証：：ダイジェストノンス= "3bada1a0"、レルム= "example.com"、応答= "756933f735fcd93f90a4bbdd5467f263"、URI = "97226491335@example.com SIP" SIP INVITE "12345678"、QOP = AUTH、アルゴリズム= MD5、cnonce = "56593a80、NC =" 00000001"
From: <sip:12345678@example.com> To: <sip:97226491335@example.com>
From：<SIP：12345678@example.com>宛先：<SIP：97226491335@example.com>
B->C
B-> C
Code = Access-Request (1) Packet identifier = 0x7d (125) Length = 221 Authenticator = F5E55840E324AA49D216D9DBD069807D NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = INVITE Digest-URI = sip:97226491335@example.com Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Digest-CNonce = 56593a80 Digest-Nonce = 3bada1a0 Digest-Nonce-Count = 00000001 Digest-Response = 756933f735fcd93f90a4bbdd5467f263 Digest-Username = 12345678 SIP-AOR = sip:12345678@example.com Message-Authenticator = B6C7F7F8D11EF261A26933D234561A60
コード=アクセス要求（1）パケット識別子= 0x7d（125）長さ= 221認証= F5E55840E324AA49D216D9DBD069807D NAS-IPアドレス= 192.0.2.38 NASポート= 5ユーザー名= 12345678ダイジェスト-METHOD =ダイジェスト-URI = SIPのINVITE ：97226491335@example.comダイジェスト・レルム= example.comダイジェストQOP = AUTHダイジェストアルゴリズム= MD5ダイジェスト-CNonce = 56593a80ダイジェスト・ナンス= 3bada1a0ダイジェスト・ナンス・カウント= 12345678 = 00000001ダイジェスト・レスポンス= 756933f735fcd93f90a4bbdd5467f263ダイジェスト - ユーザー名SIP-AOR = SIP：12345678@example.comメッセージ認証= B6C7F7F8D11EF261A26933D234561A60
C->B
C-> B
Code = Access-Accept (2) Packet identifier = 0x7d (125) Length = 72 Authenticator = FFDD74D6470D21CB6FC4D6056BE245D2 Digest-Response-Auth = f847de948d12285f8f4199e366f1af21 Message-Authenticator = 7B76E2F10A7067AF601938BF13B0A62E
コード=アクセス - 受け入れ（2）パケット識別子= 0x7d（125）長さ= 72認証= FFDD74D6470D21CB6FC4D6056BE245D2ダイジェストレスポンス-AUTH = f847de948d12285f8f4199e366f1af21のメッセージ認証= 7B76E2F10A7067AF601938BF13B0A62E
B->A
B-> A
SIP/2.0 180 Ringing
SIP / 2.0 180リンギング
B->A
B-> A
SIP/2.0 200 OK
SIP / 2.0 200 OK
A->B
A-> B
ACK sip:97226491335@example.com SIP/2.0
ACKのSIP：97226491335@example.com SIP / 2.0
A second example shows the traffic between a web browser (A), a web server (B), and a RADIUS server (C).
第二の例は、ウェブブラウザ（A）、ウェブサーバ（B）、およびRADIUSサーバ（C）間のトラフィックを示します。
A->B
A-> B
GET /index.html HTTP/1.1
GET /index.htmlがHTTP / 1.1
B->C
B-> C
Code = Access-Request (1) Packet identifier = 0x7e (126) Length = 68 Authenticator = F5E55840E324AA49D216D9DBD069807E NAS-IP-Address = 192.0.2.38 NAS-Port = 5 Digest-Method = GET Digest-URI = /index.html Message-Authenticator = 690BFC95E88DF3B185F15CD78E469992
コード=アクセス要求（1）パケット識別子= 0x7Eを（126）長さ= 68認証= F5E55840E324AA49D216D9DBD069807E NAS-IPアドレス= 192.0.2.38 NASポート= 5ダイジェストMETHOD = GETダイジェスト-URI = /index.htmlがMessage-オーセンティケータ= 690BFC95E88DF3B185F15CD78E469992
C->B
C-> B
Code = Access-challenge (11) Packet identifier = 0x7e (126) Length = 72 Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E Digest-Nonce = a3086ac8 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A
コード=アクセスチャレンジ（11）パケット識別子= 0x7Eを（126）長さ= 72認証= 2EE5EB01C02C773B6C6EC8515F565E8Eダイジェストノンス= a3086ac8ダイジェストレルム= example.comダイジェストQOP = AUTHダイジェストアルゴリズム= MD5メッセージ・オーセンティケータ= 646DB2B0AF9E72FFF2CF7FEB33C4952A
B->A
B-> A
HTTP/1.1 401 Authentication Required WWW-Authenticate: Digest realm="example.com", nonce="a3086ac8",qop=auth,algorithm=MD5 Content-Length: 0
HTTP / 1.1 401認証が必要WWW認証：ダイジェスト分野= "example.com"、ナンス= "a3086ac8"、QOP = AUTH、アルゴリズム= MD5のContent-Length：0
A->B
A-> B
GET /index.html HTTP/1.1 Authorization: Digest = algorithm=MD5,qop=auth,nonce="a3086ac8" ,nc="00000001",cnonce="56593a80" ,realm="example.com" ,response="a4fac45c27a30f4f244c54a2e99fa117" ,uri="/index.html",username="12345678"
GET /index.htmlがHTTP / 1.1認証：ダイジェスト=アルゴリズム= MD5、QOP = AUTH、ナンス= "a3086ac8"、NC = "00000001"、cnonce = "56593a80"、領域= "example.com"、レスポンス= "a4fac45c27a30f4f244c54a2e99fa117 "URI =" / index.htmlを」、ユーザ名= "12345678"
B->C
B-> C
Code = Access-Request (1) Packet identifier = 0x7f (127) Length = 176 Authenticator = F5E55840E324AA49D216D9DBD069807F NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = GET Digest-URI = /index.html Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Digest-CNonce = 56593a80 Digest-Nonce = a3086ac8 Digest-Nonce-Count = 00000001 Digest-Response = a4fac45c27a30f4f244c54a2e99fa117 Digest-Username = 12345678 Message-Authenticator = 237D85C1478C70C67EEAF22A9C456821
コードは=アクセス要求（1）パケット識別子=から0x7f（127）長さ= 176認証= F5E55840E324AA49D216D9DBD069807F NAS-IPアドレス= 192.0.2.38 NASポート= 5ユーザー名= 12345678ダイジェスト-METHOD = GETダイジェスト-URI = / index.htmlをダイジェスト・レルム= example.comダイジェストQOP = AUTHダイジェストアルゴリズム= MD5ダイジェスト-CNonce = 56593a80ダイジェスト・ナンス= a3086ac8ダイジェスト・ナンス・カウント= 00000001ダイジェスト・レスポンス= a4fac45c27a30f4f244c54a2e99fa117ダイジェストユーザ名= 12345678メッセージ認証= 237D85C1478C70C67EEAF22A9C456821
C->B
C-> B
Code = Access-Accept (2) Packet identifier = 0x7f (127) Length = 72 Authenticator = 6364FA6ED66012847C05A0895607C694 Digest-Response-Auth = 08c4e942d1d0a191de8b3aa98cd35147 Message-Authenticator = 43795A3166492AD2A890AD57D5F97D56
コード=アクセス - 受け入れ（2）パケット識別子=から0x7f（127）長さ= 72認証= 6364FA6ED66012847C05A0895607C694ダイジェストレスポンス-AUTH = 08c4e942d1d0a191de8b3aa98cd35147メッセージ認証= 43795A3166492AD2A890AD57D5F97D56
B->A
B-> A
HTTP/1.1 200 OK ...
HTTP / 1.1 200 OK ...
<html> ...
<HTML> ...
The following values from the RADIUS Attribute Types number space were assigned in [RFC4590]. This document requests that the values in the table below be entered within the existing registry.
RADIUS属性の種類数のスペースから次の値が[RFC4590]に割り当てられました。この文書では、次の表の値は、既存のレジストリ内に入力することを要求します。
Attribute #
--------------- ----
Digest-Response 103
Digest-Realm 104
Digest-Nonce 105
Digest-Response-Auth 106
Digest-Nextnonce 107
Digest-Method 108
Digest-URI 109
Digest-Qop 110
Digest-Algorithm 111
Digest-Entity-Body-Hash 112
Digest-CNonce 113
Digest-Nonce-Count 114
Digest-Username 115
Digest-Opaque 116
Digest-Auth-Param 117
Digest-AKA-Auts 118
Digest-Domain 119
Digest-Stale 120
Digest-HA1 121
SIP-AOR 122
The RADIUS extensions described in this document enable RADIUS to transport the data that is required to perform a digest calculation. As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see [RFC2617], Section 4) in addition to RADIUS security vulnerabilities described in [RFC2865], Section 8, and [RFC3579], Section 4.
本書では説明RADIUS拡張は、ダイジェスト計算を実行するために必要なデータを転送するためにRADIUSを可能にします。結果として、RADIUSは、[RFC2865]に記載されたRADIUSセキュリティの脆弱性、セクション8、および[RFC3579]、セクション4に加えて、（[RFC2617]、セクション4を参照）HTTPダイジェストの脆弱性を継承します。
An attacker compromising a RADIUS client or proxy can carry out man-in-the-middle attacks even if the paths between A, B and B, C (Figure 2) have been secured with TLS or IPsec.
RADIUSクライアントまたはプロキシを損なう攻撃者はA、BとBとの間のパスは、C（図2）は、TLSやIPsecで保護されていてもman-in-the-middle攻撃を行うことができます。
The RADIUS server MUST check the Digest-Realm Attribute it has received from a client. If the RADIUS client is not authorized to serve HTTP-style clients of that realm, it might be compromised.
ダイジェスト・レルムをチェックしなければなりませんRADIUSサーバは、クライアントから受信した属性。 RADIUSクライアントは、そのレルムのHTTPスタイルのクライアントにサービスを提供するために許可されていない場合、それは危険にさらされる可能性があります。
RADIUS clients implementing the extension described in this document may authenticate HTTP-style requests received over the Internet. As compared with the use of RADIUS to authenticate link-layer network access, attackers may find it easier to cover their tracks in such a scenario.
このドキュメントで説明する拡張機能を実装するRADIUSクライアントは、インターネット経由で受信したHTTPスタイルの要求を認証することができます。リンク層ネットワークアクセスを認証するためにRADIUSを使用することと比較すると、攻撃者は、簡単にこのようなシナリオで自分の曲をカバーするかもしれません。
An attacker can attempt a denial-of-service attack on one or more RADIUS servers by sending a large number of HTTP-style requests. To make simple denial-of-service attacks more difficult, the RADIUS server MUST check whether it has generated the nonce received from an HTTP-style client. This SHOULD be done statelessly. For example, a nonce could consist of a cryptographically random part and some kind of signature provided by the RADIUS client, as described in [RFC2617], Section 3.2.1.
攻撃者は、HTTPスタイルの要求を大量に送信することによって、1つまたは複数のRADIUSサーバ上のサービス拒否攻撃を試みることができます。シンプルなサービス拒否攻撃をより困難にするために、RADIUSサーバは、HTTP風のクライアントから受信したnonceを生成しているかどうかをチェックしなければなりません。これはステートレスに行われるべきです。 [RFC2617]に記載されているように、例えば、ナンスは、暗号的にランダムな部分とRADIUSクライアントによって提供される署名のいくつかの種類から成ることができ、セクション3.2.1。
The attributes described in this document are sent in cleartext. RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm attributes in Access-Challenge messages. A man in the middle can modify or remove those attributes in a bidding down attack, causing the RADIUS client to use a weaker authentication scheme than intended.
この文書で説明する属性はクリアテキストで送信されます。 RADIUSサーバは、ダイジェストQOPとダイジェスト・アルゴリズムはアクセスチャレンジメッセージに属性を含むべきです。真ん中の男は、RADIUSクライアントが意図したよりも弱い認証スキームを使用することを引き起こして、競り下げ攻撃でこれらの属性を変更したり、削除することができます。
The Message-Authenticator Attribute, described in [RFC3579], Section 3.2 MUST be included in Access-Request, Access-Challenge, Access-Reject, and Access-Accept messages that contain attributes described in this specification.
[RFC3579]で説明Message-Authenticatorアトリビュートは、3.2節では、アクセス要求、アクセスチャレンジに含まれなければならないアクセス拒否、および本明細書に記載された属性を含むメッセージにアクセス-受け入れます。
The Digest-HA1 Attribute contains no random components if the algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary attacks easier and enables replay attacks.
アルゴリズムは「MD5」または「AKAv1-MD5」の場合、ダイジェスト-HA1属性には、ランダムな要素が含まれていません。これは、オフライン辞書攻撃が容易になり、リプレイ攻撃を可能にします。
Some parameter combinations require the protection of RADIUS packets against eavesdropping and tampering. Implementations SHOULD try to determine automatically whether IPsec is configured to protect traffic between the RADIUS client and the RADIUS server. If this is not possible, the implementation checks a configuration parameter telling it whether IPsec will protect RADIUS traffic. The default value of this configuration parameter tells the implementation that RADIUS packets will not be protected.
いくつかのパラメータの組み合わせは、盗聴や改ざんに対するRADIUSパケットの保護を必要とします。実装は、IPsecはRADIUSクライアントとRADIUSサーバ間のトラフィックを保護するように構成されているかどうかを自動的に判断するようにしてください。これが不可能な場合、実装は、IPsecはRADIUSトラフィックを保護するかどうか、それを伝える構成パラメータをチェックします。この設定パラメータのデフォルト値は、RADIUSパケットが保護されません実装を伝えます。
HTTP-style clients can use TLS with server-side certificates together with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, too. TLS or IPsec secure the connection while Digest Authentication authenticates the user. The RADIUS transaction can be regarded as one leg on the path between the HTTP-style client and the HTTP-style server. To prevent RADIUS from representing the weak link, a RADIUS client receiving an HTTP-style request via TLS or IPsec could use an equally secure connection to the RADIUS server. There are several ways to achieve this, for example:
HTTPスタイルのクライアントは、HTTPダイジェスト認証と一緒にサーバー側の証明書を使用してTLSを使用することができます。代わりにTLSの、IPsecは、あまりにも、使用することができます。ダイジェスト認証は、ユーザーを認証しながら、TLSやIPsec接続を確保します。 RADIUSトランザクションは、HTTPスタイルのクライアントとHTTP形式のサーバー間のパス上の片足とみなすことができます。弱いリンクを表すからRADIUSを防ぐために、TLSやIPsec経由でHTTPスタイルの要求を受けたRADIUSクライアントは、RADIUSサーバにも同様に安全な接続を使用することができます。例えば、これを達成するには、いくつかの方法があります。
o The RADIUS client may reject HTTP-style requests received over TLS or IPsec.
O HTTPスタイルの要求を拒否することができるRADIUSクライアントはTLSやIPsec経由で受信しました。
o The RADIUS client may require that traffic be sent and received over IPsec.
O RADIUSクライアントは、トラフィックが送信され、IPsecの上で受信することを要求することができます。
RADIUS over IPsec, if used, MUST conform to the requirements described in [RFC3579], Section 4.2.
IPsecの上にRADIUSを使用する場合、セクション4.2、[RFC3579]で説明した要件に従わなければなりません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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, June 1999.
[RFC2617]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B.およびP.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]シンプソン、W.、 "PPPチャレンジハンドシェイク認証プロトコル（CHAP）"、RFC 1994、1996年8月。
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997.
[RFC2069]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、リーチ、P.、Luotonen、A.、シンク、E.、およびL.スチュワート、 "HTTPへの拡張：ダイジェストアクセス認証" 、RFC 2069、1997年1月。
[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002.
[RFC3310]ニエミ、A.、Arkko、J.、およびV. Torvinen、 "ハイパーテキスト転送プロトコル認証および鍵合意（AKA）を使用して（HTTP）ダイジェスト認証"、RFC 3310、2002年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、エド。、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4590] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 4590, July 2006.
[RFC4590] Sterman、B.、Sadolevsky、D.、シュワルツ、D.、ウィリアムズ、D.、およびW.ベック、 "ダイジェスト認証のためのRADIUS拡張"、RFC 4590、2006年7月。
[RFC4740] Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006.
[RFC4740]ガルシア - マーチン、M.編、Belinchon、M.、Pallares - ロペス、M.、カナーレス-ヴァレンズエラ、C.、およびK. Tammi、 "直径セッション開始プロトコル（SIP）アプリケーション"、RFC 4740 、2006年11月。
Appendix A - Changes from RFC 4590
付録A - RFC 4590からの変更点
This Appendix lists the major changes between [RFC4590] and this document. Minor changes, including style, grammar, spelling, and editorial changes are not mentioned here.
この付録では、[RFC4590]とこのドキュメント間の主な変更点を示します。スタイル、文法、スペル、および編集上の変更を含むマイナーチェンジが、ここでは言及されていません。
o The Table of Attributes (Section 5) now indicates that the Digest-Method Attribute is required within an Access-Request. Also, an entry has been added for the State attribute. The table also includes entries for Accounting-Request messages. As noted in the examples, the User-Name Attribute is not necessary when requesting a nonce.
O属性（セクション5）の表は、現在ダイジェスト-method属性は、アクセス要求内で必要とされていることを示しています。また、エントリがState属性が追加されました。表には、アカウンティング要求メッセージのエントリが含まれています。実施例で述べたようにnonceを要求するとき、User-Name属性は不要です。
o Two errors in attribute assignment have been corrected within the IANA Considerations (Section 7). Digest-Response-Auth is assigned attribute 106, and Digest-Nextnonce is assigned attribute 107.
O属性の割り当てで2つのエラーがIANAの考慮事項（第7節）以内に修正されました。ダイジェスト応答-AUTHは、属性106が割り当てられ、ダイジェストNextnonceは、属性107が割り当てられます。
o Several errors in the examples section have been corrected.
O実施例の節にいくつかの誤りが修正されました。
Acknowledgments
謝辞
The authors would like to thank Mike McCauley for his help in working through the details of the examples.
著者は、例の詳細を通じて取り組んで彼の助けのためのマイク・マッコーリーに感謝したいと思います。
We would like to acknowledge Kevin McDermott (Cisco Systems) for providing comments and experimental implementation.
私たちは、コメントや実験的な実装を提供するためのケビン・マクダーモット（シスコシステムズ）を承認したいと思います。
Many thanks to all reviewers, especially to Miguel Garcia, Jari Arkko, Avi Lior, and Jun Wang.
特にミゲル・ガルシア、ヤリArkko、アビLIOR、および6月王へのすべてのレビューに感謝、。
Authors' Addresses
著者のアドレス
Baruch Sterman Kayote Networks P.O. Box 1373 Efrat 90435 Israel
バルークSterman Kayoteネットワーク私書箱ボックス1373 Efrat 90435イスラエル
EMail: baruch@kayote.com
メールアドレス：baruch@kayote.com
Daniel Sadolevsky SecureOL, Inc. Jerusalem Technology Park P.O. Box 16120 Jerusalem 91160 Israel
ダニエルSadolevsky SecureOL、株式会社エルサレムテクノロジーパークの私書箱ボックス16120エルサレム91160イスラエル
EMail: dscreat@dscreat.com
メールアドレス：dscreat@dscreat.com
David Schwartz Kayote Networks P.O. Box 1373 Efrat 90435 Israel
デビッド・シュワルツKayoteネットワーク私書箱ボックス1373 Efrat 90435イスラエル
EMail: david@kayote.com
メールアドレス：david@kayote.com
David Williams Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park NC 27709 USA
デビッド・ウィリアムズシスコシステムズ7025キットクリーク道路私書箱14987リサーチトライアングルパークNC 27709 USA箱
EMail: dwilli@cisco.com
メールアドレス：dwilli@cisco.com
Wolfgang Beck Deutsche Telekom AG Deutsche Telekom Allee 7 Darmstadt 64295 Germany
ヴォルフガング・ベックドイツテレコム・アーゲーのドイツテレコムアリー7 64295ダルムシュタットドイツ
EMail: beckw@t-systems.com
メールアドレス：beckw@t-systems.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。