[要約] RFC 4590は、RADIUS拡張機能であるダイジェスト認証に関する規格です。このRFCの目的は、RADIUSサーバとクライアント間でのセキュアな認証を提供することです。
Network Working Group B. Sterman
Request for Comments: 4590 Kayote Networks
Category: Standards Track D. Sadolevsky
SecureOL, Inc.
D. Schwartz
Kayote Networks
D. Williams
Cisco Systems
W. Beck
Deutsche Telekom AG
July 2006
RADIUS Extension for Digest Authentication
ダイジェスト認証用のRADIUS拡張
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 ....................................................2
1.1. Terminology ................................................2
1.2. Motivation .................................................3
1.3. Overview ...................................................4
2. Detailed Description ............................................6
2.1. RADIUS Client Behavior .....................................6
2.1.1. Credential Selection ................................6
2.1.2. Constructing an Access-Request ......................6
2.1.3. Constructing an Authentication-Info Header ..........7
2.1.4. Failed Authentication ...............................8
2.1.5. Obtaining Nonces ....................................9
2.2. RADIUS Server Behavior .....................................9
2.2.1. General Attribute Checks ............................9
2.2.2. Authentication .....................................10
2.2.3. Constructing the Reply .............................11
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 ...................................14
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 ............................................22
6. Examples .......................................................23
7. IANA Considerations ............................................27
8. Security Considerations ........................................27
8.1. Denial of Service .........................................28
8.2. Confidentiality and Data Integrity ........................28
9. Acknowledgements ...............................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................30
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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スタイル」という用語は、[RFC2617]で説明されているように、HTTPのようなヘッダーを使用し、HTTPダイジェスト認証を使用するプロトコルを示します。例は、HTTPとセッション開始プロトコル（SIP）です。
NAS Network Access Server, the RADIUS client.
RADIUSクライアントであるNASネットワークアクセスサーバー。
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.
再生攻撃を防ぐために使用される予測不可能な値。NonCeジェネレーターは、暗号化メカニズムを使用して、状態を維持せずに認識できる非能力を生成する場合があります。
protection space HTTP-style protocols differ in their definition of the protection space. For HTTP, it is defined as the combination of 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の場合、レルムストリングのみが保護スペースを定義します。
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（セッション開始プロトコル）要求に対する応答を生成する論理エンティティです。
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を参照）、追加の認証と暗号化メカニズムは、輸送層のセキュリティ（TLS）[RFC4346]および安全なMIME（S/MIME）を含むSIP [RFC3261]で定義されています。[RFC3851]。ただし、SIP実装ではDigest認証サポートが必須であり、SIP UAがプロキシサーバーに認証するためのDigest Authenticationが好ましい方法です。Digest認証は、他のプロトコルでも使用されます。
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]や直径[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 [SIP-APP] defines support for Digest Authentication within Diameter.
このドキュメントでは、この認証方法を使用して、SIP、HTTP、およびその他のHTTPスタイルプロトコルで使用するためのダイジェスト認証のサポートを有効にするために、RADIUSプロトコルの拡張を定義します。認証とキー契約（別名）[RFC3310]などのダイジェストメカニズムのサポートもサポートされています。コンパニオンドキュメント[SIP-APP]は、直径内の消化認証のサポートを定義します。
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 Digestは、サーバー上のリソースにアクセスするというクライアントの要求を認証するために使用されるチャレンジ応答プロトコルです。図1は、単一のHTTPダイジェストトランザクションを示しています。
HTTP/SIP..
+------------+ (1) +------------+
| |--------->| |
| HTTP-style | (2) | HTTP-style |
| client |<---------| server |
| | (3) | |
| |--------->| |
| | (4) | |
| |<---------| |
+------------+ +------------+
Figure 1: Digest operation without RADIUS
図1：半径のない消化操作
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 re-transmits 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）なしでリクエストを送信した場合、サーバーはノンセを含むエラー応答（2）で返信します。クライアントは、リクエストの一部から、サーバーから受け取ったNonceから、および共有された秘密から暗号化ダイジェストを作成します。クライアントはリクエスト（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 CHAP algorithm is not compatible with HTTP Digest.
ローカルユーザーデータベースを維持する代わりに、サーバーはRADIUSを使用して集中ユーザーデータベースにアクセスできます。ただし、RADIUS [RFC2865]には、HTTPダイジェスト認証のサポートは含まれていません。RADIUSクライアントは、HTTPスタイルのクライアントからパスワードを受信しないため、ユーザーパスワード属性を使用できません。[RFC1994]に記載されているチャップチャレンジおよびチャップパスワードの属性も、chapアルゴリズムがHTTPダイジェストと互換性がないため、適していません。
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.
このドキュメントでは、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.
Digestアルゴリズムで必要なNoncesは、RADIUSサーバーによって生成されます。RADIUSクライアントでそれらを生成すると、往復が節約されますが、セキュリティと運用上の問題が導入されます。いくつかのダイジェストアルゴリズム（例えば、別名[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サーバーへの認証を定めるシナリオを示しています。エンティティAとBはHTTPまたはSIPを使用して通信し、エンティティBとCは半径を使用して通信します。
HTTP/SIP RADIUS
HTTP/SIP半径
+-----+ (1) +-----+ +-----+
| |==========>| | (2) | |
| | | |---------->| |
| | | | (3) | |
| | (4) | |<----------| |
| |<==========| | | |
| | (5) | | | |
| |==========>| | | |
| A | | B | (6) | C |
| | | |---------->| |
| | | | (7) | |
| | | |<----------| |
| | (8) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
====> HTTP/SIP
----> RADIUS
Figure 2: HTTP Digest over RADIUS
図2：半径上のHTTPダイジェスト
The entities have the following roles:
エンティティには次の役割があります。
A: HTTP client / SIP UA
A：HTTPクライアント / SIP UA
B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS}
acting also as a RADIUS NAS
C: RADIUS server The following messages are sent in this scenario:
C：RADIUSサーバーこのシナリオで次のメッセージが送信されます。
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は、承認ヘッダー（ステップ1）なしでb an http/sipリクエストを送信します。Bは、新しく定義されたダイジェストメソッドとダイジェスト-URI属性を使用してアクセスリケストパケットを送信しますが、RADIUSサーバーC（ステップ2）にダイジェストノンセ属性がありません。CはNONCEを選択し、アクセスチャレンジで応答します（ステップ3）。このAccess-Challengeには、Digest属性が含まれています。そこからBは、HTTP/SIPを構築するために値を取得します」（プロキシ）承認が必要な「応答」が必要です。bこの応答はA（ステップ4）に送信します。資格情報を使用してリクエストを再送信します（ステップ5）。bはcにアクセス要求を送信します（ステップ6）。cは資格情報をチェックし、アクセスacceptまたはアクセス拒否で返信します（ステップ7）。Cの結果に応じて、BはAの要求を処理または拒否します。
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.
このドキュメントで説明されている属性は、ClearTextで送信されます。したがって、HTTPスタイルのクライアントから安全な接続（HTTPまたはSIP）を受け入れるRADIUSクライアントは、HTTPスタイルのクライアントがRADIUS交換中にクリアで送信することによって意図的に保護されている情報をもたらす可能性があります。
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サーバーにゼロまたは正確に1つの資格情報を送信する必要があります。RADIUSクライアントは、レルムディレクティブがローカルで構成されたレルムと一致する場合、（プロキシ - ）認証ヘッダーの資格情報を選択する必要があります。
If a matching (Proxy-)Authorization header is present and contains HTTP Digest information, the RADIUS client checks the 'nonce' parameter.
マッチング（プロキシ - ）認証ヘッダーが存在し、HTTPダイジェスト情報が含まれている場合、RADIUSクライアントは「NonCE」パラメーターをチェックします。
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アクセスリケストパケットに入れます。「応答」指令をダイジェスト応答属性に入れ、領域、ノンセ、ダイジェストリ、QOP、アルゴリズム、CNONCE、NC、ユーザー名、および不透明なディレクティブをそれぞれのダイジェストリアルム、ダイジェストノンセ、ダイジェストウリに入れます、Digest-qop、Digest-Algorithm、Digest-Cnonce、Digest-Nonce-Count、Digest-Username、Digest-Opaque属性。RADIUSクライアントは、リクエストメソッドをダイジェストメソッド属性に入れます。
Due to syntactic requirements, HTTP-style protocols have to escape with backslash all quote and backslash characters in contents of HTTP Digest directives. When translating directives into RADIUS attributes, the RADIUS client only removes the surrounding quotes where present. 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]、セクション3.2.1で説明されているようにH（エンティティボディ）を計算し、結果をダイジェストエンティティボディに置きます - ハッシュ属性。
The RADIUS client adds a Message-Authenticator attribute, defined in [RFC3579], and sends the Access-Request packet to the RADIUS server.
RADIUSクライアントは、[RFC3579]で定義されているメッセージAuthenticator属性を追加し、RADIUSサーバーにアクセスリケストパケットを送信します。
The RADIUS server processes the packet and responds with an Access-Accept or an Access-Reject.
RADIUSサーバーはパケットを処理し、Access-AcceptまたはAccess-rejectで応答します。
After having received an Access-Accept from the RADIUS server, the RADIUS client constructs an Authentication-Info header:
RADIUSサーバーからアクセスacceptを受け取った後、RADIUSクライアントは認証-INFOヘッダーを構築します。
o If the Access-Accept packet contains a Digest-Response-Auth attribute, the RADIUS client checks the Digest-Qop attribute:
o Access-AcceptパケットにDigest-Response-Auth属性が含まれている場合、RADIUSクライアントはDigest-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.
* Digest-QOP属性の値が「認証」または指定されていない場合、RADIUSクライアントは、Digest-Response-Auth属性のコンテンツをHTTPスタイル応答の認証INFOヘッダーの「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).
* Digest-QOP属性の値が「auth-int」である場合、RADIUSクライアントはアクセスacceptパケットを無視し、アクセス - rejectパケットを受信したかのように動作します（Digest-Response-authは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:
o Access-AcceptパケットにDigest-HA1属性が含まれている場合、RADIUSクライアントは、承認したいHTTPスタイルの要求の承認ヘッダーに「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クライアントはDigest-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」であり、少なくとも次の条件の1つが真である場合、RADIUSクライアントはHTTPスタイルの応答の「RSPAuth」指令の内容を計算します。
+ The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5-sess'.
+ アルゴリズムディレクティブの値は、「MD5-SESS」または「AKAV1-MD5-SESS」です。
+ 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を参照）。
It 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.
HTTPスタイルの応答メッセージを作成し、このメッセージの本体のハッシュを計算します。対応するAccess-Requestパケットの結果とDigest-URI属性の値を使用して、H（A2）計算を実行します。「RSPAuth」値の計算を完了するには、対応するAccess-RequestおよびDigest-Ha1属性の値のDigest-Nonce、Digest-Nonce-Count、Digest-Cnonce、およびDigest-QOP値を必要とします。
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.
o Access-AcceptパケットにDigest-Response-AuthもDigest-HA1属性も含まれていない場合、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サーバーがAccess-AcceptパケットにDigest-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クライアントが、ローカルで構成されたレルム値に一致する（プロキシ - ）承認ヘッダーなしでHTTPスタイルの要求を受け取った場合、新しいNonCEを取得し、（プロキシ - ）認証ヘッダーを含むエラー応答（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 directive 'stale' and the digest directives derived from the Digest-* attributes.
RADIUSクライアントが、ダイジェストノンセ属性を含むアクセスリケストに応じてアクセスチャレンジパケットを受信した場合、RADIUSサーバーはNonCEを受け入れませんでした。Digest-Stale属性がアクセスチャレンジに存在し、「True」の値（周囲の引用符なし）がある場合、RADIUSクライアントは、www-/proxy-authenticateヘッダーを含むエラー応答（401または407）を送信します。ディレクティブ「古い」とダイジェスト指令は、ダイジェスト - *属性から派生しました。
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クライアントには、Noncesを取得する2つの方法があります。以前に受信したアクセスacceptパケットのDigest-NextNonce属性で1つを受信したか、RADIUSサーバーに1つを要求します。後者を行うには、ダイジェストメソッドとダイジェスト-uri属性を含むが、ダイジェストノンス属性を含むアクセスリケストを送信します。アクセスリクエストパケットにメッセージを追加します（[rfc3579]を参照）属性を追加します。RADIUSサーバーはNONCEを選択し、Digest-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クライアントは、受信したDigest-NonceおよびDigest-RealM属性を使用して（プロキシ）認証ヘッダーを構築し、NonCeおよびRealmディレクティブを記入します。RADIUSサーバーは、NonCeを運ぶアクセスチャレンジにDigest-QOP、Digest-Algorithm、Digest-Domain、およびDigest-Opaque属性を送信できます。これらの属性が存在する場合、クライアントはそれらを使用する必要があります。
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 more Digest-Qop, and MAY add Digest-Domain or Digest-Opaque attributes to the Access-Challenge packet.
RADIUSサーバーが、Digest-MethodとDigest-URI属性を備えたAccess-Requestパケットを受信したが、Digest-Nonce属性がない場合、NonCeを選択します。NonceをDigest-Nonce属性に入れ、Radiusクライアントにアクセスチャレンジパケットに送信します。RADIUSサーバーは、Digest-RealM、Message-Authenticator（[RFC3579]を参照）を追加し、Digest-Algorithmと1つ以上のDigest-QOPを追加し、Access-ChallengeパケットにDigest-DomainまたはDigest-Opaque属性を追加する必要があります。
If the RADIUS server receives an Access-Request packet containing a Digest-Response attribute, it looks for the following attributes: 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.
RADIUSサーバーがDigest-Response属性を含むAccess-Requestパケットを受信した場合、次の属性を探します：Digest-Realm、Digest-Nonce、Digest-Method、Digest-Uri、Digest-Qop、Digest-Algorithm、Digest-USNAME。Digest-AlgorithmとDigest-QOPの含有量に応じて、Digest-Entity-Body-Hash、Digest-Cnonce、Digest-Aka-autsも探します。詳細については、[RFC2617]および[RFC3310]を参照してください。ダイジェストアルゴリズム属性が欠落している場合、「MD5」が想定されます。RADIUSサーバーがNONCEとともにDigest-Opaque属性を発行した場合、Access-Requestには一致するダイジェストオパク属性が必要です。
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サーバーは、Digest-RealM属性に記載されているレルムのユーザーにサービスを提供することをRADIUSクライアントが許可されているかどうかを確認する必要があります。RADIUSクライアントが承認されていない場合、RADIUSサーバーはアクセス拒否を送信する必要があります。RADIUSサーバーは、オペレーターに通知するようにイベントをログに記録する必要があり、この動作が管理アクションによってリセットされるまで、このクライアントからのすべての将来の要求に応じてアクセスrejectを送信するなどの追加アクションを実行する場合があります。
The RADIUS server determines the age of the nonce in Digest-Nonce by using an embedded time-stamp or by looking it up in a local table. The RADIUS server MUST check the integrity of the nonce if it embeds the time-stamp in the nonce. Section 2.2.2 describes how the server handles old nonces.
RADIUSサーバーは、埋め込まれたタイムスタンプを使用するか、ローカルテーブルで調べることにより、Digest-NonceのNonCeの年齢を決定します。RADIUSサーバーは、NONCEにタイムスタンプを埋め込む場合、NonCEの整合性を確認する必要があります。セクション2.2.2では、サーバーが古いNoncesを処理する方法について説明します。
If the Access-Request message has passed 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メッセージが上記のチェックに合格した場合、RADIUSサーバーは[RFC2617]で説明されているようにダイジェスト応答を計算します。パスワードを検索するには、RADIUSサーバーはRADIUSユーザー名属性を使用します。RADIUSサーバーは、ユーザーがユーザー名属性によって識別されたかどうかを確認する必要があります
o is authorized to access the protection space and
o 保護スペースにアクセスすることが許可されています
o is authorized to use the URI included in the SIP-AOR attribute, if this attribute is present.
o この属性が存在する場合、SIP-AOR属性に含まれるURIを使用する権限があります。
If any of those checks fails, the RADIUS server MUST send an Access-Reject.
これらのチェックのいずれかが失敗した場合、RADIUSサーバーはAccess-rejectを送信する必要があります。
Correlation between User-Name and SIP-AOR AVP values is required just to avoid that any user can register or misuse a SIP-AOR 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.
ダイジェスト計算に必要なすべての値は、このドキュメントで説明されているダイジェスト属性から取得されます。計算されたダイジェスト応答が、Digest-Response属性で受信された値に等しい場合、認証は成功しました。
If the response values match, but the RADIUS server considers the nonce in the Digest-Nonce attribute as 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サーバーがDigest-Nonce属性のNonCEを古すぎると見なしている場合、新しいNonCEと「True」の値を持つDigest-Stale属性を含むアクセスチャレンジパケットを送信します（周囲のない引用符）。
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サーバーは、RADIUSクライアントが使用して認証INFOヘッダーを構築するために使用できるAccess-Acceptパケットに属性を追加します。
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.
o Digest-QOP属性の値が「認証」または不特定の場合、RADIUSサーバーはDigest-Response-Auth属性をAccess-Acceptパケットに入れる必要があります。
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 Digest-qop属性の値が「auth-int」であり、少なくとも次の条件の1つが真である場合、RADIUSサーバーはDigest-HA1属性をAccess-Acceptパケットに入れる必要があります。
* The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-MD5-sess'.
* Digest-Algorithm属性の値は、「MD5-SESS」または「AKAV1-MD5-SESS」です。
* IPsec is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see Section 8).
* IPSECは、IPSECを使用してRADIUSクライアントとRADIUSサーバー間のトラフィックを保護するように構成されています（セクション8を参照）。
In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be sent.
他のすべての場合、Digest-Response-AuthまたはDigest-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サーバーは、Digest-NextNonce属性を構築し、Access-Acceptパケットに追加する場合があります。これは、NonCEの寿命を制限し、将来のリクエストで往復を節約するのに役立ちます（[RFC2617]、セクション3.2.3のNextNonceディスカッションを参照）。RADIUSサーバーは、Message-Authenticator属性（[RFC3579]を参照）を追加し、Access-Acceptパケットを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-Qop and MAY add Digest-Domain, Digest-Opaque attributes to the Access-Challenge packet.
RADIUSサーバーがAccess-Requestパケットで受信したNONCEを受け入れないが、認証が成功した場合、RADIUSサーバーは、「True」に設定されたダイジェストステール属性を含むアクセスチャレンジパケットを送信する必要があります（周囲の引用符なし）。RADIUSサーバーは、Message-Authenticator（[RFC3579]を参照）を追加する必要があります（[RFC3579]を参照）、Digest-Nonce、Digest-RealMは、Digest-Algorithmおよび1つ以上のDigest-QOPを追加し、Digest-Domain、Digest-Opaque属性をアクセスに追加する可能性があります。チャレンジパケット。
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
引用されたストリング構文を持つHTTPスタイルのディレクティブを表すDigest-*属性の引用とバックスラッシュ文字が逃げます。周囲の引用符は削除されます。それらは、半径が冗長である構文的な区切り文字です。たとえば、指令
realm="the \"example\" value"
Realm = "the \"例\ "値"
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-Requests. Type 103 for Digest-Response. Length >= 3
説明この属性がAccess-Requestメッセージに存在する場合、この仕様を実装するRADIUSサーバーは、Access-Requestをダイジェスト認証のリクエストとして扱う必要があります。RADIUSクライアントが（プロキシ - ）承認ヘッダーを受信すると、リクエストダイジェスト値をダイジェスト応答属性に配置します。この属性（ユーザーがパスワードの所有を証明できるようにする）は、アクセスリケストでのみ使用する必要があります。ダイジェスト応答のためのタイプ103。長さ> = 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.
テキストHTTPダイジェストを使用する場合、テキストフィールドの長さは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 and Access-Challenge 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を参照してください。Access-RequestおよびAccess-Challengeパケットでのみ使用する必要があります。Digest-Realmの長さのタイプ104> = 3テキストアクセス再クエストでは、RADIUSクライアントは、認証を必要とするHTTPスタイルの要求からの引用を取り巻くことなく、レルム指令（[RFC2617]に従ってレルム値）の値を取得します。Access-Challengeパケットでは、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 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.
この属性には、HTTPダイジェスト計算で使用されるNonCEが保持されます。Access-RequestにDigest-MethodとDigest-URIがあり、Digest-Nonce属性がない場合、RADIUSサーバーはDigest-Nonce属性をそのアクセスチャレンジパケットに入れなければなりません。この属性は、Access-RequestおよびAccess-Challengeパケットでのみ使用する必要があります。Digest-Nonceの長さのタイプ105Access-Challengeパケットには、属性にはRADIUSサーバーによって選択された非CEが含まれます。
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サーバーがパスワードの所有を証明できます。以前に受信したDigest-QOP属性が「auth-int」（周囲の引用符なし）である場合、RADIUSサーバーは、Digest-Response-Auth属性の代わりにDigest-HA1属性を送信する必要があります。Digest-Response-Auth属性は、Access-Acceptパケットでのみ使用する必要があります。RADIUSクライアントは、認証INFOヘッダーのRSPAuth指令に引用符を囲むことなく属性値を配置します。Digest-Response-Authのタイプ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サーバーは、Digest-NextNonce属性をAccess-Acceptパケットに入れる場合があります。この属性が存在する場合、RADIUSクライアントは、この属性のコンテンツを、HTTPスタイルの応答における認証INFOヘッダーのNextNonce指令に配置する必要があります。この属性は、Access-Acceptパケットでのみ使用する必要があります。Digest-NextNonceの長さのタイプ107> = 3テキストこのテキストは、base64または16進数データであることをお勧めします。
Description This attribute holds the method value to be used in the HTTP Digest calculation. This attribute MUST only be used in Access-Request packets.
説明この属性は、HTTPダイジェスト計算で使用されるメソッド値を保持します。この属性は、Access-Requestパケットでのみ使用する必要があります。
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.
Digest-Methodの長さのタイプ108
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 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.
説明この属性は、Digest-URIディレクティブの内容またはHTTPスタイルのリクエストのURIを輸送するために使用されます。Access-Requestパケットでのみ使用する必要があります。DIGEST-URIの長さのタイプ109-value "[rfc2617]のセクション3.2.2）は、この属性に引用符を囲むことなく。承認ヘッダーがない場合、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 and Access-Challenge 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]. 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.
説明この属性は、HTTPダイジェストの計算に影響を与える保護パラメーターの品質を保持します。この属性は、Access-RequestおよびAccess-Challengeパケットでのみ使用する必要があります。RADIUSクライアントは、以前のアクセスチャレンジパケットで受信したダイジェストQOP属性の1つを挿入する必要があります。RADIUSサーバーは、Access-Challengeパケットに少なくとも1つのDigest-QOP属性を挿入する必要があります。Digest-QOPは、[RFC2069]の最小限の実装で後方互換性を保持するためにオプションです。Digest-QOPの長さのタイプ110Access-Challengeパケットでは、RADIUSサーバーは目的のQOP値をこの属性に入れます。RADIUSサーバーが複数の「保護品質」値をサポートする場合、各QOP値を個別のDigest-QOP属性に入れます。
Description This attribute holds the algorithm parameter that influences the HTTP Digest calculation. It MUST only be used in Access-Request and Access-Challenge 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ダイジェスト計算に影響を与えるアルゴリズムパラメーターを保持します。Access-RequestおよびAccess-Challengeパケットでのみ使用する必要があります。この属性が欠落している場合、MD5が想定されます。Digest-Algorithmの長さのタイプ111> = 3テキストAccess-Requestsでは、RADIUSクライアントは、ALGORITHMディレクティブの値を取得します（[RFC2617]、セクション3.2.1で説明されています）。Access-Challengeパケットでは、RADIUSサーバーは目的のアルゴリズムをこの属性に配置する必要があります。
Description When using the qop-level '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 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.
[RFC3261]のセクション22.4で説明されている明確化は、空のエンティティボディのハッシュに関するダイジェストエンティティボディハッシュ属性に適用されます。この属性は、Access-Requestパケットでのみ送信する必要があります。Digest-Entity-Body-Hash Lengthのタイプ112> = 3テキスト属性は、H（エンティティボディ）の16進表現を保持します。このハッシュは、「Auth-Int」に設定された保護品質を備えたHTTPダイジェストなど、特定の認証メカニズムによって必要です。RADIUSクライアントは、HTTPダイジェストが認証メカニズムである場合、エンティティボディのハッシュを輸送するためにこの属性を使用する必要があり、RADIUSサーバーは、エンティティボディの整合性（たとえば、QOPパラメーターを「auth-int」に設定）を検証する必要があります。このドキュメントの拡張は、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ダイジェスト計算で使用されるクライアントNonCeパラメーターを保持します。Access-Requestパケットでのみ使用する必要があります。Digest-Cnonceの長さのタイプ113> = 3テキストこの属性には、HTTPスタイルのリクエストから取られた、周囲の引用なしにCnonce-Value [RFC2617]の値が含まれます。
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.
説明この属性には、リプレイ攻撃の検出に使用されるNonCeカウントパラメーターが含まれます。属性は、Access-Requestパケットでのみ使用する必要があります。
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.
タイプ114 Digest-Nonce-Count Length 10 Text 10 Access-Requestsのテキストでは、RADIUSクライアントは、認証を必要とするHTTPスタイルの要求からの引用を取り巻くことなく、NC指令（[RFC2617]に従って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 MUST use the User-Name (1) attribute, and MUST NOT use the Digest-Username attribute. This attribute MUST only be used in Access-Request packets. Type 115 for Digest-Username
説明この属性は、HTTPダイジェスト計算で使用されるユーザー名を保持します。RADIUSサーバーは、ダイジェストを計算する目的でのみこの属性を使用する必要があります。適切なユーザー資格情報を決定するために、RADIUSサーバーはuser-name（1）属性を使用する必要があり、ダイジェストユーザー名属性を使用してはなりません。この属性は、Access-Requestパケットでのみ使用する必要があります。ダイジェストユーザー名のタイプ115
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.
長さ> = 3テキストAccess-Requestsでは、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クライアント）に戻します。この属性は、Access-RequestおよびAccess-Challengeパケットでのみ使用する必要があります。Digest-opaqueの長さのタイプ116この属性にそれを入れます。Access-Challengeパケットでは、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」パラメーターに対応します。Digest-Auth-Paramは、RADIUSクライアントとRADIUSサーバーが、RADIUSクライアントによって理解されず、対応するスタンドアロン属性がないダイジェストヘッダーに含まれるAuth-Param拡張パラメーターを交換できるメカニズムです。
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, or Access-Accept packets.
以前にリストされたDigest-*属性とは異なり、Digest-Auth-Paramには、PALAMETOR名もRADIUSクライアントには不明であるため、値だけでなくパラメーター名も含まれています。ダイジェストヘッダーにいくつかの未知のパラメーターが含まれている場合、RADIUS実装はこの属性を繰り返す必要があり、各インスタンスには1つの異なる不明なダイジェストパラメーター/値の組み合わせが含まれている必要があります。この属性は、Access-Request、Access-Challenge、またはAccess-Acceptパケットでのみ使用する必要があります。
Type 117 for Digest-Auth-Param Length >=3 Text The text consists of the whole parameter, including its name and the equal sign ('=') and quotes.
Digest-Auth-Paramの長さのタイプ117
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.
説明この属性は、ダイジェスト（[RFC3310]）計算で使用されるAUTSパラメーターを保持します。Digest-responseのアルゴリズムがDigest [RFC3310]のバージョンを示す場合にのみ使用されます。この属性は、Access-Requestパケットでのみ使用する必要があります。DIGEST-AKA-AUTSのタイプ118> = 3テキストアクセスリケストのテキスト、RADIUSクライアントは、HTTPスタイルのリクエストからの引用を囲むことなく、AUTSディレクティブ（[RFC3310]のセクション3.4に従ってAuts-Param）を取得します。認証したいです。
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 packets. Type 119 for Digest-Domain Length 3 Text This attribute consists of a single URI that defines a protection space component.
説明RADIUSクライアントがNONCEを要求した場合、RADIUSサーバーはアクセスチャレンジパケットに1つ以上のダイジェストドメイン属性を送信する場合があります。RADIUSクライアントは、www-authenticateヘッダーの「ドメイン」指令のurisの引用されたスペース分離されたリストにそれらを入れます。Digest-RealMとともに、リスト内のURIは、一部のHTTPスタイルのプロトコルについては、保護スペース（[RFC2617]、セクション3.2.1を参照）を定義します。この属性は、アクセスチャレンジパケットでのみ使用する必要があります。ダイジェストドメイン長3テキストのタイプ119この属性は、保護スペースコンポーネントを定義する単一の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).
説明この属性は、RADIUSクライアントにNONCEを受け入れたかどうかを通知するためにRADIUSサーバーによって送信されます。RADIUSクライアントによって提示された非CEが古くなった場合、値は「真」であり、それ以外の場合は「偽」です。RADIUSクライアントは、この属性のコンテンツを、認証したい要求に対するHTTPスタイルの応答におけるwww-authenticateヘッダーの「古い」指令に配置します。属性は、アクセスチャレンジパケットでのみ使用する必要があります。Digest-Stale Length 3のタイプ120テキスト属性には、値「True」または「False」のいずれか（両方の値が引用符なしの値）があります。
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」である場合、アクセスacceptパケットで使用する必要があります。
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).
QOPパラメーターが指定されていないか、「auth」の値がある場合は、この属性を送信してはなりません（この場合、代わりにDigest-Response-authを使用してください）。
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:
Digest-HA1属性は、RADIUSサーバーによってのみ送信されるか、次の条件の少なくとも1つが真である場合にRADIUSクライアントによって処理される必要があります。
+ The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-MD5-sess'.
+ Digest-Algorithm属性の値は、「MD5-SESS」または「AKAV1-MD5-SESS」です。
+ IPsec is configured to protect traffic between 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. Type 121 for Digest-HA1 Length >= 3
この属性は、Access-Acceptパケットでのみ使用する必要があります。Digest-Ha1の長さのタイプ121> = 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.
テキストこの属性には、[RFC2617]、セクション3.1.3、3.2.1、および3.2.2.2に記載されているH（A1）の16進表現が含まれています。
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レジスタリクエストのヘッダーフィールド（登録中のユーザー）、または他のSIPリクエストのヘッダーフィールドから派生できます。ただし、SIPへのこの属性の正確なマッピングは、プロトコルの新しい開発により変更される可能性があります。この属性は、RADIUSクライアントがSIPユーザーを承認したい場合にのみ使用する必要があり、Access-Requestパケットでのみ使用する必要があります。SIP-AORの長さのタイプ122
The SIP-AOR attribute holds the complete URI, including parameters and other parts. It is up to the RADIUS server what components of the URI are regarded in the authorization decision.
SIP-AOR属性は、パラメーターやその他の部分を含む完全なURIを保持します。RADIUSサーバー次第で、URIのコンポーネントが承認決定でどのコンポーネントと見なされているかです。
This document defines support for Digest Authentication in RADIUS. A companion document "Diameter Session Initiation Protocol (SIP) Application" [SIP-APP] defines support for Digest Authentication in Diameter, and addresses compatibility issues between RADIUS and Diameter.
このドキュメントでは、RADIUSでの消化認証のサポートを定義しています。コンパニオンドキュメント「直径セッション開始プロトコル（SIP）アプリケーション」[SIP-APP]は、直径のダイジェスト認証のサポートを定義し、半径と直径の間の互換性の問題に対処します。
The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity.
次の表は、どの種類のパケットとどのような量の属性が見つかるかについてのガイドを示します。
+-----+--------+--------+-----------+-----+-------------------------+
| Req | Accept | Reject | Challenge | # | Attribute |
+-----+--------+--------+-----------+-----+-------------------------+
| 1 | 0 | 0 | 0 | 1 | User-Name |
| 1 | 1 | 1 | 1 | 80 | Message-Authenticator |
| 0-1 | 0 | 0 | 0 | 103 | Digest-Response |
| 0-1 | 0 | 0 | 1 | 104 | Digest-Realm |
| 0-1 | 0 | 0 | 1 | 105 | Digest-Nonce |
| 0 | 0-1 | 0 | 0 | 106 | Digest-Response-Auth |
| | | | | | (see Note 1, 2) |
| 0 | 0-1 | 0 | 0 | 107 | Digest-Nextnonce |
| 0-1 | 0 | 0 | 0 | 108 | Digest-Method |
| 0-1 | 0 | 0 | 0 | 109 | Digest-URI |
| 0-1 | 0 | 0 | 0+ | 110 | Digest-Qop |
| 0-1 | 0 | 0 | 0-1 | 111 | Digest-Algorithm (see |
| | | | | | Note 3) |
| 0-1 | 0 | 0 | 0 | 112 | Digest-Entity-Body-Hash |
| 0-1 | 0 | 0 | 0 | 113 | Digest-CNonce |
| 0-1 | 0 | 0 | 0 | 114 | Digest-Nonce-Count |
| 0-1 | 0 | 0 | 0 | 115 | Digest-Username |
| 0-1 | 0 | 0 | 0-1 | 116 | Digest-Opaque |
| 0+ | 0+ | 0 | 0+ | 117 | Digest-Auth-Param |
| 0-1 | 0 | 0 | 0 | 118 | Digest-AKA-Auts |
| 0 | 0 | 0 | 0+ | 119 | Digest-Domain |
| 0 | 0 | 0 | 0-1 | 120 | Digest-Stale |
| 0 | 0-1 | 0 | 0 | 121 | Digest-HA1 (see Note 1, |
| | | | | | 2) |
| 0-1 | 0 | 0 | 0 | 122 | SIP-AOR |
+-----+--------+--------+-----------+-----+-------------------------+
Table 1
表1
[Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if Digest-Qop is 'auth-int'.
[注1] Digest-Qopが「auth-int」である場合、ダイジェスト応答-authの代わりにダイジェスト-HA1を使用する必要があります。
[Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if Digest-Qop is 'auth'.
[注2] Digest-QOPが「認証」である場合、Digest-HA1の代わりにDigest-Response-Authを使用する必要があります。
[Note 3] If Digest-Algorithm is missing, 'MD5' is assumed.
[注3] Digest-Algorithmが欠落している場合、「MD5」が想定されます。
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メッセージは完全には表示されません。
A->B
a-> b
INVITE sip:97226491335@example.com SIP/2.0
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
B->A
b-> a
SIP/2.0 100 Trying
SIP/2.0 100試行
B->C
b-> c
Code = 1 (Access-Request) Attributes: NAS-IP-Address = c0 0 2 26 (192.0.2.38) NAS-Port-Type = 5 (Virtual) User-Name = 12345678 Digest-Method = INVITE Digest-URI = sip:97226491335@example.com Message-Authenticator = 08 af 7e 01 b6 8d 74 c3 a4 3c 33 e1 56 2a 80 43
Code = 1（Access-Request）属性：NAS-IP-Address = C0 0 2 26（192.0.2.38）Nas-Port-Type = 5（Virtual）user-name = 12345678 Digest-Method = Invite digest-uri = sip：97226491335@example.comメッセージ-Authenticator = 08 AF 7E 01 B6 8D 74 C3 A4 3C 33 E1 56 2A 80 43
C->B
c-> b
Code = 11 (Access-Challenge) Attributes: Digest-Nonce = 3bada1a0 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
Code = 11（Access-Challenge）属性：Digest-Nonce = 3Bada1a0 Digest-Realm = Example.com Digest-Qop = auth Digest-algorithm = md5 message-authenticator = f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27DA 40
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
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 algorithm="md5",nonce="3bada1a0"
,realm="example.com"
,response="f3ce87e6984557cd0fecc26f3c5e97a4"
,uri="sip:97226491335@example.com",username="12345678"
,qop=auth,algorithm=MD5
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
B->C
b-> c
Code = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678
Digest-Response = f3ce87e6984557cd0fecc26f3c5e97a4
Digest-Realm = example.com
Digest-Nonce = 3bada1a0
Digest-Method = INVITE
Digest-URI = sip:97226491335@example.com
Digest-Qop = auth
Digest-Algorithm = md5
Digest-Username = 12345678
SIP-AOR = sip:12345678@example.com
Message-Authenticator =
ff 67 f4 13 8e b8 59 32 22 f9 37 0f 32 f8 e0 ff
C->B
c-> b
Code = 2 (Access-Accept) Attributes: Digest-Response-Auth = 6303c41b0e2c3e524e413cafe8cce954 Message-Authenticator = 75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1
Code = 2（Access-Accept）属性：Digest-Response-Auth = 6303C41B0E2C3E524E413CCE8CCE954 MESSION-AUTHENTICATOR = 75 8D 44 44 49 66 1F 7B 47 9D 10 D0 2D 4A 2E F1
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), web server (B), and a RADIUS server (C).
2番目の例は、Webブラウザー（a）、Webサーバー（b）、およびRADIUSサーバー（C）間のトラフィックを示しています。
A->B
a-> b
GET /index.html HTTP/1.1
get /index.html http /1.1を取得します
B->C
b-> c
Code = 1 (Access-Request) Attributes: NAS-IP-Address = c0 0 2 26 (192.0.2.38) NAS-Port-Type = 5 (Virtual) Digest-Method = GET Digest-URI = /index.html Message-Authenticator = 34 a6 26 46 f3 81 f9 b4 97 c0 dd 9d 11 8f ca c7
code = 1（Access-Request）属性：NAS-IP-Address = C0 0 2 26（192.0.2.38）Nas-Port-Type = 5（Virtual）Digest-Method = Get Digest-Uri = /index.htmlメッセージ - Authenticator = 34 A6 26 46 F3 81 F9 B4 97 C0 DD 9D 11 8F CA C7
C->B
c-> b
Code = 11 (Access-Challenge) Attributes: Digest-Nonce = a3086ac8 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
Code = 11（Access-Challenge）属性：Digest-Nonce = a3086ac8 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = md5 message-authenticator = f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27DA 40
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
A->B
a-> b
GET /index.html HTTP/1.1
Authorization: Digest algorithm=MD5,nonce="a3086ac8"
,realm="example.com"
,response="f052b68058b2987aba493857ae1ab002"
,uri="/index.html",username="12345678"
,qop=auth,algorithm=MD5
B->C
b-> c
Code = 1 (Access-Request) Attributes: NAS-IP-Address = c0 0 2 26 (192.0.2.38) NAS-Port-Type = 5 (Virtual) User-Name = 12345678 Digest-Response = f052b68058b2987aba493857ae1ab002 Digest-Realm = example.com Digest-Nonce = a3086ac8 Digest-Method = GET Digest-URI = /index.html Digest-Username = 12345678 Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = 06 e1 65 23 57 94 e6 de 87 5a e8 ce a2 7d 43 6b
Code = 1（Access-Request）属性：NAS-IP-Address = C0 0 2 26（192.0.2.38）Nas-Port-Type = 5（Virtual）user-name = 12345678 Digest-Response = F052B68058B2987ABA493857A1AB002 DIMESTRIMM = DIM.com Digest-Nonce = a3086ac8 Digest-Method = Get Digest-uri = /index.html Digest-Username = 12345678 Digest-Qop = Md5 Message-Authenticator = 06 E1 65 23 57 94 DE 87 5A E8A E85 5ACE A2 7D 43 6b
C->B
c-> b
Code = 2 (Access-Accept) Attributes: Digest-Response-Auth = e644aa513effbfe1caff67103ff6433c Message-Authenticator = 7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7
Code = 2（Access-Accept）属性：Digest-Response-Auth = e644aa513effbfe1caff67103ff6433c messay-authenticator = 7a 66 73 A3 52 44 DD CA 90 E2 F6 10 61 2d 81 D7
B->A
b-> a
HTTP/1.1 200 OK ...
HTTP/1.1 200 OK ...
<html> ...
<html> ...
This document serves as an IANA registration request for a number of values from the RADIUS attribute type number space. The IANA has assigned the following:
このドキュメントは、RADIUS属性タイプ番号スペースからの多くの値のIANA登録要求として機能します。IANAは以下を割り当てました。
+-------------------------+------------------------+
| placeholder | value assigned by IANA |
+-------------------------+------------------------+
| Digest-Response | 103 |
| Digest-Realm | 104 |
| Digest-Nonce | 105 |
| Digest-Nextnonce | 106 |
| Digest-Response-Auth | 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 |
+-------------------------+------------------------+
Table 2
表2
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.
このドキュメントで説明されている半径拡張機能により、半径はダイジェスト計算を実行するために必要なデータを輸送できます。その結果、半径は、[RFC2865]、セクション8、および[RFC3579]に記載されている半径セキュリティの脆弱性に加えて、HTTPダイジェストの脆弱性（[RFC2617]、セクション4を参照）を継承します。
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で保護されている場合でも、中間の攻撃を実行できます。
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サーバーは、クライアントから受信したDigest-RealM属性を確認する必要があります。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スタイルのリクエストを認証する場合があります。LADIUSを使用してリンク層ネットワークアクセスを認証するのと比較して、攻撃者はこのようなシナリオでトラックをカバーする方が簡単になる場合があります。
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サーバーは、HTTPスタイルのクライアントから受信したNONCEを生成したかどうかを確認する必要があります。これはステクトレスに行う必要があります。たとえば、非CEは、[RFC2617]、セクション3.2.1で説明されているように、暗号的にランダムな部分とRADIUSクライアントによって提供される何らかの署名で構成されます。
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.
このドキュメントで説明されている属性は、ClearTextで送信されます。RADIUSサーバーには、Access-ChallengeメッセージにDigest-QOPおよびDigest-Algorithm属性を含める必要があります。中央の男性は、入札ダウン攻撃でこれらの属性を変更または削除することができ、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]に記載されているメッセージ-Authenticator属性、セクション3.2は、この仕様に記載されている属性を含むアクセスレクエスト、アクセスチャレンジ、アクセス - アクセプトメッセージ、およびアクセスacceptメッセージに含める必要があります。
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.
Digest-HA1属性には、アルゴリズムが「MD5」または「AKAV1-MD5」の場合、ランダムコンポーネントは含まれません。これにより、オフラインの辞書攻撃が容易になり、再生攻撃が可能になります。
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クライアントとRADIUSサーバー間のトラフィックを保護するようにIPSECが構成されているかどうかを自動的に決定する必要があります。これが不可能な場合、実装は、IPSECが半径トラフィックを保護するかどうかを示す構成パラメーターをチェックします。この構成パラメーターのデフォルト値は、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-Digest認証とともにサーバーサイド証明書を使用してTLSを使用できます。TLSの代わりに、IPSECも使用できます。TLSまたはIPSEC Digest Authenticationがユーザーを認証しながら接続を保護します。RADIUSトランザクションは、HTTPスタイルのクライアントとHTTPスタイルのサーバーの間のパス上の片足と見なすことができます。半径が弱いリンクを表すのを防ぐために、TLSまたはIPSECを介してHTTPスタイルの要求を受信するRADIUSクライアントは、RADIUSサーバーへの等しく安全な接続を使用できます。これを達成するには、いくつかの方法があります。たとえば、
o The RADIUS client may reject HTTP-style requests received over TLS or IPsec.
o RADIUSクライアントは、TLSまたはIPSECを介して受信したHTTPスタイルのリクエストを拒否する場合があります。
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上の半径は、使用する場合、[RFC3579]、セクション4.2で説明されている要件に準拠する必要があります。
We would like to acknowledge Kevin McDermott (Cisco Systems) for providing comments and experimental implementation.
コメントと実験的実装を提供してくれたKevin McDermott（Cisco Systems）に感謝します。
Many thanks to all reviewers, especially to Miguel Garcia, Jari Arkko, Avi Lior, and Jun Wang.
すべてのレビュアー、特にミゲル・ガルシア、ジャリ・アークコ、アヴィ・リオール、ジュン・ワンに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「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.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、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. Calhoun、「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月。
[SIP-APP] Garcia-Martin, M., "Diameter Session Initiation Protocol (SIP) Application", Work in Progress), April 2006.
[SIP-APP] Garcia-Martin、M。、「直径セッション開始プロトコル（SIP）アプリケーション」、進行中の作業）、2006年4月。
[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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Leach、P.、Luotonen、A.、Sink、E。、およびL. Stewart、「HTTPへの拡張：消化アクセス認証」、RFC 2069、1997年1月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[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] Niemi、A.、Arkko、J。、およびV. Torvinen、「Hypertext Transfer Protocol（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] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
Authors' Addresses
著者のアドレス
Baruch Sterman Kayote Networks P.O. Box 1373 Efrat 90435 Israel
Baruch Sterman Kayote Networks P.O.ボックス1373 EFRAT 90435イスラエル
EMail: baruch@kayote.com
Daniel Sadolevsky SecureOL, Inc. Jerusalem Technology Park P.O. Box 16120 Jerusalem 91160 Israel
Daniel Sadolevsky Secureol、Inc。エルサレムテクノロジーパークP.O.ボックス16120エルサレム91160イスラエル
EMail: dscreat@dscreat.com
David Schwartz Kayote Networks P.O. Box 1373 Efrat 90435 Israel
David Schwartz Kayote Networks P.O.ボックス1373 EFRAT 90435イスラエル
EMail: david@kayote.com
David Williams Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park NC 27709 USA
David Williams Cisco Systems 7025 Kit Creek Road P.O.Box 14987 Research Triangle Park NC 27709 USA
EMail: dwilli@cisco.com
Wolfgang Beck Deutsche Telekom AG Deutsche Telekom Allee 7 Darmstadt 64295 Germany
Wolfgang Beck Deutsche Telekom AG Deutsche Telekom Allee 7 Darmstadt 64295ドイツ
EMail: beckw@t-systems.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。