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

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




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.


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
1. Introduction
1. はじめに
1.1. Terminology
1.1. 用語

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.


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


NAS Network Access Server, the RADIUS client.


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 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(セッション開始プロトコル)要求に対する応答を生成する論理エンティティ。

1.2. Motivation
1.2. 動機

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]及びセキュア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 [SIP-APP] defines support for Digest Authentication within Diameter.


1.3. Overview
1.3. 概要

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ダイジェストトランザクションを示しています。

                  +------------+  (1)     +------------+
                  |            |--------->|            |
                  | HTTP-style |  (2)     | HTTP-style |
                  | client     |<---------| server     |
                  |            |  (3)     |            |
                  |            |--------->|            |
                  |            |  (4)     |            |
                  |            |<---------|            |
                  +------------+          +------------+

Figure 1: Digest operation without 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 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).


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ダイジェスト認証をサポートしていません。それは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.


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.




               +-----+    (1)    +-----+           +-----+
               |     |==========>|     |    (2)    |     |
               |     |           |     |---------->|     |
               |     |           |     |    (3)    |     |
               |     |    (4)    |     |<----------|     |
               |     |<==========|     |           |     |
               |     |    (5)    |     |           |     |
               |     |==========>|     |           |     |
               |  A  |           |  B  |    (6)    |  C  |
               |     |           |     |---------->|     |
               |     |           |     |    (7)    |     |
               |     |           |     |<----------|     |
               |     |    (8)    |     |           |     |
               |     |<==========|     |           |     |
               +-----+           +-----+           +-----+
               ====> HTTP/SIP
               ----> RADIUS

Figure 2: HTTP Digest over RADIUS


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


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)でそれを拒否します。

2. Detailed Description
2.1. RADIUS Client Behavior
2.1. RADIUSクライアントの動作

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.


2.1.1. Credential Selection
2.1.1. 資格の選択

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.


2.1.2. Constructing an Access-Request
2.1.2. アクセス要求を構築

If a matching (Proxy-)Authorization header is present and contains HTTP Digest information, the RADIUS client checks the 'nonce' parameter.


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 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]で説明したように、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.


The RADIUS server processes the packet and responds with an Access-Accept or an Access-Reject.


2.1.3. Constructing an Authentication-Info Header
2.1.3. 認証-情報ヘッダーを構築

After having received an Access-Accept from the RADIUS server, the RADIUS client constructs an Authentication-Info header:


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.


* 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クライアントは「QOP」とそれが認可したいHTTP形式のリクエストのAuthorizationヘッダの「アルゴリズム」ディレクティブをチェックします。

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


* 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'.


+ 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形式の応答メッセージを作成し、このメッセージのボディのハッシュを計算します。これは、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.


2.1.4. Failed Authentication
2.1.4. 失敗した認証

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.


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を受け入れませんでした。ダイジェスト古い属性がアクセスチャレンジに存在し、(周囲の引用符なし)「真」の値を有する場合、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サーバーにフェールオーバーします。

2.1.5. Obtaining Nonces
2.1.5. ナンスの取得

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を選択し、ダイジェスト・ナンス属性を含むアクセスチャレンジで応答します。

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、ダイジェスト・アルゴリズム、ダイジェスト・ドメイン、およびナンスを運ぶアクセスチャレンジでのダイジェスト-不透明な属性を送ることができます。これらの属性が存在する場合、クライアントはそれらを使用しなければなりません。

2.2. RADIUS Server Behavior
2.2. RADIUSサーバーの動作

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サーバは、ダイジェスト・メソッドとダイジェスト-URI属性ではなくダイジェスト・ナンス属性なしのAccess-Requestパケットを受信した場合、それはnonceを選択します。これは、ダイジェスト・ナンス属性にnonceを置き、RADIUSクライアントにアクセスチャレンジパケットで送信します。 RADIUSサーバはダイジェスト・レルム、メッセージ認証を追加する必要があります(参照[RFC3579])は、ダイジェスト・アルゴリズムと1つまたは複数のダイジェストQOPを追加する必要があり、アクセスチャレンジパケットにダイジェスト・ドメインまたはダイジェスト-不透明な属性を追加することができます。

2.2.1. General Attribute Checks
2.2.1. 一般的な属性検査

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.

ダイジェスト・レルム、ダイジェスト・ノンス、ダイジェスト・メソッド、ダイジェスト-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クライアントがダイジェスト・レルム属性に言及した分野のユーザーにサービスを提供するために許可されている場合は、RADIUSサーバがチェックしなければなりません。 RADIUSクライアントが許可されていない場合、RADIUSサーバーはアクセス拒否を送らなければなりません。 RADIUSサーバは、オペレータに通知するようにイベントをログに記録しなければならず、この動作は、管理アクションによってリセットされるまでは、そのようなこのクライアントからのすべての将来の要求に応じて、アクセス拒否を送信するように、追加措置を取ってもよいです。

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サーバは、埋め込まれたタイムスタンプを使用するか、またはローカルテーブルでそれを見ることによって、ダイジェスト-Nonceの中ナンスの年齢を決定します。それはナンスにタイムスタンプを埋め込む場合、RADIUSサーバは、ナンスの整合性をチェックしなければなりません。 2.2.2項では、サーバが古いナンスを処理する方法について説明します。

2.2.2. Authentication
2.2.2. 認証

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メッセージは、上記のチェックに合格した場合は、[RFC2617]に記載されているように、RADIUSサーバがダイジェスト応答を算出します。パスワードを検索するには、RADIUSサーバは、RADIUS User-Name属性を使用しています。ユーザーは、User-Name属性によって識別される場合はRADIUSサーバがチェックしなければなりません

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.


If any of those checks fails, the RADIUS server MUST send an 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.


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


If the response values don't match, the RADIUS server responds with an Access-Reject.


2.2.3. Constructing the Reply
2.2.3. 返信を構築

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:


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


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


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-Qop and MAY add Digest-Domain, Digest-Opaque attributes to the Access-Challenge packet.

nonceを受け入れないRADIUSサーバがアクセス要求パケットで受信したが、認証が成功した場合、RADIUSサーバは、(引用符を囲むなし)「真」に設定さダイジェスト古い属性を含むアクセスチャレンジパケットを送らなければなりません。 RADIUSサーバーはAccess-にダイジェスト・アルゴリズムと1つまたは複数のダイジェストQOPを追加すべきであるとダイジェストドメインを追加してもよい(MAY)、ダイジェスト-不透明属性、メッセージ認証([RFC3579]を参照)、ダイジェスト・ノンス、ダイジェスト・レルムを追加しなければなりませんチャレンジパケット。

3. New RADIUS Attributes

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 |
3.1. Digest-Response attribute
3.1. ダイジェスト・レスポンス属性

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サーバは、ダイジェスト認証のための要求として、アクセス要求を扱わなければなりません。 RADIUSクライアント(Proxy-)Authorizationヘッダを受信すると、ダイジェストレスポンス属性に要求ダイジェスト値を置きます。この属性(パスワードの所有を証明するためにユーザを可能にします)のみアクセス - 要求で使用されなければなりません。ダイジェスト・レスポンスのために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.


3.2. Digest-Realm Attribute
3.2. ダイジェスト-realm属性

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を参照してください。それが唯一のアクセス要求とアクセスチャレンジパケットで使用されなければなりません。アクセス・リクエストで> = 3テキストダイジェスト・レルムの長さのために104を入力し、RADIUSクライアントは、それが認証したいHTTP形式のリクエストから引用符を囲むことなく、([RFC2617]によると、レルム値)レルムディレクティブの値をとります。アクセスチャレンジパケットでは、RADIUSサーバは、この属性に期待レルム値を置きます。

3.3. Digest-Nonce Attribute
3.3. ダイジェスト・ナンス属性



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を保持しています。アクセス要求がダイジェスト・メソッドとダイジェスト-URIが、無ダイジェスト・ナンスの属性を持っていた場合、RADIUSサーバは、そのアクセスチャレンジパケットにダイジェスト-Nonceの属性を置く必要があります。この属性は、アクセス要求とアクセスチャレンジパケットで使用されなければなりません。アクセス - 要求の長さ> = 3テキストダイジェスト・ナンスのために105を入力し、RADIUSクライアントは、それが認証したいHTTP形式のリクエストから引用符を囲むことなく、([RFC2617]でナンス値)ナンスディレクティブの値をとります。アクセスチャレンジパケットでは、属性は、RADIUSサーバによって選択されたナンスが含まれています。

3.4. Digest-Response-Auth Attribute
3.4. ダイジェスト・レスポンス認証属性

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以外の長さを定義するかもしれません。

3.5. Digest-Nextnonce Attribute
3.5. ダイジェストNextnonce属性

This attribute holds a nonce to be used in the HTTP Digest calculation.




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を入力します。

3.6. Digest-Method Attribute
3.6. ダイジェスト-method属性

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.


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.

アクセス - 要求でダイジェスト・メソッドの長さ> = 3テキストのために108を入力し、RADIUSクライアントは、それが認証したいHTTP形式のリクエストからのリクエストメソッドの値をとります。

3.7. Digest-URI Attribute
3.7. ダイジェスト-URI属性

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.

説明この属性は、ダイジェスト-URIディレクティブまたはHTTP形式のリクエストのURIの内容を転送するために使用されます。それが唯一のAccess-Requestパケットで使用する必要があります。 HTTP形式のリクエストがAuthorizationヘッダを持っている場合は、RADIUSクライアントは、「ダイジェスト-URIとして知られているHTTP-スタイルリクエストのAuthorizationヘッダ(で見つかった「URI」ディレクティブの値を置くダイジェスト-URIの長さ> = 3のテキストのために109を入力しますこの属性に引用符を囲むことなく、[RFC2617])のセクション3.2.2で-value」。何Authorizationヘッダがない場合は、RADIUSクライアントは、それが認証したいHTTP形式のリクエストからリクエストURIの値をとります。

3.8. Digest-Qop Attribute
3.8. ダイジェストQOP属性

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ダイジェスト計算に影響を与える保護パラメータの品質を保持しています。この属性は、アクセス要求とアクセスチャレンジパケットで使用されなければなりません。 RADIUSクライアントは、ダイジェストQOPの一つは、それが以前のAccess-Challengeパケットで受信した属性を挿入する必要があり。 RADIUSサーバは、アクセスチャレンジパケット内の少なくとも1つのダイジェストQOP属性を挿入する必要があります。ダイジェストQOPは、[RFC2069]の最小限の実装との下位互換性を維持するためにオプションです。からアクセス・リクエストでダイジェストQOP長さ> = 3テキスト110を入力([RFC2617]に記載されているようにQOP値)、RADIUSクライアントはQOP指令の値をとります

         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.
3.9. Digest-Algorithm Attribute
3.9. ダイジェスト・アルゴリズムの属性

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ダイジェスト計算に影響を与えるアルゴリズムパラメータを保持しています。それが唯一のアクセス要求とアクセスチャレンジパケットで使用されなければなりません。この属性が欠落している場合は、MD5が想定されます。それが認証したいHTTP形式のリクエストから([RFC2617]、セクション3.2.1で説明したように)アクセス - 要求でダイジェスト・アルゴリズムの長さ> = 3テキストのために111を入力し、RADIUSクライアントは、アルゴリズムのディレクティブの値をとります。アクセスチャレンジパケットでは、RADIUSサーバは、この属性に必要なアルゴリズムを置くべきです。

3.10. Digest-Entity-Body-Hash Attribute
3.10. ダイジェスト・エンティティボディ - ハッシュ属性

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で説明の明確化は、ダイジェスト・エンティティボディ - ハッシュ属性に適用されます。この属性は、アクセス要求パケットで送らなければなりません。ダイジェスト・エンティティボディハッシュ長さ> = 3テキストの112を入力属性は、H(エンティティボディ)の16進表現を保持しています。このハッシュは、「AUTH-INT」に設定されている保護の品質で、このようなHTTPダイジェストなどの特定の認証メカニズムによって必要とされます。 RADIUSクライアントは、HTTPダイジェスト認証メカニズムであり、RADIUSサーバがエンティティボディ(「AUTH-INT」に設定され、例えば、QOPパラメータ)の整合性を検証することを必要とするときにエンティティボディのハッシュを輸送するために、この属性を使用する必要があります。このドキュメントへの拡張は、HTTPダイジェスト以外の認証メカニズムのサポートを定義することがあります。

3.11. Digest-CNonce Attribute
3.11. ダイジェストCNonce属性

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を入力します。

3.12. Digest-Nonce-Count Attribute
3.12. ダイジェスト・ナンス-count属性

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.

アクセス - 要求でダイジェスト・ノンス-カウント長10文字のために114を入力し、RADIUSクライアントは、それが認証したいHTTP形式のリクエストから引用符を囲むことなく、([RFC2617]に係るNC-値)NC指令の値をとります。

3.13. Digest-Username Attribute
3.13. ダイジェストuserName属性

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サーバーは、ユーザー名(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テキストは、RADIUSクライアントは、それが認証したいHTTP形式のリクエストから引用符を囲むことなく、([RFC2617]によると、ユーザ名、値)のユーザ名ディレクティブの値をとります。

3.14. Digest-Opaque Attribute
3.14. ダイジェスト-不透明属性

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サーバは、この属性を含むかもしれません。

3.15. Digest-Auth-Param Attribute
3.15. ダイジェスト認証-のParam属性

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.


         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

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.

ダイジェスト-AUTH-Paramの長さ117を入力> = 3本文テキストは、その名前と等号(「=」)および引用符を含む、全体のパラメータで構成されています。

3.16. Digest-AKA-Auts Attribute
3.16. ダイジェスト-AKA-AUTS属性

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指令の値をとりますそれが認証したいです。

3.17. Digest-Domain Attribute
3.17. ダイジェスト-domain属性

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クライアントがナンスを求めた場合、RADIUSサーバはダイジェスト・ドメインは、そのアクセスチャレンジパケットの属性一つ以上を送信することができます。 RADIUSクライアントは、WWW-Authenticateヘッダの「ドメイン」ディレクティブのURIの引用された、スペース区切りのリストにそれらを置きます。一緒にダイジェスト・レルムで、リスト中のURIは、いくつかのHTTP形式のプロトコルのために([RFC2617]、セクション3.2.1を参照)保護空間を定義します。この属性は、アクセスチャレンジパケットで使用されなければなりません。この属性は、保護空間のコンポーネントを定義する単一のURIで構成さダイジェストドメインの長さ3のテキストのために119を入力します。

3.18. Digest-Stale Attribute
3.18. ダイジェスト古い属性

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を入力します。

3.19. Digest-HA1 Attribute
3.19. ダイジェスト-HA1属性

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:


+ The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-MD5-sess'.


+ IPsec is configured to protect traffic between RADIUS client and RADIUS server with IPsec (see Section 8).

+ IPsecが(セクション8を参照)のIPsecとRADIUSクライアントとRADIUSサーバ間のトラフィックを保護するように構成されています。

This attribute MUST only be used in Access-Accept packets. Type 121 for Digest-HA1 Length >= 3

この属性のみで使用する必要がありますAccess-Acceptパケット。ダイジェスト-HA1長さ> = 3 121を入力

Text This attribute contains the hexadecimal representation of H(A1) as described in [RFC2617], sections 3.1.3, 3.2.1, and


3.20. SIP-AOR Attribute
3.20. SIP-AOR属性

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 what
         components of the URI are regarded in the authorization
4. Diameter Compatibility

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.


5. Table of Attributes

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


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


[Note 3] If Digest-Algorithm is missing, 'MD5' is assumed.


6. Examples

This is an example selected from the traffic between a softphone (A), a Proxy Server (B), and an 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)、および RADIUSサーバ(C)間のトラフィックから選択例です。プロキシサーバとSIPパブリック間の通信は、電話網(PSTN)ゲートウェイを簡潔にするために省略されているスイッチ。 SIPメッセージが完全に表示されません。


A-> B

INVITE SIP/2.0 From: <> To: <>

INVITE SIP / 2.0から:<>宛先:<>


B-> A

SIP/2.0 100 Trying

SIP / 2.0 100試行


B-> C

Code = 1 (Access-Request) Attributes: NAS-IP-Address = c0 0 2 26 ( NAS-Port-Type = 5 (Virtual) User-Name = 12345678 Digest-Method = INVITE Digest-URI = Message-Authenticator = 08 af 7e 01 b6 8d 74 c3 a4 3c 33 e1 56 2a 80 43

コード= 1(アクセス要求は)属性:NAS-IP-アドレス= C0 0 2 26(ポート型= 5(仮想)ユーザー名= 12345678ダイジェスト方式=ダイジェスト-URI = SIPのINVITE :97226491335@example.comメッセージ認証= 08 AF 7E 01 B6 8D 74のC3 A4 3C 33 E1 56 2A 80 43


C-> B

Code = 11 (Access-Challenge) Attributes: Digest-Nonce = 3bada1a0 Digest-Realm = Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40

コード= 11(アクセスチャレンジ)属性:ダイジェストノンス= 3bada1a0ダイジェストレルム= example.comダイジェストQOP = AUTHダイジェストアルゴリズム= MD5メッセージ・オーセンティケータ= F8 01 26 9F 70 5E EF 5D 24交流F5 FB 27 CAダ40


B-> A

SIP/2.0 407 Proxy Authentication Required Proxy-Authenticate: Digest realm="" ,nonce="3bada1a0",qop=auth,algorithm=MD5 Content-Length: 0

SIP / 2.0 407プロキシ認証が必要プロキシ認証:ダイジェストレルム= ""、ノンス= "3bada1a0"、QOP = AUTH、アルゴリズム= MD5のContent-Length:0


A-> B


ACKの SIP / 2.0


A-> B

INVITE SIP/2.0 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" ,realm="" ,response="f3ce87e6984557cd0fecc26f3c5e97a4" ,uri="",username="12345678" ,qop=auth,algorithm=MD5 From: <> To: <> SIP / 2.0プロキシ認証:SIPのINVITEアルゴリズム= "MD5"、ノンス= "3bada1a0"、レルム= ""、応答= "f3ce87e6984557cd0fecc26f3c5e97a4を" ダイジェスト、URI = "SIP:97226491335例@ .COM」、ユーザ名= "12345678"、QOP = AUTH、アルゴリズム= MD5から:<>宛先:<>


B-> C

Code = 1 (Access-Request) Attributes: NAS-IP-Address = c0 0 2 26 ( NAS-Port-Type = 5 (Virtual) User-Name = 12345678 Digest-Response = f3ce87e6984557cd0fecc26f3c5e97a4 Digest-Realm = Digest-Nonce = 3bada1a0 Digest-Method = INVITE Digest-URI = Digest-Qop = auth Digest-Algorithm = md5 Digest-Username = 12345678 SIP-AOR = Message-Authenticator = ff 67 f4 13 8e b8 59 32 22 f9 37 0f 32 f8 e0 ff

コード= 1(アクセス要求は)属性:NAS-IP-アドレス= C0 0 2 26(ポート型= 5(仮想)ユーザー名= 12345678ダイジェスト・レスポンス= f3ce87e6984557cd0fecc26f3c5e97a4ダイジェスト・レルム=例.COMダイジェストノンス= 3bada1a0ダイジェスト-METHOD = INVITEダイジェスト-URI = SIP:97226491335@example.comダイジェストQOP = AUTHダイジェストアルゴリズム= MD5ダイジェストユーザ名= 12345678 SIP-AOR = SIP:12345678@example.comメッセージ-Authenticator = 67個のF4 13 8E B8 59 32 22 F9 37 0F 32 F8のE0のFF FF


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

コード= 2(アクセスが承諾)属性:ダイジェストレスポンス-AUTH = 6303c41b0e2c3e524e413cafe8cce954メッセージ認証= 75 8D 44 49 66 1F 7B 47 9D 10 D0 2次元4A 2E単三F1


B-> A

SIP/2.0 180 Ringing

SIP / 2.0 180リンギング


B-> A

SIP/2.0 200 OK

SIP / 2.0 200 OK


A-> B


ACKの SIP / 2.0

A second example shows the traffic between a web browser (A), web server (B), and a RADIUS server (C).



A-> B

GET /index.html HTTP/1.1

GET /index.htmlがHTTP / 1.1


B-> C

Code = 1 (Access-Request) Attributes: NAS-IP-Address = c0 0 2 26 ( 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

コード= 1(アクセス要求は)属性:NAS-IP-アドレス= C0 0 2 26(ポート型= 5(仮想)ダイジェスト・メソッド= GETダイジェスト-URI = /index.htmlがMessage-オーセンティケータ= 34 A6 26 46 F3 81 F9 B4 97 C0 DD 9D 11 8FカリフォルニアC7


C-> B

Code = 11 (Access-Challenge) Attributes: Digest-Nonce = a3086ac8 Digest-Realm = Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40

コード= 11(アクセスチャレンジ)属性:ダイジェストノンス= a3086ac8ダイジェストレルム= example.comダイジェストQOP = AUTHダイジェストアルゴリズム= MD5メッセージ・オーセンティケータ= F8 01 26 9F 70 5E EF 5D 24交流F5 FB 27 CAダ40


B-> A

HTTP/1.1 401 Authentication Required WWW-Authenticate: Digest realm="", nonce="a3086ac8",qop=auth,algorithm=MD5 Content-Length: 0

HTTP / 1.1 401認証が必要WWW認証:ダイジェスト分野= ""、ナンス= "a3086ac8"、QOP = AUTH、アルゴリズム= MD5のContent-Length:0


A-> B

GET /index.html HTTP/1.1 Authorization: Digest algorithm=MD5,nonce="a3086ac8" ,realm="" ,response="f052b68058b2987aba493857ae1ab002" ,uri="/index.html",username="12345678" ,qop=auth,algorithm=MD5

GET /index.htmlがHTTP / 1.1認証:ダイジェストアルゴリズム= MD5、ナンス= "a3086ac8"、領域= ""、レスポンス= "f052b68058b2987aba493857ae1ab002"、URI = "/ index.htmlを"、ユーザ名= "12345678"、 QOP = AUTH、アルゴリズム= MD5


B-> C

Code = 1 (Access-Request) Attributes: NAS-IP-Address = c0 0 2 26 ( NAS-Port-Type = 5 (Virtual) User-Name = 12345678 Digest-Response = f052b68058b2987aba493857ae1ab002 Digest-Realm = 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

コード= 1(アクセス要求は)属性:NAS-IP-アドレス= C0 0 2 26(ポート型= 5(仮想)ユーザー名= 12345678ダイジェスト・レスポンス= f052b68058b2987aba493857ae1ab002ダイジェスト・レルム=例.COMダイジェストノンス= a3086ac8ダイジェスト-METHOD = GETダイジェスト-URI = /index.htmlがダイジェストユーザ名= 12345678ダイジェストQOP = AUTHダイジェストアルゴリズム= MD5メッセージ・オーセンティケータ= 06 E1 65 23 57 94 E6ド87 5aはE8 CEのA2 7dを43 6bを


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

コード= 2(接続許可)属性:ダイジェストレスポンス-AUTH = e644aa513effbfe1caff67103ff6433cのメッセージ認証= 7A 66 73 A3 52 44 DD 90 E2 F6 10 61 2D 81 D7 CA


B-> A

HTTP/1.1 200 OK ...

HTTP / 1.1 200 OK ...

<html> ...

<HTML> ...

7. IANA Considerations
7. IANAの考慮事項

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


8. Security Considerations

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.


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.


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スタイルのクライアントにサービスを提供するために許可されていない場合、それは危険にさらされる可能性があります。

8.1. Denial of Service
8.1. サービス拒否

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.


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。

8.2. Confidentiality and Data Integrity
8.2. 機密性とデータの整合性

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.


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.


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.


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.


9. Acknowledgements

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.


10. References
10.1. Normative References
10.1. 引用規格

[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月。

10.2. Informative References
10.2. 参考文献

[SIP-APP] Garcia-Martin, M., "Diameter Session Initiation Protocol (SIP) Application", Work in Progress), April 2006.

[SIP-APP]ガルシア・マーチン、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]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、リーチ、P.、Luotonen、A.、シンク、E.、およびL.スチュワート、 "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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ(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.、 "/セキュア多目的インターネットメール拡張(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]ニエミ、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月。

Authors' Addresses


Baruch Sterman Kayote Networks P.O. Box 1373 Efrat 90435 Israel

バルークSterman Kayoteネットワーク私書箱ボックス1373 Efrat 90435イスラエル



Daniel Sadolevsky SecureOL, Inc. Jerusalem Technology Park P.O. Box 16120 Jerusalem 91160 Israel

ダニエルSadolevsky SecureOL、株式会社エルサレムテクノロジーパークの私書箱ボックス16120エルサレム91160イスラエル



David Schwartz Kayote Networks P.O. Box 1373 Efrat 90435 Israel

デビッド・シュワルツKayoteネットワーク私書箱ボックス1373 Efrat 90435イスラエル



David Williams Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park NC 27709 USA

デビッド・ウィリアムズシスコシステムズ7025キットクリーク道路私書箱14987リサーチトライアングルパークNC 27709 USA箱



Wolfgang Beck Deutsche Telekom AG Deutsche Telekom Allee 7 Darmstadt 64295 Germany

ヴォルフガング・ベックドイツテレコム・アーゲーのドイツテレコムアリー7 64295ダルムシュタットドイツ



Full Copyright Statement


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に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).