RFC4590 日本語訳
4590 RADIUS Extension for Digest Authentication. B. Sterman, D.Sadolevsky, D. Schwartz, D. Williams, W. Beck. July 2006. (Format: TXT=67181 bytes) (Obsoleted by RFC5090) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Stermanがコメントのために要求するワーキンググループB.をネットワークでつないでください: 4590Kayoteはカテゴリをネットワークでつなぎます: 規格はD.ウィリアムズシスコシステムズW.べックドイツ・テレコム株式会社2006年7月にD.Sadolevsky SecureOL Inc.D.シュワルツKayoteネットワークを追跡します。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントは、使用のためにSession Initiationプロトコル(SIP)とHTTPのようなHTTPスタイルプロトコルでDigest Authenticationのサポートを可能にするために中のRemote Authentication Dial User Service(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
1. 序論…2 1.1. 用語…2 1.2. 動機…3 1.3. 概要…4 2. 詳細な記述…6 2.1. 半径クライアントの振舞い…6 2.1.1. 資格証明選択…6 2.1.2. アクセス要求を構成します…6 2.1.3. 認証インフォメーションヘッダーを組み立てます…7 2.1.4. 認証に失敗します…8 2.1.5. 一回だけを得ます…9 2.2. 半径サーバの振舞い…9
Sterman, et al. Standards Track [Page 1] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[1ページ]。
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
2.2.1. 一般属性はチェックします…9 2.2.2. 認証…10 2.2.3. 回答を構成します…11 3. 新しい半径属性…12 3.1. ダイジェスト応答属性…12 3.2. ダイジェスト分野属性…13 3.3. ダイジェスト一回だけ属性…13 3.4. ダイジェスト応答Auth属性…14 3.5. ダイジェスト-Nextnonce属性…14 3.6. ダイジェストメソッド属性…14 3.7. ダイジェストURI属性…15 3.8. ダイジェスト-Qop属性…15 3.9. ダイジェストアルゴリズム属性…16 3.10. ダイジェスト実体ボディーハッシュ属性…16 3.11. ダイジェスト-CNonce属性…17 3.12. ダイジェストの一回だけのカウント属性…17 3.13. ダイジェストユーザ名属性…17 3.14. ダイジェスト不透明な属性…18 3.15. ダイジェスト-Auth-Param属性…18 3.16. ダイジェスト別名Auts属性…19 3.17. ダイジェストドメイン属性…19 3.18. ダイジェスト聞き古した属性…20 3.19. ダイジェスト-HA1属性…20 3.20. 一口AOR属性…21 4. 直径の互換性…21 5. 属性のテーブル…22 6. 例…23 7. IANA問題…27 8. セキュリティ問題…27 8.1. サービス妨害…28 8.2. 秘密性とデータの保全…28 9. 承認…29 10. 参照…29 10.1. 標準の参照…29 10.2. 有益な参照…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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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サーバ実装だけに適用されるものとします。 このドキュメントは既存の実装のためのどんな標準の要件も作成しません。
Sterman, et al. Standards Track [Page 2] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[2ページ]。
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).
[RFC2617]で説明されて、'HTTPスタイル'という用語がHTTPのようなヘッダーを使用するどんなプロトコルも指示して、HTTP Digest Authenticationを使用するHTTPスタイルプロトコル。 例は、HTTPとSession Initiationプロトコル(SIP)です。
NAS
Network Access Server, the RADIUS client.
NAS Network Access Server、RADIUSクライアント。
nonce
An unpredictable value used to prevent replay attacks. The
nonce generator may use cryptographic mechanisms to produce
nonces it can recognize without maintaining state.
反射攻撃を防ぐのに使用される一回だけのAn予測できない値。 一回だけのジェネレータは、それが状態を維持しないで認識できる一回だけを生産するのに暗号のメカニズムを使用するかもしれません。
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 Userエージェント、Session Initiationプロトコルを使用するインターネット終点。
SIP UAS
SIP User Agent Server, a logical entity that generates a
response to a SIP (Session Initiation Protocol) request.
SIP UAS SIP UserエージェントServer、SIP(セッションInitiationプロトコル)要求への応答を生成する論理的な実体。
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 Digest Authenticationメカニズムは次に、SIP[RFC3261]との使用のために適合させられました。 Digest Authentication([RFC2617]を見てください、セクション4)の制限と弱点のため、追加認証と暗号化メカニズムはSIP[RFC3261]で定義されます、Transport Layer Security(TLS)[RFC4346]とSecure MIME(S/MIME)[RFC3851]を含んでいて。 しかしながら、Digest AuthenticationサポートはSIP実装で義務的です、そして、Digest AuthenticationはSIP UAがプロキシサーバにそれ自体を認証する都合のよい方法です。ダイジェストAuthenticationはまた、他のプロトコルに使用されます。
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]などのAuthentication、Authorization、およびAccounting(AAA)プロトコルの中でこの認証機構をサポートする必要があります。
Sterman, et al. Standards Track [Page 3] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[3ページ]。
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スタイルプロトコルでこの認証方法を使用することでDigest Authenticationのサポートを可能にするためにRADIUSプロトコルと拡大を定義します。 また、AuthenticationやKey Agreement(AKA)[RFC3310]などのDigestメカニズムのサポートはサポートされます。 仲間ドキュメント[SIP-APP]はDiameterの中でDigest Authenticationのサポートを定義します。
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 Digestはサーバに関する何らかのリソースにアクセスするというクライアントの要求を認証するのに使用されるチャレンジレスポンスプロトコルです。図1はただ一つのHTTP Digestトランザクションを示しています。
HTTP/SIP..
+------------+ (1) +------------+
| |--------->| |
| HTTP-style | (2) | HTTP-style |
| client |<---------| server |
| | (3) | |
| |--------->| |
| | (4) | |
| |<---------| |
+------------+ +------------+
HTTP/一口。 +------------+ (1) +------------+ | |、-、-、-、-、-、-、-、--、>|、|、| HTTPスタイル| (2) | HTTPスタイル| | クライアント| <、-、-、-、-、-、-、-、--、| サーバ| | | (3) | | | |、-、-、-、-、-、-、-、--、>|、|、|、| (4) | | | | <、-、-、-、-、-、-、-、--、|、| +------------+ +------------+
Figure 1: Digest operation without RADIUS
図1: RADIUSなしで操作を読みこなしてください。
If the client sends a request without any credentials (1), the server will reply with an error response (2) containing a nonce. The client creates a cryptographic digest from parts of the request, from the nonce it received from the server, and from a shared secret. The client 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)が一回だけを含んでいて、サーバは返答するでしょう。 クライアントは要求の部分から暗号のダイジェストを作成します、それがサーバと、共有秘密キーから受けた一回だけから。 クライアントは、要求(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 Digest Authenticationのサポートを含んでいません。 HTTPスタイルクライアントからパスワードを受け取らないので、RADIUSクライアントはUser-パスワード属性を使用できません。 また、CHAPアルゴリズムはHTTP Digestと互換性がないので、[RFC1994]で説明されたCHAP-挑戦とCHAP-パスワード属性も適当ではありません。
Sterman, et al. Standards Track [Page 4] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[4ページ]。
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の中でDigest Authenticationのサポートを提供して。
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サーバによって生成されます。a往復を除いて、RADIUSクライアントで彼らを生成するのは紹介するでしょうが、セキュリティと操作上の問題を紹介してください。 いくつかのダイジェストアルゴリズム(例えば、AKA[RFC3310])は利かないでしょう。
Figure 2 depicts a scenario in which the HTTP-style server defers authentication to a RADIUS server. Entities A and B communicate using HTTP or SIP, while entities B and C communicate using RADIUS.
図2はHTTPスタイルサーバがRADIUSサーバに認証を延期するシナリオについて表現します。実体AとBはHTTPかSIPを使用することで交信します、実体BとCはRADIUSを使用することで交信しますが。
HTTP/SIP RADIUS
HTTP/一口半径
+-----+ (1) +-----+ +-----+
| |==========>| | (2) | |
| | | |---------->| |
| | | | (3) | |
| | (4) | |<----------| |
| |<==========| | | |
| | (5) | | | |
| |==========>| | | |
| A | | B | (6) | C |
| | | |---------->| |
| | | | (7) | |
| | | |<----------| |
| | (8) | | | |
| |<==========| | | |
+-----+ +-----+ +-----+
+-----+ (1) +-----+ +-----+ | |==========>|、| (2) | | | | | |、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| (3) | | | | (4) | | <、-、-、-、-、-、-、-、-、--、|、|、| |<=====| | | | | | (5) | | | | | |==========>|、|、|、|、| A| | B| (6) | C| | | | |、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| (7) | | | | | | <、-、-、-、-、-、-、-、-、--、|、|、|、| (8) | | | | | |<=====| | | | +-----+ +-----+ +-----+
====> HTTP/SIP
----> RADIUS
====>HTTP/一口---->半径
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
B: また、RADIUS NASとして機能するHTTPサーバ/HTTPプロキシサーバ/SIPプロキシサーバ/SIP UAS
C: RADIUS server
C: RADIUSサーバ
Sterman, et al. Standards Track [Page 5] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[5ページ]。
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は承認ヘッダー(ステップ1)なしでHTTP/SIP要求をBに送ります。 Bは新たに定義されたDigest-メソッドとDigest-URI属性にもかかわらず、Digest-一回だけ属性なしでAccess-リクエスト・パケットをRADIUSサーバに送ります、C(ステップ2)。 Cは、一回だけを選んで、Access-挑戦(ステップ3)で応じます。 このAccess-挑戦はDigest属性を含んでいます。(Bは、HTTP/SIPの「(プロキシ)承認必要な」応答を構成するために属性から値を取ります)。 BはAへのこの応答(ステップ4)を送ります。 Aは資格証明書(ステップ5)がある要求を再送します。 BはC(ステップ6)にAccess-要求を送ります。 CはAccess受け入れるとの資格証明書と回答かAccess-廃棄物(ステップ7)をチェックします。 Cの結果によって、Bは、「(プロキシ)承認必要な」応答(ステップ8)でAの要求を処理するか、またはそれを拒絶します。
2. Detailed Description
2. 詳述
2.1. RADIUS Client Behavior
2.1. 半径クライアントの振舞い
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で本書では説明された属性を送ります。 したがって、RADIUSクライアントがHTTPスタイルクライアントから安全な接続(HTTPSかSIPS)を受け入れるなら、これは故意にRADIUS交換の間の明確で送られるHTTPスタイルクライアントによって保護された情報をもたらすかもしれないでしょうに。
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.
RADIUSクライアントは、どの資格証明書が適切であるかを決定するのにHTTPに'分野'指示を使用できます。 分野のいずれも興味がないところでは、RADIUSクライアントがまるでどんな関連資格証明書も送らないかのように振る舞わなければなりません。 すべての状況で、RADIUSクライアントはゼロかまさに1つの資格証明書をRADIUSサーバに送らなければなりません。分野指示が局所的に構成された分野に合っているなら、RADIUSクライアントは(プロキシ)承認ヘッダーの資格証明書を選ばなければなりません。
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.
(プロキシ)合っている承認ヘッダーが存在していて、HTTP Digest情報を含んでいるなら、RADIUSクライアントは'一回だけ'のパラメタをチェックします。
Sterman, et al. Standards Track [Page 6] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[6ページ]。
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クライアントが一回だけを認識するなら、それは、ヘッダー指示を取って、RADIUS Access-リクエスト・パケットにそれらを入れます。 それはそれぞれのDigest-分野、Digest-一回だけ、Digest-URI、Digest-Qop、Digest-アルゴリズム、Digest-CNonce、Digestの一回だけのカウント、Digest-ユーザ名、およびDigest不透明な属性へのDigest-応答属性、分野、一回だけ、ダイジェスト-uri、qop、アルゴリズム、cnonce、nc、ユーザ名、および不透明な指示に'応答'指示を入れます。 RADIUSクライアントはDigest-メソッド属性に要求メソッドを入れます。
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 Digest指示のコンテンツで逃げられなければなりません。 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.
Protection(qop)のQualityが指示のものが、評価する'auth-int'であるなら、RADIUSクライアントは、[RFC2617]、セクション3.2.1で説明されるようにH(実体本体)について計算して、Digest実体ボディーハッシュ属性に結果を入れます。
The RADIUS client adds a Message-Authenticator attribute, defined in [RFC3579], and sends the Access-Request packet to the RADIUS server.
RADIUSクライアントは、[RFC3579]で定義されたMessage-固有識別文字属性を追加して、Access-リクエスト・パケットをRADIUSサーバに送ります。
The RADIUS server processes the packet and responds with an Access-Accept or an Access-Reject.
Access受け入れてください。RADIUSサーバがパケットを処理して、反応する、または、Access-廃棄物。
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:
RADIUSからAccess受け入れているサーバを受け取った後に、RADIUSクライアントはAuthentication-インフォメーションヘッダーを組み立てます:
o If the Access-Accept packet contains a Digest-Response-Auth
attribute, the RADIUS client checks the Digest-Qop attribute:
o Access受け入れているパケットがDigest応答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属性の値が'auth'であるか指定しなかったなら、RADIUSクライアントはAuthentication-インフォメーションヘッダーのHTTPスタイル応答の'rspauth'指示にDigest応答Auth属性の内容を入れます。
* 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クライアントは、Access受け入れているパケットを無視して、まるでAccess-廃棄物パケットを受けたかのように振る舞います(RADIUSサーバがHTTPスタイル応答のボディーのコンテンツを知らないようにダイジェスト応答Authは正しいはずがありません)。
Sterman, et al. Standards Track [Page 7] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[7ページ]。
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受け入れているパケットがDigest-HA1属性を含んでいるなら、RADIUSクライアントはそれが認可したがっているHTTPスタイル要求のAuthorizationヘッダーで'qop'と'アルゴリズム'指示をチェックします:
* If the 'qop' directive is missing or its value is 'auth', the
RADIUS client ignores the Digest-HA1 attribute. It does not
include an Authentication-Info header in its HTTP-style
response.
* 'qop'指示がなくなるか、値が'auth'であるなら、RADIUSクライアントはDigest-HA1属性を無視します。 それはHTTPスタイル応答にAuthentication-インフォメーションヘッダーを含んでいません。
* 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 Securityは、IPsecと共にRADIUSクライアントとRADIUSサーバの間のトラフィックを保護するために構成されます(IPsec)(セクション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)計算を実行するのに結果とDigest-URI属性の対応するAccess-リクエスト・パケットの値を使用します。 'rspauth'価値の計算を終えるのに対応するAccess-要求とDigest-HA1属性の価値のDigest-一回だけ、Digestの一回だけのカウント、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受け入れているパケットがDigest応答AuthもDigest-HA1属性も含んでいないと、RADIUSクライアントはHTTPスタイル応答のためにAuthentication-インフォメーションヘッダーを創造しないでしょう。
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受け入れているパケットにDigest-Nextnonce属性を提供するとき、RADIUSクライアントは'nextnonce'指示にこの属性のコンテンツを入れます。 今、それはHTTPスタイル応答を送ることができます。
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.
RADIUSクライアントが局所的に構成された分野値に合っている(プロキシ)承認ヘッダーなしでHTTPスタイル要求を受け取ったなら、それは、新しい一回だけを得て、(プロキシ)を含んでいると認証される誤り応答(401か407)にヘッダーを送ります。
Sterman, et al. Standards Track [Page 8] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[8ページ]。
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.
Digest-一回だけ属性を含んで、RADIUSクライアントがAccess-要求に対応してAccess-挑戦パケットを受けるなら、RADIUSサーバは一回だけを受け入れませんでした。 Digest聞き古した属性がAccess-挑戦で存在していて、'本当(周囲の引用文のない)'の値を持っているなら、クライアントがWWW/を含む誤り応答(401か407)を送るRADIUSは指示が'聞き古したである'、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サーバからAccess-廃棄物を受け取るなら、それはそれが受け取った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クライアントには、一回だけを得る2つの方法があります: それが以前に容認されたAccess受け入れているパケットのDigest-Nextnonce属性で1を受け取ったか、またはそれはRADIUSサーバに1つを求めます。 Digest-メソッドとDigest-URI属性を含んでいますが、Digest-一回だけ属性なしで送って、後者をするために、それはAccess-要求を送ります。 それはMessage-固有識別文字([RFC3579]を見る)属性をAccess-リクエスト・パケットに加えます。 RADIUSサーバは、一回だけを選んで、Digest-一回だけ属性を含んでいて、Access-挑戦で反応します。
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.
(プロキシ)が容認されたDigest-一回だけとDigest-分野属性を使用しているヘッダーを認証するRADIUSクライアント構造物は一回だけと分野指示をいっぱいにしています。 RADIUSサーバで、Access-挑戦におけるDigest-Qop、Digest-アルゴリズム、Digest-ドメイン、およびDigest-不透明なもの属性は一回だけを運ぶことができます。 これらの属性が存在しているなら、クライアントはそれらを使用しなければなりません。
2.2. RADIUS Server Behavior
2.2. 半径サーバの振舞い
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-メソッドとDigest-URI属性にもかかわらず、Digest-一回だけ属性なしでAccess-リクエスト・パケットを受けるなら、それは一回だけを選びます。 それは、Digest-一回だけ属性に一回だけを入れて、Access-挑戦パケットでRADIUSクライアントにそれを送ります。 RADIUSサーバはDigest-分野、Digest-アルゴリズムと1Digest-Qop、および5月が、Digest-ドメインかDigest-不透明なものがAccess-挑戦パケットの結果と考えるとSHOULDが、言い足す言い足すMessage-固有識別文字([RFC3579]を見る)を加えなければなりません。
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-応答属性を含んでいて、RADIUSサーバがAccess-リクエスト・パケットを受けるなら、以下の属性を探します:
Sterman, et al. Standards Track [Page 9] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[9ページ]。
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、ダイジェストアルゴリズム、およびダイジェストユーザ名。 Digest-アルゴリズムとDigest-Qopの内容によって、それはDigest実体ボディーハッシュ、Digest-CNonce、およびDigest-AKA-Autsも探します。 詳細に関して[RFC2617]と[RFC3310]を見てください。 Digest-アルゴリズム属性がなくなるなら、'MD5'は想定されます。 RADIUSサーバが一回だけに伴うDigest不透明な属性を発行したなら、Access-要求には、合っているDigest不透明な属性がなければなりません。
If mandatory attributes are missing, it MUST respond with an Access-Reject packet.
義務的な属性がなくなるなら、それはAccess-廃棄物パケットで応じなければなりません。
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クライアントがDigest-分野属性で言及した分野のユーザに役立つのに権限を与えられるかどうかチェックしなければなりません。 RADIUSクライアントが認可されていないなら、RADIUSサーバはAccess-廃棄物を送らなければなりません。 RADIUSサーバSHOULDはオペレータに通知するためにイベントを登録します、そして、このクライアントからのすべての今後の要求に対応してAccess-廃棄物を送るのなどように追加措置を取るかもしれません、この振舞いが管理活動でリセットされるまで。
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-一回だけの一回だけの時代を測定します。 タイムスタンプを一回だけに埋め込むなら、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-要求メッセージが上で説明されたチェックを通過したなら、RADIUSサーバは[RFC2617]で説明されるようにダイジェスト応答について計算します。 パスワードを調べるために、RADIUSサーバはRADIUS User-名前属性を使用します。 RADIUSサーバは、ユーザがUser-名前で属性を特定したかどうかチェックしなければなりません。
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-廃棄物を送らなければなりません。
Sterman, et al. Standards Track [Page 10] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[10ページ]。
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.
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.
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.
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 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.
If the response values don't match, the RADIUS server responds with an Access-Reject.
2.2.3. Constructing the Reply
2.2.3. Constructing the Reply
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:
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' 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 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:
* The Digest-Algorithm attribute's value is 'MD5-sess' or
'AKAv1-MD5-sess'.
* 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 is configured to protect traffic between the RADIUS client and RADIUS server with IPsec (see Section 8).
In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be sent.
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 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.
Sterman, et al. Standards Track [Page 11] RFC 4590 RADIUS Digest Authentication July 2006
Sterman, et al. Standards Track [Page 11] RFC 4590 RADIUS Digest Authentication July 2006
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.
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.
3. New RADIUS Attributes
3. New RADIUS Attributes
If not stated otherwise, the attributes have the following format:
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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
realm="the \"example\" value"
realm="the \"example\" value"
is represented as follows:
is represented as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Digest-Realm | 23 | the \"example\" value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Digest-Realm | 23 | the \"example\" value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1. Digest-Response attribute
3.1. Digest-Response attribute
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
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
Sterman, et al. Standards Track [Page 12] RFC 4590 RADIUS Digest Authentication July 2006
Sterman, et al. Standards Track [Page 12] RFC 4590 RADIUS Digest Authentication July 2006
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.
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. Digest-Realm Attribute
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.
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.
3.3. Digest-Nonce Attribute
3.3. Digest-Nonce Attribute
Description
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.
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.
Sterman, et al. Standards Track [Page 13] RFC 4590 RADIUS Digest Authentication July 2006
Sterman, et al. Standards Track [Page 13] RFC 4590 RADIUS Digest Authentication July 2006
3.4. Digest-Response-Auth Attribute
3.4. Digest-Response-Auth Attribute
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.
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.
3.5. Digest-Nextnonce Attribute
3.5. Digest-Nextnonce Attribute
This attribute holds a nonce to be used in the HTTP Digest calculation.
This attribute holds a nonce to be used in the HTTP Digest calculation.
Description
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.
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.
3.6. Digest-Method Attribute
3.6. Digest-Method Attribute
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.
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.
Sterman, et al. Standards Track [Page 14] RFC 4590 RADIUS Digest Authentication July 2006
Sterman, et al. Standards Track [Page 14] RFC 4590 RADIUS Digest Authentication July 2006
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.
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.7. Digest-URI Attribute
3.7. Digest-URI Attribute
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.
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.
3.8. Digest-Qop Attribute
3.8. Digest-Qop Attribute
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
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
Sterman, et al. Standards Track [Page 15] RFC 4590 RADIUS Digest Authentication July 2006
Sterman, et al. Standards Track [Page 15] RFC 4590 RADIUS Digest Authentication July 2006
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-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. Digest-Algorithm Attribute
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.
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.
3.10. Digest-Entity-Body-Hash Attribute
3.10. Digest-Entity-Body-Hash Attribute
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.
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.
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
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
Sterman, et al. Standards Track [Page 16] RFC 4590 RADIUS Digest Authentication July 2006
Sterman, et al. Standards Track [Page 16] RFC 4590 RADIUS Digest Authentication July 2006
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.
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.
3.11. Digest-CNonce Attribute
3.11. Digest-CNonce Attribute
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.
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.
3.12. Digest-Nonce-Count Attribute
3.12. Digest-Nonce-Count Attribute
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.
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.
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.
3.13. Digest-Username Attribute
3.13. Digest-Username Attribute
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
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
Sterman, et al. Standards Track [Page 17] RFC 4590 RADIUS Digest Authentication July 2006
Sterman, et al. Standards Track [Page 17] RFC 4590 RADIUS Digest Authentication July 2006
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.
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.14. Digest-Opaque Attribute
3.14. Digest-Opaque Attribute
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.
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.
3.15. Digest-Auth-Param Attribute
3.15. Digest-Auth-Param Attribute
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.
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
packets.
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.
Sterman, et al. Standards Track [Page 18] RFC 4590 RADIUS Digest Authentication July 2006
Sterman, et al. Standards Track [Page 18] RFC 4590 RADIUS Digest Authentication July 2006
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.
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.
3.16. Digest-AKA-Auts Attribute
3.16. Digest-AKA-Auts Attribute
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.
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.
3.17. Digest-Domain Attribute
3.17. Digest-Domain Attribute
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.
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.
Sterman, et al. Standards Track [Page 19] RFC 4590 RADIUS Digest Authentication July 2006
Sterman, et al. Standards Track [Page 19] RFC 4590 RADIUS Digest Authentication July 2006
3.18. Digest-Stale Attribute
3.18. Digest-Stale Attribute
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).
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).
3.19. Digest-HA1 Attribute
3.19. Digest-HA1 Attribute
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'.
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'.
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).
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-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'.
+ 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 is configured to protect traffic between RADIUS client and RADIUS server with IPsec (see Section 8).
This attribute MUST only be used in Access-Accept packets.
Type
121 for Digest-HA1
Length
>= 3
This attribute MUST only be used in Access-Accept packets. Type 121 for Digest-HA1 Length >= 3
Sterman, et al. Standards Track [Page 20] RFC 4590 RADIUS Digest Authentication July 2006
Sterman, et al. Standards Track [Page 20] RFC 4590 RADIUS Digest Authentication July 2006
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.
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.
3.20. SIP-AOR Attribute
3.20. SIP-AOR Attribute
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]).
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]).
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.
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.
4. Diameter Compatibility
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.
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.
Sterman, et al. Standards Track [Page 21] RFC 4590 RADIUS Digest Authentication July 2006
Sterman, et al. Standards Track [Page 21] RFC 4590 RADIUS Digest Authentication July 2006
5. Table of Attributes
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.
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 | +-----+--------+--------+-----------+-----+-------------------------+
+-----+--------+--------+-----------+-----+-------------------------+ | Req| 受け入れてください。| 廃棄物| 挑戦| # | 属性| +-----+--------+--------+-----------+-----+-------------------------+ | 1 | 0 | 0 | 0 | 1 | ユーザ名| | 1 | 1 | 1 | 1 | 80 | メッセージ固有識別文字| | 0-1 | 0 | 0 | 0 | 103 | ダイジェスト応答| | 0-1 | 0 | 0 | 1 | 104 | ダイジェスト分野| | 0-1 | 0 | 0 | 1 | 105 | ダイジェスト一回だけです。| | 0 | 0-1 | 0 | 0 | 106 | ダイジェスト応答Auth| | | | | | | (注意1、2を見ます) | | 0 | 0-1 | 0 | 0 | 107 | ダイジェスト-Nextnonce| | 0-1 | 0 | 0 | 0 | 108 | ダイジェストメソッド| | 0-1 | 0 | 0 | 0 | 109 | ダイジェストURI| | 0-1 | 0 | 0 | 0+ | 110 | ダイジェスト-Qop| | 0-1 | 0 | 0 | 0-1 | 111 | ダイジェストアルゴリズム(| | | | | | | 注意3を見ます)| | 0-1 | 0 | 0 | 0 | 112 | ダイジェスト実体ボディーハッシュ| | 0-1 | 0 | 0 | 0 | 113 | ダイジェスト-CNonce| | 0-1 | 0 | 0 | 0 | 114 | ダイジェストの一回だけのカウント| | 0-1 | 0 | 0 | 0 | 115 | ダイジェストユーザ名| | 0-1 | 0 | 0 | 0-1 | 116 | ダイジェスト不透明です。| | 0+ | 0+ | 0 | 0+ | 117 | ダイジェスト-Auth-Param| | 0-1 | 0 | 0 | 0 | 118 | ダイジェスト別名Auts| | 0 | 0 | 0 | 0+ | 119 | ダイジェストドメイン| | 0 | 0 | 0 | 0-1 | 120 | ダイジェスト聞き古したです。| | 0 | 0-1 | 0 | 0 | 121 | ダイジェスト-HA1(| | | | | | | 注意1、2を見ます)| | 0-1 | 0 | 0 | 0 | 122 | 一口AOR| +-----+--------+--------+-----------+-----+-------------------------+
Table 1
テーブル1
[Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if
Digest-Qop is 'auth-int'.
[1]ダイジェスト-HA1 MUSTがDigest-Qopが'auth-int'であるならDigest応答Authの代わりに使用されることに注意してください。
[Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if
Digest-Qop is 'auth'.
Digest-Qopが'auth'であるならDigest-HA1の代わりに[注意2]ダイジェスト応答Authを使用しなければなりません。
[Note 3] If Digest-Algorithm is missing, 'MD5' is assumed.
[注意3] Digest-アルゴリズムがなくなるなら、'MD5'は想定されます。
Sterman, et al. Standards Track [Page 22] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[22ページ]。
6. Examples
6. 例
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)と、Proxyサーバ(B)と、example.com RADIUSサーバ(C)の間のトラフィックから選択された例です。 ProxyサーバとSIP Public Switched Telephone Network(PSTN)ゲートウェイとのコミュニケーションは簡潔さのために省略されます。 SIPメッセージは完全に示されるというわけではありません。
A->B
1>のB
INVITE sip:97226491335@example.com SIP/2.0
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
INVITE一口: 97226491335@example.com SIP/2.0From: <一口: 12345678@example.com 、gt;、To: <一口: 97226491335@example.com 、gt。
B->A
B>A
SIP/2.0 100 Trying
一口/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
=1(アクセス要求)属性をコード化してください: NAS IPアドレスがc0 0 2 26と等しい、(192.0.2.38)NASポートタイプ=5(仮想の)ユーザ名はINVITE Digest-URI=12345678Digest-メソッド=一口と等しいです: 97226491335@example.com Message-固有識別文字は08af 7e01b6 8d74c3 a4 3c33e1 56 2a80 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
コードは11(アクセス挑戦)の属性と等しいです: ダイジェスト一回だけ=3bada1a0 Digest-分野=example.com Digest-Qopはauth Digest-アルゴリズム=MD5 Message-固有識別文字=f8 01 26 9f70 5e ef 5d24ac f5 ca fb27da40と等しいです。
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
プロキシ認証が必要とした一口/2.0 407は以下をプロキシで認証します。 ダイジェスト分野は"example.com"と等しく、一回だけ=は「3bada1a0"、qop=auth、アルゴリズムはMD5 Content-長さと等しいです」です。 0
Sterman, et al. Standards Track [Page 23] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[23ページ]。
A->B
1>のB
ACK sip:97226491335@example.com SIP/2.0
ACK一口: 97226491335@example.com SIP/2.0
A->B
1>の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>
INVITE一口: 97226491335@example.com SIP/2.0Proxy-承認: ダイジェストアルゴリズムは「「12345678」、qop=auth、アルゴリズム=md5"、一回だけ=「: 3bada1a0"、分野="example.com"応答=「f3ce87e6984557cd0fecc26f3c5e97a4"、uri=」一口 97226491335@example.com 」ユーザ名=MD5From:」と等しいです。 <一口: 12345678@example.com 、gt;、To: <一口: 97226491335@example.com 、gt。
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
=1(アクセス要求)属性をコード化してください: NAS IPアドレスがc0 0 2 26と等しい、(192.0.2.38)NASポートタイプ=5(仮想の)ユーザ名はf3ce87e6984557cd0fecc26f3c5e97a4 Digest-分野=example.com Digest-一回だけ=3bada1a0 Digest-メソッド=INVITE Digest-URI=12345678Digest-応答=一口と等しいです: 97226491335@example.com Digest-Qopは12345678auth Digest-アルゴリズム=md5 Digest-ユーザ名=SIP-AOR=一口: 12345678@example.com Message-固有識別文字=ff67f4 13 8e b8 59 32 22f9 37 0f32f8 e0ffと等しいです。
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
コードは2つ(アクセスして受け入れる)の属性と等しいです: ダイジェスト応答Authは6303c41b0e2c3e524e413cafe8cce954 Message-固有識別文字=75 8d44 49 66 1f 7b47 9d10d0 2d 4a 2e aa f1と等しいです。
B->A
B>A
SIP/2.0 180 Ringing
一口/2.0 180の鳴ること
Sterman, et al. Standards Track [Page 24] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[24ページ]。
B->A
B>A
SIP/2.0 200 OK
一口/2.0 200OK
A->B
1>のB
ACK sip:97226491335@example.com SIP/2.0
ACK一口: 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番目の例はウェブブラウザ(A)と、ウェブサーバー(B)と、RADIUSサーバ(C)の間のトラフィックを示しています。
A->B
1>のB
GET /index.html HTTP/1.1
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
=1(アクセス要求)属性をコード化してください: NAS IPアドレスがc0 0 2 26と等しい、(192.0.2.38)NASポートタイプ=5(仮想)のダイジェストメソッド=GET Digest-URI index.html Message=/固有識別文字=34a6 26 46f3 81f9 b4 97c0 dd 9d11 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
コードは11(アクセス挑戦)の属性と等しいです: ダイジェスト一回だけ=a3086ac8 Digest-分野=example.com Digest-Qopはauth Digest-アルゴリズム=MD5 Message-固有識別文字=f8 01 26 9f70 5e ef 5d24ac f5 ca fb27da40と等しいです。
B->A
B>A
HTTP/1.1 401 Authentication Required
WWW-Authenticate: Digest realm="example.com",
nonce="a3086ac8",qop=auth,algorithm=MD5
Content-Length: 0
認証が必要としたHTTP/1.1 401は以下をWWW認証します。 ダイジェスト分野は"example.com"と等しく、一回だけ=は「a3086ac8"、qop=auth、アルゴリズムはMD5 Content-長さと等しいです」です。 0
Sterman, et al. Standards Track [Page 25] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[25ページ]。
A->B
1>の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
/index.html HTTP/1.1承認を得てください: 「12345678」、qop=auth、アルゴリズム=ダイジェストアルゴリズム=MD5、一回だけ=「a3086ac8"、分野="example.com"応答=「f052b68058b2987aba493857ae1ab002"、uri=」/index.html」ユーザ名=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
=1(アクセス要求)属性をコード化してください: NAS IPアドレスがc0 0 2 26と等しい、(192.0.2.38)NASポートタイプ=5(仮想の)ユーザ名はauth Digest-アルゴリズム=MD5 Message-固有識別文字=06e1 65 23 57 94e6 de87 5a e8Ce a2 7d43f052b68058b2987aba493857ae1ab002 Digest-分野=example.com Digest-一回だけ=a3086ac8 Digest-メソッド=GET Digest-URI index.html Digest=/ユーザ名=12345678 12345678Digest-応答=Digest-Qop=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
コードは2つ(アクセスして受け入れる)の属性と等しいです: ダイジェスト応答Authはe644aa513effbfe1caff67103ff6433c Message-固有識別文字=7a66 73a3 52 44dd ca90e2 f6 10 61 2d81d7と等しいです。
B->A
B>A
HTTP/1.1 200 OK
...
HTTP/1.1 200に、OK…
<html>
...
<html>…
Sterman, et al. Standards Track [Page 26] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[26ページ]。
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:
このドキュメントは多くの値を求めるIANA登録要求としてRADIUS属性タイプ数のスペースから機能します。 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 |
+-------------------------+------------------------+
+-------------------------+------------------------+ | プレースホルダ| IANAによって割り当てられた値| +-------------------------+------------------------+ | ダイジェスト応答| 103 | | ダイジェスト分野| 104 | | ダイジェスト一回だけです。| 105 | | ダイジェスト-Nextnonce| 106 | | ダイジェスト応答Auth| 107 | | ダイジェストメソッド| 108 | | ダイジェストURI| 109 | | ダイジェスト-Qop| 110 | | ダイジェストアルゴリズム| 111 | | ダイジェスト実体ボディーハッシュ| 112 | | ダイジェスト-CNonce| 113 | | ダイジェストの一回だけのカウント| 114 | | ダイジェストユーザ名| 115 | | ダイジェスト不透明です。| 116 | | ダイジェスト-Auth-Param| 117 | | ダイジェスト別名Auts| 118 | | ダイジェストドメイン| 119 | | ダイジェスト聞き古したです。| 120 | | ダイジェスト-HA1| 121 | | 一口AOR| 122 | +-------------------------+------------------------+
Table 2
テーブル2
8. Security Considerations
8. セキュリティ問題
The RADIUS extensions described in this document enable RADIUS to transport the data that is required to perform a digest calculation. As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see [RFC2617], section 4) in addition to RADIUS security vulnerabilities described in [RFC2865], section 8, and [RFC3579], section 4.
本書では説明されたRADIUS拡張子は、RADIUSがダイジェスト計算を実行するのに必要であるデータを輸送するのを可能にします。 その結果、RADIUSはセキュリティの脆弱性が[RFC2865]、セクション8で説明したRADIUS、および[RFC3579](セクション4)に加えてHTTP Digest([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.
TLSかIPsecと共にAとBとB、C(図2)の間の経路を保証したとしても、RADIUSクライアントかプロキシに感染する攻撃者は介入者攻撃を行うことができます。
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-分野属性をチェックしなければなりません。 RADIUSクライアントがその分野のHTTPスタイルクライアントに役立つのに権限を与えられないなら、それは感染されるかもしれません。
Sterman, et al. Standards Track [Page 27] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[27ページ]。
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.
本書では説明された拡大を実装するRADIUSクライアントはインターネットの上に受け取られたHTTPスタイル要求を認証するかもしれません。 リンクレイヤネットワークアクセスを認証するためにRADIUSの使用と比べて、攻撃者は、そのようなシナリオで証拠を隠すのが、より簡単であることがわかるかもしれません。
An attacker can attempt a denial-of-service attack on one or more RADIUS servers by sending a large number of HTTP-style requests. To make simple denial-of-service attacks more difficult, the RADIUS server MUST check whether it has generated the nonce received from an HTTP-style client. This SHOULD be done statelessly. For example, a nonce could consist of a cryptographically random part and some kind of signature provided by the RADIUS client, as described in [RFC2617], section 3.2.1.
攻撃者は、1つ以上のRADIUSサーバで多くのHTTPスタイル要求を送ることによって、サービス不能攻撃を試みることができます。 簡単なサービス不能攻撃をより難しくするように、RADIUSサーバは、それがHTTPスタイルクライアントから受け取られた一回だけを生成したかどうかチェックしなければなりません。 このSHOULD、状態がなくしてください。 例えば、一回だけはaから暗号で成ることができました。無作為の部分とある種の署名がRADIUSクライアントで提供しました、[RFC2617]、セクション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.
cleartextで本書では説明された属性を送ります。 RADIUSサーバSHOULDはAccess-挑戦メッセージにDigest-QopとDigest-アルゴリズム属性を含んでいます。 中央の男性は、攻撃の下側への入札でそれらの属性を変更するか、または取り除くことができます、RADIUSクライアントが意図するより弱い認証体系を使用することを引き起こして。
The Message-Authenticator attribute, described in [RFC3579], section 3.2 MUST be included in Access-Request, Access-Challenge, Access-Reject, and Access-Accept messages that contain attributes described in this specification.
[RFC3579]で説明されたMessage-固有識別文字属性、セクション3.2はAccess-要求、Access-挑戦、Access-廃棄物に含まれていて、この仕様で説明された属性を含むメッセージをAccess受け入れなければなりません。
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パケットの保護を必要とします。 実装SHOULDは、IPsecがRADIUSクライアントとRADIUSサーバの間のトラフィックを保護するために構成されるかどうか自動的に決定しようとします。これが可能でないなら、実装はIPsecがRADIUSトラフィックを保護するかどうかそれに言う設定パラメータをチェックします。 この設定パラメータのデフォルト値は、RADIUSパケットが保護されないと実装に言います。
HTTP-style clients can use TLS with server side certificates together with HTTP-Digest Authentication. Instead of TLS, IPsec can be used, too. TLS or IPsec secure the connection while Digest Authentication authenticates the user. The RADIUS transaction can be regarded as
HTTPスタイルクライアントはHTTPダイジェストAuthenticationと共にサーバサイド証明書があるTLSを使用できます。 また、TLSの代わりに、IPsecを使用できます。 Digest Authenticationがユーザを認証している間、TLSかIPsecが接続を保証します。 トランザクションを見なすことができるRADIUS
Sterman, et al. Standards Track [Page 28] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[28ページ]。
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:
1つはHTTPスタイルクライアントとHTTPスタイルサーバの間の経路を急いで歩きます。RADIUSが弱いリンクを表すのを防ぐのに、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の上のRADIUSは[RFC3579]、セクション4.2で説明された要件に従わなければなりません。
9. Acknowledgements
9. 承認
We would like to acknowledge Kevin McDermott (Cisco Systems) for providing comments and experimental implementation.
コメントと実験的な実装を提供するために、ケビン・マクダーモット(シスコシステムズ)を承認したいと思います。
Many thanks to all reviewers, especially to Miguel Garcia, Jari Arkko, Avi Lior, and Jun Wang.
特にすべての評論家と、そして、ミゲル・ガルシアと、ヤリArkkoと、アヴィLiorと、6月のワングをありがとうございます。
10. References
10. 参照
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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、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.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(2003年9月)。
Sterman, et al. Standards Track [Page 29] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[29ページ]。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004.
[RFC3966]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。
10.2. Informative References
10.2. 有益な参照
[SIP-APP] Garcia-Martin, M., "Diameter Session Initiation Protocol
(SIP) Application", Work in Progress), April 2006.
2006年4月の[一口装置] ガルシア-マーチン、M.、「直径セッション開始プロトコル(一口)アプリケーション」、処理中の作業)
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、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への拡大:」 「ダイジェストアクセス認証」、RFC2069、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.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[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メッセージ仕様」、RFC3851、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.
Torvinenと、[RFC3310] Niemi、A.、Arkko、J.、およびRFC3310、2002年9月対「認証を使用するハイパーテキスト転送プロトコル(HTTP)ダイジェスト認証と主要な協定(別名)」
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
Sterman, et al. Standards Track [Page 30] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[30ページ]。
Authors' Addresses
作者のアドレス
Baruch Sterman Kayote Networks P.O. Box 1373 Efrat 90435 Israel
バルク書Sterman Kayoteは私書箱1373Efrat90435イスラエルをネットワークでつなぎます。
EMail: baruch@kayote.com
メール: baruch@kayote.com
Daniel Sadolevsky SecureOL, Inc. Jerusalem Technology Park P.O. Box 16120 Jerusalem 91160 Israel
ダニエルSadolevsky SecureOL Inc.エルサレム技術公園私書箱16120エルサレム91160イスラエル
EMail: dscreat@dscreat.com
メール: dscreat@dscreat.com
David Schwartz Kayote Networks P.O. Box 1373 Efrat 90435 Israel
デヴィッドシュワルツKayoteは私書箱1373Efrat90435イスラエルをネットワークでつなぎます。
EMail: david@kayote.com
メール: david@kayote.com
David Williams Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park NC 27709 USA
7025年のデヴィッド・ウィリアムスシスコシステムズキットクリーク道路私書箱14987リサーチトライアングル公園NC27709米国
EMail: dwilli@cisco.com
メール: dwilli@cisco.com
Wolfgang Beck Deutsche Telekom AG Deutsche Telekom Allee 7 Darmstadt 64295 Germany
ウォルフギャングべックドイツ・テレコム株式会社ドイツ・テレコム並木道7ダルムシュタット64295ドイツ
EMail: beckw@t-systems.com
メール: beckw@t-systems.com
Sterman, et al. Standards Track [Page 31] RFC 4590 RADIUS Digest Authentication July 2006
Sterman、他 規格は半径ダイジェスト認証2006年7月にRFC4590を追跡します[31ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Sterman, et al. Standards Track [Page 32]
Sterman、他 標準化過程[32ページ]
一覧
スポンサーリンク
