RFC 6614 - Transport Layer Security (TLS) Encryption for RADIUS 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6614
タイトル : RFC 6614 - RADIUSのトランスポート層セキュリティ（TLS）暗号化
翻訳編集 : 自動生成

[要約] RFC 6614は、RADIUS (Remote Authentication Dial In User Service) プロトコルの通信を保護するために、Transport Layer Security (TLS) を使用する方法について定義しています。この文書の目的は、RADIUSサーバーとクライアント間のデータの機密性と完全性を確保することにあります。主に、認証やネットワークアクセス制御の文脈で利用されます。関連するRFCには、RFC 2865 (RADIUSの基本仕様) やRFC 2866 (RADIUSの会計)、RFC 5246 (TLS 1.2の仕様) などがあります。RFC 6614は、セキュリティを強化するためにRADIUS通信にTLSを適用する方法を提供します。

Internet Engineering Task Force (IETF)                         S. Winter
Request for Comments: 6614                                       RESTENA
Category: Experimental                                       M. McCauley
ISSN: 2070-1721                                                      OSC
                                                               S. Venaas
                                                             K. Wierenga
                                                                   Cisco
                                                                May 2012

Transport Layer Security (TLS) Encryption for RADIUS

RADIUSのトランスポート層セキュリティ（TLS）暗号化

Abstract

概要

This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers.

このドキュメントでは、トランスポートプロトコルとしてTCPを介したトランスポート層セキュリティ（TLS）を使用するRADIUSのトランスポートプロファイルを指定します。これにより、RADIUSサーバー間の動的な信頼関係が可能になります。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

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

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

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................3
      1.1. Requirements Language ......................................3
      1.2. Terminology ................................................4
      1.3. Document Status ............................................4
   2. Normative: Transport Layer Security for RADIUS/TCP ..............5
      2.1. TCP port and Packet Types ..................................5
      2.2. TLS Negotiation ............................................5
      2.3. Connection Setup ...........................................5
      2.4. Connecting Client Identity .................................7
      2.5. RADIUS Datagrams ...........................................8
   3. Informative: Design Decisions ..................................10
      3.1. Implications of Dynamic Peer Discovery ....................10
      3.2. X.509 Certificate Considerations ..........................10
      3.3. Ciphersuites and Compression Negotiation Considerations ...11
      3.4. RADIUS Datagram Considerations ............................11
   4. Compatibility with Other RADIUS Transports .....................12
   5. Diameter Compatibility .........................................13
   6. Security Considerations ........................................13
   7. IANA Considerations ............................................14
   8. Acknowledgements ...............................................15
   9. References .....................................................15
      9.1. Normative References ......................................15
      9.2. Informative References ....................................16
   Appendix A. Implementation Overview: Radiator .....................18
   Appendix B. Implementation Overview: radsecproxy ..................19
   Appendix C. Assessment of Crypto-Agility Requirements .............20

1. Introduction

1. はじめに

The RADIUS protocol [RFC2865] is a widely deployed authentication and authorization protocol. The supplementary RADIUS Accounting specification [RFC2866] provides accounting mechanisms, thus delivering a full Authentication, Authorization, and Accounting (AAA) solution. However, RADIUS is experiencing several shortcomings, such as its dependency on the unreliable transport protocol UDP and the lack of security for large parts of its packet payload. RADIUS security is based on the MD5 algorithm, which has been proven to be insecure.

RADIUSプロトコル[RFC2865]は、広く展開されている認証および承認プロトコルです。補足のRADIUSアカウンティング仕様[RFC2866]は、アカウンティングメカニズムを提供し、完全な認証、承認、アカウンティング（AAA）ソリューションを提供します。ただし、RADIUSには、信頼できないトランスポートプロトコルUDPへの依存や、パケットペイロードの大部分に対するセキュリティの欠如など、いくつかの欠点があります。 RADIUSセキュリティは、安全でないことが証明されているMD5アルゴリズムに基づいています。

The main focus of RADIUS over TLS is to provide a means to secure the communication between RADIUS/TCP peers using TLS. The most important use of this specification lies in roaming environments where RADIUS packets need to be transferred through different administrative domains and untrusted, potentially hostile networks. An example for a worldwide roaming environment that uses RADIUS over TLS to secure communication is "eduroam", see [eduroam].

RADIUS over TLSの主な焦点は、TLSを使用してRADIUS / TCPピア間の通信を保護する手段を提供することです。この仕様の最も重要な使用法は、RADIUSパケットをさまざまな管理ドメインと信頼できない、潜在的に敵対的なネットワークを介して転送する必要があるローミング環境にあります。 RADIUS over TLSを使用して通信を保護する世界的なローミング環境の例は、「eduroam」です。[eduroam]を参照してください。

There are multiple known attacks on the MD5 algorithm that is used in RADIUS to provide integrity protection and a limited confidentiality protection (see [MD5-attacks]). RADIUS over TLS wraps the entire RADIUS packet payload into a TLS stream and thus mitigates the risk of attacks on MD5.

整合性保護と限定された機密保護を提供するためにRADIUSで使用されるMD5アルゴリズムに対する複数の既知の攻撃があります（[MD5-attacks]を参照）。 RADIUS over TLSは、RADIUSパケットペイロード全体をTLSストリームにラップし、MD5への攻撃のリスクを軽減します。

Because of the static trust establishment between RADIUS peers (IP address and shared secret), the only scalable way of creating a massive deployment of RADIUS servers under the control of different administrative entities is to introduce some form of a proxy chain to route the access requests to their home server. This creates a lot of overhead in terms of possible points of failure, longer transmission times, as well as middleboxes through which authentication traffic flows. These middleboxes may learn privacy-relevant data while forwarding requests. The new features in RADIUS over TLS obsolete the use of IP addresses and shared MD5 secrets to identify other peers and thus allow the use of more contemporary trust models, e.g., checking a certificate by inspecting the issuer and other certificate properties.

RADIUSピア（IPアドレスと共有シークレット）間の静的な信頼確立のため、さまざまな管理エンティティの制御下でRADIUSサーバーの大規模な展開を作成する唯一のスケーラブルな方法は、アクセス要求をルーティングするプロキシチェーンの形式を導入することです彼らのホームサーバーに。これにより、考えられる障害点、長い伝送時間、認証トラフィックが流れるミドルボックスに関して、多くのオーバーヘッドが発生します。これらのミドルボックスは、リクエストの転送中にプライバシー関連のデータを学習する場合があります。 RADIUS over TLSの新機能により、IPアドレスと共有MD5シークレットの使用が廃止され、他のピアが識別されるため、発行者やその他の証明書のプロパティを検査して証明書をチェックするなど、より現代的な信頼モデルを使用できるようになります。

1.1. Requirements Language

1.1. 要件言語

In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

このドキュメントでは、仕様の要件を示すためにいくつかの単語が使用されています。キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。

1.2. Terminology

1.2. 用語

RADIUS/TLS node: a RADIUS-over-TLS client or server

RADIUS / TLSノード：RADIUS-over-TLSクライアントまたはサーバー

RADIUS/TLS Client: a RADIUS-over-TLS instance that initiates a new connection.

RADIUS / TLSクライアント：新しい接続を開始するRADIUS-over-TLSインスタンス。

RADIUS/TLS Server: a RADIUS-over-TLS instance that listens on a RADIUS-over-TLS port and accepts new connections

RADIUS / TLSサーバー：RADIUS-over-TLSポートでリッスンし、新しい接続を受け入れるRADIUS-over-TLSインスタンス

RADIUS/UDP: a classic RADIUS transport over UDP as defined in [RFC2865]

RADIUS / UDP：[RFC2865]で定義されているUDPを介した従来のRADIUSトランスポート

1.3. Document Status

1.3. ドキュメントのステータス

This document is an Experimental RFC.

このドキュメントは試験的なRFCです。

It is one out of several approaches to address known cryptographic weaknesses of the RADIUS protocol (see also Section 4). The specification does not fulfill all recommendations on a AAA transport profile as per [RFC3539]; in particular, by being based on TCP as a transport layer, it does not prevent head-of-line blocking issues.

これは、RADIUSプロトコルの既知の暗号化の弱点に対処するためのいくつかのアプローチの1つです（セクション4も参照）。この仕様は、[RFC3539]によるAAAトランスポートプロファイルのすべての推奨事項を満たしているわけではありません。特に、トランスポート層としてTCPに基づいているため、行頭ブロッキングの問題を防ぐことはできません。

If this specification is indeed selected for advancement to Standards Track, certificate verification options (Section 2.3, point 2) need to be refined.

この仕様が本当にスタンダードトラックへの移行のために選択された場合、証明書検証オプション（セクション2.3、ポイント2）を改良する必要があります。

Another experimental characteristic of this specification is the question of key management between RADIUS/TLS peers. RADIUS/UDP only allowed for manual key management, i.e., distribution of a shared secret between a client and a server. RADIUS/TLS allows manual distribution of long-term proofs of peer identity as well (by using TLS-PSK ciphersuites, or identifying clients by a certificate fingerprint), but as a new feature enables use of X.509 certificates in a PKIX infrastructure. It remains to be seen if one of these methods will prevail or if both will find their place in real-life deployments. The authors can imagine pre-shared keys (PSK) to be popular in small-scale deployments (Small Office, Home Office (SOHO) or isolated enterprise deployments) where scalability is not an issue and the deployment of a Certification Authority (CA) is considered too much of a hassle; however, the authors can also imagine large roaming consortia to make use of PKIX. Readers of this specification are encouraged to read the discussion of key management issues within [RFC6421] as well as [RFC4107].

この仕様の別の実験的特性は、RADIUS / TLSピア間のキー管理の問題です。 RADIUS / UDPは手動の鍵管理、つまりクライアントとサーバー間の共有シークレットの配布にのみ許可されています。 RADIUS / TLSを使用すると、（TLS-PSK暗号スイートを使用するか、証明書のフィンガープリントでクライアントを識別することにより）ピアIDの長期証明を手動で配布できますが、新しい機能として、PKIXインフラストラクチャでX.509証明書を使用できます。これらの方法のいずれかが普及するのか、それとも実際の展開で両方がその位置を見つけるのかはまだ分からない。作成者は、事前共有キー（PSK）が、スケーラビリティが問題ではなく、証明機関（CA）の展開が重要ではない小規模な展開（小規模オフィス、ホームオフィス（SOHO）、または独立したエンタープライズ展開）で人気があると想像できます。面倒すぎると考えました。ただし、著者はPKIXを利用するために大きなローミングコンソーシアムを想像することもできます。この仕様の読者は、[RFC6421]および[RFC4107]内の主要な管理問題の説明を読むことをお勧めします。

It has yet to be decided whether this approach is to be chosen for Standards Track. One key aspect to judge whether the approach is usable on a large scale is by observing the uptake, usability, and operational behavior of the protocol in large-scale, real-life deployments.

このアプローチをスタンダードトラックに採用するかどうかはまだ決定されていません。アプローチが大規模で使用可能かどうかを判断するための重要な側面の1つは、大規模な実際の展開におけるプロトコルの取り込み、使いやすさ、および動作の動作を観察することです。

An example for a worldwide roaming environment that uses RADIUS over TLS to secure communication is "eduroam", see [eduroam].

RADIUS over TLSを使用して通信を保護する世界的なローミング環境の例は、「eduroam」です。[eduroam]を参照してください。

2. Normative: Transport Layer Security for RADIUS/TCP

2. 標準：RADIUS / TCPのトランスポート層セキュリティ

2.1. TCP port and Packet Types

2.1. TCPポートとパケットタイプ

The default destination port number for RADIUS over TLS is TCP/2083. There are no separate ports for authentication, accounting, and dynamic authorization changes. The source port is arbitrary. See Section 3.4 for considerations regarding the separation of authentication, accounting, and dynamic authorization traffic.

RADIUS over TLSのデフォルトの宛先ポート番号はTCP / 2083です。認証、アカウンティング、および動的承認の変更に個別のポートはありません。送信元ポートは任意です。認証、アカウンティング、および動的承認トラフィックの分離に関する考慮事項については、3.4項を参照してください。

2.2. TLS Negotiation

2.2. TLSネゴシエーション

RADIUS/TLS has no notion of negotiating TLS in an established connection. Servers and clients need to be preconfigured to use RADIUS/TLS for a given endpoint.

RADIUS / TLSには、確立された接続でTLSをネゴシエートするという概念はありません。サーバーとクライアントは、特定のエンドポイントでRADIUS / TLSを使用するように事前構成する必要があります。

2.3. Connection Setup

2.3. 接続設定

RADIUS/TLS nodes

RADIUS / TLSノード

1. establish TCP connections as per [RFC6613]. Failure to connect leads to continuous retries, with exponentially growing intervals between every try. If multiple servers are defined, the node MAY attempt to establish a connection to these other servers in parallel, in order to implement quick failover.

1. [RFC6613]に従ってTCP接続を確立します。接続に失敗すると、再試行が連続的に行われ、試行の間隔が指数関数的に増加します。複数のサーバーが定義されている場合、ノードは迅速なフェイルオーバーを実装するために、これらの他のサーバーへの接続を並行して確立しようとする場合があります。

2. after completing the TCP handshake, immediately negotiate TLS sessions according to [RFC5246] or its predecessor TLS 1.1. The following restrictions apply:

2. TCPハンドシェイクが完了したら、[RFC5246]またはその前身のTLS 1.1に従って、TLSセッションを直ちにネゴシエートします。以下の制限が適用されます。

* Support for TLS v1.1 [RFC4346] or later (e.g., TLS 1.2 [RFC5246]) is REQUIRED. To prevent known attacks on TLS versions prior to 1.1, implementations MUST NOT negotiate TLS versions prior to 1.1.

* TLS v1.1 [RFC4346]以降（TLS 1.2 [RFC5246]など）のサポートが必要です。 1.1より前のTLSバージョンに対する既知の攻撃を防ぐために、実装は1.1より前のTLSバージョンをネゴシエートしてはなりません。

* Support for certificate-based mutual authentication is REQUIRED.

* 証明書ベースの相互認証のサポートが必要です。

* Negotiation of mutual authentication is REQUIRED.

* 相互認証の交渉が必要です。

* Negotiation of a ciphersuite providing for confidentiality as well as integrity protection is REQUIRED. Failure to comply with this requirement can lead to severe security problems, like user passwords being recoverable by third parties. See Section 6 for details.

* 機密性と完全性の保護を提供する暗号スイートの交渉が必要です。この要件を遵守しないと、サードパーティがユーザーパスワードを回復できるなど、深刻なセキュリティ問題が発生する可能性があります。詳細については、セクション6を参照してください。

* Support for and negotiation of compression is OPTIONAL.

* 圧縮のサポートとネゴシエーションはオプションです。

* Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL.

* TLS-PSK相互認証[RFC4279]のサポートはオプションです。

* RADIUS/TLS implementations MUST, at a minimum, support negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA, and SHOULD support TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3.

* RADIUS / TLS実装は、最低でもTLS_RSA_WITH_3DES_EDE_CBC_SHAのネゴシエーションをサポートする必要があり、SHOULDはTLS_RSA_WITH_RC4_128_SHAおよびTLS_RSA_WITH_AES_128_CBC_SHAもサポートする必要があります（セクション3.3を参照）。

* In addition, RADIUS/TLS implementations MUST support negotiation of the mandatory-to-implement ciphersuites required by the versions of TLS that they support.

* さらに、RADIUS / TLS実装は、それらがサポートするTLSのバージョンで必要な実装から必須の暗号スイートのネゴシエーションをサポートする必要があります。

3. Peer authentication can be performed in any of the following three operation models:

3. ピア認証は、次の3つの操作モデルのいずれかで実行できます。

* TLS with X.509 certificates using PKIX trust models (this model is mandatory to implement):

* PKIX信頼モデルを使用したX.509証明書を使用したTLS（このモデルの実装は必須です）：

+ Implementations MUST allow the configuration of a list of trusted Certification Authorities for incoming connections.

+ 実装では、着信接続用の信頼できる認証局のリストの構成を許可する必要があります。

+ Certificate validation MUST include the verification rules as per [RFC5280].

+ 証明書の検証には、[RFC5280]による検証ルールを含める必要があります。

+ Implementations SHOULD indicate their trusted Certification Authorities (CAs). For TLS 1.2, this is done using [RFC5246], Section 7.4.4, "certificate_authorities" (server side) and [RFC6066], Section 6 "Trusted CA Indication" (client side). See also Section 3.2.

+ 実装は、信頼できる認証局（CA）を示す必要があります（SHOULD）。 TLS 1.2の場合、これは[RFC5246]、セクション7.4.4、「certificate_authorities」（サーバー側）と[RFC6066]、セクション6「信頼できるCA表示」（クライアント側）を使用して行われます。セクション3.2も参照してください。

+ Peer validation always includes a check on whether the locally configured expected DNS name or IP address of the server that is contacted matches its presented certificate. DNS names and IP addresses can be contained in the Common Name (CN) or subjectAltName entries. For verification, only one of these entries is to be considered. The following precedence applies: for DNS name validation, subjectAltName:DNS has precedence over CN; for IP address validation, subjectAltName:iPAddr has precedence over CN.

+ ピアの検証には、接続されているサーバーのローカルに構成された予期されるDNS名またはIPアドレスが、提示された証明書と一致するかどうかのチェックが常に含まれます。 DNS名とIPアドレスは、共通名（CN）またはsubjectAltNameエントリに含めることができます。確認のために、これらのエントリの1つだけが考慮されます。次の優先順位が適用されます。DNS名の検証では、subjectAltName：DNSがCNよりも優先されます。 IPアドレスの検証では、subjectAltName：iPAddrがCNよりも優先されます。

Implementors of this specification are advised to read [RFC6125], Section 6, for more details on DNS name validation.

この仕様の実装者は、DNS名の検証の詳細について、[RFC6125]、セクション6を読むことをお勧めします。

+ Implementations MAY allow the configuration of a set of additional properties of the certificate to check for a peer's authorization to communicate (e.g., a set of allowed values in subjectAltName:URI or a set of allowed X509v3 Certificate Policies).

+ 実装は、通信のピアの承認をチェックするために証明書の追加プロパティのセットの構成を許可する場合があります（たとえば、subjectAltName：URIの許可された値のセットまたは許可されたX509v3証明書ポリシーのセット）。

+ When the configured trust base changes (e.g., removal of a CA from the list of trusted CAs; issuance of a new CRL for a given CA), implementations MAY renegotiate the TLS session to reassess the connecting peer's continued authorization.

+ 構成された信頼ベースが変更された場合（信頼されたCAのリストからのCAの削除、特定のCAの新しいCRLの発行など）、実装はTLSセッションを再ネゴシエートして、接続ピアの継続的な承認を再評価できます（MAY）。

* TLS with X.509 certificates using certificate fingerprints (this model is optional to implement): Implementations SHOULD allow the configuration of a list of trusted certificates, identified via fingerprint of the DER encoded certificate octets. Implementations MUST support SHA-1 as the hash algorithm for the fingerprint. To prevent attacks based on hash collisions, support for a more contemporary hash function such as SHA-256 is RECOMMENDED.

* 証明書のフィンガープリントを使用するX.509証明書を使用したTLS（このモデルは実装するかどうかはオプションです）：実装では、DERエンコードされた証明書オクテットのフィンガープリントで識別される、信頼できる証明書のリストの構成を許可する必要があります。実装は、指紋のハッシュアルゴリズムとしてSHA-1をサポートする必要があります。ハッシュの衝突に基づく攻撃を防ぐために、SHA-256などのより現代的なハッシュ関数のサポートをお勧めします。

* TLS using TLS-PSK (this model is optional to implement).

* TLS-PSKを使用したTLS（このモデルの実装はオプションです）。

4. start exchanging RADIUS datagrams (note Section 3.4 (1)). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see Section 3.4 (2)).

4. RADIUSデータグラムの交換を開始します（セクション3.4（1）に注意）。（廃止された）MD5整合性チェックと属性暗号化を計算するための共有秘密は、「radsec」でなければなりません（セクション3.4（2）を参照）。

2.4. Connecting Client Identity

2.4. クライアントIDの接続

In RADIUS/UDP, clients are uniquely identified by their IP address. Since the shared secret is associated with the origin IP address, if more than one RADIUS client is associated with the same IP address, then those clients also must utilize the same shared secret, a practice that is inherently insecure, as noted in [RFC5247].

RADIUS / UDPでは、クライアントはIPアドレスによって一意に識別されます。共有シークレットは元のIPアドレスに関連付けられているため、複数のRADIUSクライアントが同じIPアドレスに関連付けられている場合、それらのクライアントも同じ共有シークレットを使用する必要があります。これは、[RFC5247]で述べられているように、本質的に安全でない方法です。。

RADIUS/TLS supports multiple operation modes.

RADIUS / TLSは複数の操作モードをサポートしています。

In TLS-PSK operation, a client is uniquely identified by its TLS identifier.

TLS-PSK操作では、クライアントはそのTLS識別子によって一意に識別されます。

In TLS-X.509 mode using fingerprints, a client is uniquely identified by the fingerprint of the presented client certificate.

フィンガープリントを使用するTLS-X.509モードでは、クライアントは提示されたクライアント証明書のフィンガープリントによって一意に識別されます。

In TLS-X.509 mode using PKIX trust models, a client is uniquely identified by the tuple (serial number of presented client certificate;Issuer).

PKIX信頼モデルを使用したTLS-X.509モードでは、クライアントはタプル（提示されたクライアント証明書のシリアル番号、発行者）によって一意に識別されます。

Note well: having identified a connecting entity does not mean the server necessarily wants to communicate with that client. For example, if the Issuer is not in a trusted set of Issuers, the server may decline to perform RADIUS transactions with this client.

よく注意してください。接続しているエンティティを識別しても、サーバーがそのクライアントとの通信を必要としているとは限りません。たとえば、発行者が発行者の信頼されたセットに含まれていない場合、サーバーはこのクライアントとのRADIUSトランザクションの実行を拒否することがあります。

There are numerous trust models in PKIX environments, and it is beyond the scope of this document to define how a particular deployment determines whether a client is trustworthy. Implementations that want to support a wide variety of trust models should expose as many details of the presented certificate to the administrator as possible so that the trust model can be implemented by the administrator. As a suggestion, at least the following parameters of the X.509 client certificate should be exposed:

PKIX環境には多数の信頼モデルがあり、特定の展開がクライアントが信頼できるかどうかをどのように決定するかを定義することは、このドキュメントの範囲を超えています。さまざまな信頼モデルをサポートする実装では、管理者が信頼モデルを実装できるように、提示された証明書の詳細をできるだけ多く管理者に公開する必要があります。提案として、X.509クライアント証明書の少なくとも以下のパラメーターを公開する必要があります。

o Originating IP address

o 発信元IPアドレス

o Certificate Fingerprint

o 証明書の指紋

o Issuer

o 発行者

o Subject

o 件名

o all X509v3 Extended Key Usage

o すべてのX509v3拡張キーの使用法

o all X509v3 Subject Alternative Name

o すべてのX509v3サブジェクトの別名

o all X509v3 Certificate Policies

o すべてのX509v3証明書ポリシー

In TLS-PSK operation, at least the following parameters of the TLS connection should be exposed:

TLS-PSK操作では、TLS接続の少なくとも以下のパラメーターを公開する必要があります。

o Originating IP address

o 発信元IPアドレス

o TLS Identifier

o TLS識別子

2.5. RADIUS Datagrams

2.5. RADIUSデータグラム

Authentication, Authorization, and Accounting packets are sent according to the following rules:

認証、承認、およびアカウンティングパケットは、次のルールに従って送信されます。

RADIUS/TLS clients transmit the same packet types on the connection they initiated as a RADIUS/UDP client would (see Section 3.4 (3) and (4)). For example, they send o Access-Request

RADIUS / TLSクライアントは、RADIUS / UDPクライアントと同様に、開始した接続で同じパケットタイプを送信します（セクション3.4（3）および（4）を参照）。たとえば、Access-Requestを送信します

o Accounting-Request

o Status-Server

o ステータスサーバー

o Disconnect-ACK

o Disconnect-NAK

o 切断-NAK

o ...

o 。。。

and they receive

そして彼らは受け取る

o Access-Accept

o アクセス許可

o Accounting-Response

o 会計対応

o Disconnect-Request

o 切断要求

o ...

o 。。。

RADIUS/TLS servers transmit the same packet types on connections they have accepted as a RADIUS/UDP server would. For example, they send

RADIUS / TLSサーバーは、RADIUS / UDPサーバーと同じように、受け入れた接続で同じパケットタイプを送信します。たとえば、彼らは送信します

o Access-Challenge

o アクセスチャレンジ

o Access-Accept

o アクセス許可

o Access-Reject

o アクセス拒否

o Accounting-Response

o 会計対応

o Disconnect-Request

o 切断要求

o ...

o 。。。

and they receive

そして彼らは受け取る

o Access-Request

o アクセス要求

o Accounting-Request

o Status-Server

o ステータスサーバー

o Disconnect-ACK

o ...

o 。。。

Due to the use of one single TCP port for all packet types, it is required that a RADIUS/TLS server signal which types of packets are supported on a server to a connecting peer. See also Section 3.4 for a discussion of signaling.

すべてのパケットタイプに単一のTCPポートを使用するため、RADIUS / TLSサーバーは、サーバーでサポートされているパケットのタイプを接続ピアに通知する必要があります。シグナリングの説明については、セクション3.4も参照してください。

o When an unwanted packet of type 'CoA-Request' or 'Disconnect-Request' is received, a RADIUS/TLS server needs to respond with a 'CoA-NAK' or 'Disconnect-NAK', respectively. The NAK SHOULD contain an attribute Error-Cause with the value 406 ("Unsupported Extension"); see [RFC5176] for details.

o タイプ「CoA-Request」または「Disconnect-Request」の不要なパケットが受信されると、RADIUS / TLSサーバーはそれぞれ「CoA-NAK」または「Disconnect-NAK」で応答する必要があります。 NAKには、値406（「サポートされていない拡張子」）の属性Error-Causeが含まれている必要があります（SHOULD）。詳細については、[RFC5176]を参照してください。

o When an unwanted packet of type 'Accounting-Request' is received, the RADIUS/TLS server SHOULD reply with an Accounting-Response containing an Error-Cause attribute with value 406 "Unsupported Extension" as defined in [RFC5176]. A RADIUS/TLS accounting client receiving such an Accounting-Response SHOULD log the error and stop sending Accounting-Request packets.

o タイプ「Accounting-Request」の不要なパケットが受信されると、RADIUS / TLSサーバーは、[RFC5176]で定義されている値406 "Unsupported Extension"のError-Cause属性を含むAccounting-Responseで応答する必要があります（SHOULD）。このようなアカウンティング応答を受信するRADIUS / TLSアカウンティングクライアントは、エラーをログに記録して、アカウンティング要求パケットの送信を停止する必要があります（SHOULD）。

3. Informative: Design Decisions

3. 参考情報：設計上の決定

This section explains the design decisions that led to the rules defined in the previous section.

このセクションでは、前のセクションで定義されたルールにつながる設計上の決定について説明します。

3.1. Implications of Dynamic Peer Discovery

3.1. 動的ピア検出の影響

One mechanism to discover RADIUS-over-TLS peers dynamically via DNS is specified in [DYNAMIC]. While this mechanism is still under development and therefore is not a normative dependency of RADIUS/ TLS, the use of dynamic discovery has potential future implications that are important to understand.

DNSを介してRADIUS-over-TLSピアを動的に検出するメカニズムの1つは、[DYNAMIC]で指定されています。このメカニズムはまだ開発中であるため、RADIUS / TLSの標準的な依存関係ではありませんが、動的検出の使用には、理解することが重要である潜在的な将来の影響があります。

Readers of this document who are considering the deployment of DNS-based dynamic discovery are thus encouraged to read [DYNAMIC] and follow its future development.

このドキュメントの読者は、DNSベースの動的検出の導入を検討しているため、[動的]を読んで、今後の開発をフォローすることをお勧めします。

3.2. X.509 Certificate Considerations

3.2. X.509証明書に関する考慮事項

(1) If a RADIUS/TLS client is in possession of multiple certificates from different CAs (i.e., is part of multiple roaming consortia) and dynamic discovery is used, the discovery mechanism possibly does not yield sufficient information to identify the consortium uniquely (e.g., DNS discovery). Subsequently, the client may not know by itself which client certificate to use for the TLS handshake. Then, it is necessary for the server to signal to which consortium it belongs and which certificates it expects. If there is no risk of confusing multiple roaming consortia, providing this information in the handshake is not crucial.

（1）RADIUS / TLSクライアントが異なるCAからの複数の証明書を所有しており（つまり、複数のローミングコンソーシアムの一部である）、動的検出が使用されている場合、検出メカニズムはコンソーシアムを一意に識別するのに十分な情報を提供しない可能性があります（例：、DNS検出）。その後、クライアントは、TLSハンドシェイクに使用するクライアント証明書をそれ自体では知らない可能性があります。次に、サーバーは、所属するコンソーシアムと予想される証明書に信号を送る必要があります。複数のローミングコンソーシアムを混乱させるリスクがない場合、ハンドシェイクでこの情報を提供することは重要ではありません。

(2) If a RADIUS/TLS server is in possession of multiple certificates from different CAs (i.e., is part of multiple roaming consortia), it will need to select one of its certificates to present to the RADIUS/TLS client. If the client sends the Trusted CA Indication, this hint can make the server select the appropriate certificate and prevent a handshake failure. Omitting this indication makes it impossible to deterministically select the right certificate in this case. If there is no risk of confusing multiple roaming consortia, providing this indication in the handshake is not crucial.

（2）RADIUS / TLSサーバーが異なるCAからの複数の証明書を所有している場合（つまり、複数のローミングコンソーシアムの一部である場合）、RADIUS / TLSクライアントに提示する証明書の1つを選択する必要があります。クライアントがTrusted CA Indicationを送信する場合、このヒントはサーバーに適切な証明書を選択させ、ハンドシェイクの失敗を防ぐことができます。この表示を省略すると、この場合、正しい証明書を確定的に選択することができなくなります。複数のローミングコンソーシアムを混乱させるリスクがない場合、ハンドシェイクでこの表示を提供することは重要ではありません。

3.3. Ciphersuites and Compression Negotiation Considerations

3.3. 暗号スイートと圧縮交渉の考慮事項

Not all TLS ciphersuites in [RFC5246] are supported by available TLS tool kits, and licenses may be required in some cases. The existing implementations of RADIUS/TLS use OpenSSL as a cryptographic backend, which supports all of the ciphersuites listed in the rules in the normative section.

[RFC5246]のすべてのTLS暗号スイートが、利用可能なTLSツールキットでサポートされているわけではなく、場合によってはライセンスが必要になることがあります。 RADIUS / TLSの既存の実装では、OpenSSLを暗号化バックエンドとして使用します。これは、規範セクションのルールにリストされているすべての暗号スイートをサポートします。

The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory to implement according to [RFC4346]; thus, it has to be supported by RADIUS/TLS nodes.

[RFC4346]に従って実装するには、TLS暗号スイートTLS_RSA_WITH_3DES_EDE_CBC_SHAが必須です。したがって、RADIUS / TLSノードでサポートされる必要があります。

The two other ciphersuites in the normative section are widely implemented in TLS tool kits and are considered good practice to implement.

規範セクションにある他の2つの暗号スイートは、TLSツールキットで広く実装されており、実装するのに適した方法と見なされています。

3.4. RADIUS Datagram Considerations

3.4. RADIUSデータグラムの考慮事項

(1) After the TLS session is established, RADIUS packet payloads are exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet size can be determined by evaluating the size of the datagram that arrived. Due to the stream nature of TCP and TLS, this does not hold true for RADIUS/TLS packet exchange. Instead, packet boundaries of RADIUS packets that arrive in the stream are calculated by evaluating the packet's Length field. Special care needs to be taken on the packet sender side that the value of the Length field is indeed correct before sending it over the TLS tunnel, because incorrect packet lengths can no longer be detected by a differing datagram boundary. See Section 2.6.4 of [RFC6613] for more details.

（1）TLSセッションが確立された後、RADIUSパケットのペイロードが暗号化されたTLSトンネルを介して交換されます。 RADIUS / UDPでは、パケットサイズは、到着したデータグラムのサイズを評価することによって決定できます。 TCPとTLSのストリームの性質により、これはRADIUS / TLSパケット交換には当てはまりません。代わりに、ストリームに到着するRADIUSパケットのパケット境界は、パケットの長さフィールドを評価することによって計算されます。パケットセンダー側では、TLSトンネルを介して送信する前に、Lengthフィールドの値が実際に正しいことに特別な注意を払う必要があります。これは、異なるデータグラム境界で誤ったパケット長を検出できないためです。詳細については、[RFC6613]のセクション2.6.4を参照してください。

(2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding attributes such as User-Password, as well as in computation of the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computation of both the Request Authenticator and the Response Authenticator. Since TLS provides integrity protection and encryption sufficient to substitute for RADIUS application-layer security, it is not necessary to configure a RADIUS shared secret. The use of a fixed string for the obsolete shared secret eliminates possible node misconfigurations.

（2）RADIUS / UDP [RFC2865]内では、共有シークレットを使用して、ユーザーパスワードなどの属性を非表示にしたり、応答オーセンティケーターを計算したりします。 RADIUSアカウンティング[RFC2866]では、共有シークレットは、要求オーセンティケーターと応答オーセンティケーターの両方の計算に使用されます。 TLSは、RADIUSアプリケーション層セキュリティの代わりに十分な整合性保護と暗号化を提供するため、RADIUS共有シークレットを構成する必要はありません。廃止された共有シークレットに固定文字列を使用することで、ノードの誤設定の可能性がなくなります。

(3) RADIUS/UDP [RFC2865] uses different UDP ports for authentication, accounting, and dynamic authorization changes. RADIUS/TLS allocates a single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS, the notion of a client that sends authentication requests and processes replies associated with its users' sessions and the notion of a server that receives requests, processes them, and sends the appropriate replies is to be preserved. The normative rules about acceptable packet types for clients and servers mirror the packet flow behavior from RADIUS/UDP.

（3）RADIUS / UDP [RFC2865]は、認証、アカウンティング、動的承認の変更に異なるUDPポートを使用します。 RADIUS / TLSは、すべてのRADIUSパケットタイプに単一のポートを割り当てます。それでも、RADIUS / TLSでは、認証要求を送信してユーザーのセッションに関連付けられた応答を処理するクライアントの概念と、要求を受信して処理し、適切な応答を送信するサーバーの概念が維持されます。クライアントとサーバーの受け入れ可能なパケットタイプに関する規範的なルールは、RADIUS / UDPからのパケットフローの動作を反映しています。

(4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support the reception and processing of the packet types in [RFC5176]. These packet types are listed as to be received in RADIUS/TLS implementations. Note well: it is not required for an implementation to actually process these packet types; it is only required that the NAK be sent as defined above.

（4）RADIUS / UDP [RFC2865]は、新しく割り当てられたUDPポートへの負のICMP応答を使用して、ピアRADIUSサーバーが[RFC5176]のパケットタイプの受信と処理をサポートしていないことを通知します。これらのパケットタイプは、RADIUS / TLS実装で受信されるものとしてリストされています。よく注意してください。実装がこれらのパケットタイプを実際に処理する必要はありません。上記で定義されたとおりにNAKが送信されることのみが必要です。

(5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support the reception and processing of RADIUS Accounting packets. There is no RADIUS datagram to signal an Accounting NAK. Clients may be misconfigured for sending Accounting packets to a RADIUS/TLS server that does not wish to process their Accounting packet. To prevent a regression of detectability of this situation, the Accounting-Response + Error-Cause signaling was introduced.

（5）RADIUS / UDP [RFC2865]は、新しく割り当てられたUDPポートへの負のICMP応答を使用して、ピアRADIUSサーバーがRADIUSアカウンティングパケットの受信と処理をサポートしていないことを通知します。アカウンティングNAKを通知するRADIUSデータグラムはありません。クライアントは、アカウンティングパケットを処理しないRADIUS / TLSサーバーにアカウンティングパケットを送信するように誤って構成されている可能性があります。この状況の検出可能性の低下を防ぐために、Accounting-Response + Error-Causeシグナリングが導入されました。

4. Compatibility with Other RADIUS Transports

4. 他のRADIUSトランスポートとの互換性

The IETF defines multiple alternative transports to the classic UDP transport model as defined in [RFC2865], namely RADIUS over TCP [RFC6613] and the present document on RADIUS over TLS. The IETF also proposed RADIUS over Datagram Transport Layer Security (DTLS) [RADEXT-DTLS].

IETFは、[RFC2865]で定義されている従来のUDPトランスポートモデルに対する複数の代替トランスポート、つまりRADIUS over TCP [RFC6613]とRADIUS over TLSに関する現在のドキュメントを定義しています。 IETFは、RADIUS over Datagram Transport Layer Security（DTLS）[RADEXT-DTLS]も提案しました。

RADIUS/TLS does not specify any inherent backward compatibility to RADIUS/UDP or cross compatibility to the other transports, i.e., an implementation that utilizes RADIUS/TLS only will not be able to receive or send RADIUS packet payloads over other transports. An implementation wishing to be backward or cross compatible (i.e., wishes to serve clients using other transports than RADIUS/TLS) will need to implement these other transports along with the RADIUS/TLS transport and be prepared to send and receive on all implemented transports, which is called a "multi-stack implementation".

RADIUS / TLSは、RADIUS / UDPに対する固有の下位互換性や他のトランスポートとの相互互換性を指定していません。つまり、RADIUS / TLSのみを使用する実装は、他のトランスポートを介してRADIUSパケットペイロードを送受信できません。下位互換性または相互互換性が必要な実装（つまり、RADIUS / TLS以外のトランスポートを使用するクライアントにサービスを提供したい）は、RADIUS / TLSトランスポートとともにこれらの他のトランスポートを実装し、実装されたすべてのトランスポートで送受信できるように準備する必要があります。これは「マルチスタック実装」と呼ばれます。

If a given IP device is able to receive RADIUS payloads on multiple transports, this may or may not be the same instance of software, and it may or may not serve the same purposes. It is not safe to assume that both ports are interchangeable. In particular, it cannot be assumed that state is maintained for the packet payloads between the transports. Two such instances MUST be considered separate RADIUS server entities.

特定のIPデバイスが複数のトランスポートでRADIUSペイロードを受信できる場合、これはソフトウェアの同じインスタンスである場合とそうでない場合があり、同じ目的で機能する場合と機能しない場合があります。両方のポートが交換可能であると想定するのは安全ではありません。特に、トランスポート間のパケットペイロードの状態が維持されるとは想定できません。そのような2つのインスタンスは、別個のRADIUSサーバーエンティティと見なす必要があります。

5. Diameter Compatibility

5. 直径の互換性

Since RADIUS/TLS is only a new transport profile for RADIUS, the compatibility of RADIUS/TLS - Diameter [RFC3588] and RADIUS/UDP [RFC2865] - Diameter [RFC3588] is identical. The considerations regarding payload size in [RFC6613] apply.

RADIUS / TLSはRADIUSの新しいトランスポートプロファイルにすぎないため、RADIUS / TLS-Diameter [RFC3588]とRADIUS / UDP [RFC2865]-Diameter [RFC3588]の互換性は同じです。 [RFC6613]のペイロードサイズに関する考慮事項が適用されます。

6. Security Considerations

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

The computational resources to establish a TLS tunnel are significantly higher than simply sending mostly unencrypted UDP datagrams. Therefore, clients connecting to a RADIUS/TLS node will more easily create high load conditions and a malicious client might create a Denial-of-Service attack more easily.

TLSトンネルを確立するための計算リソースは、単純にほとんど暗号化されていないUDPデータグラムを送信するよりもはるかに多くなります。したがって、RADIUS / TLSノードに接続するクライアントは高負荷状態をより簡単に作成し、悪意のあるクライアントはサービス拒否攻撃をより簡単に作成する可能性があります。

Some TLS ciphersuites only provide integrity validation of their payload, and provide no encryption. This specification forbids the use of such ciphersuites. Since the RADIUS payload's shared secret is fixed to the well-known term "radsec" (see Section 2.3 (4)), failure to comply with this requirement will expose the entire datagram payload in plaintext, including User-Password, to intermediate IP nodes.

一部のTLS暗号スイートは、ペイロードの整合性検証のみを提供し、暗号化を提供しません。この仕様では、このような暗号スイートの使用を禁止しています。 RADIUSペイロードの共有シークレットは、よく知られている用語「radsec」に固定されているため（セクション2.3（4）を参照）、この要件に準拠しないと、データグラムペイロード全体がユーザーパスワードを含むプレーンテキストで中間IPノードに公開されます。。

By virtue of being based on TCP, there are several generic attack vectors to slow down or prevent the TCP connection from being established; see [RFC4953] for details. If a TCP connection is not up when a packet is to be processed, it gets re-established, so such attacks in general lead only to a minor performance degradation (the time it takes to re-establish the connection). There is one notable exception where an attacker might create a bidding-down attack though. If peer communication between two devices is configured for both RADIUS/TLS (i.e., TLS security over TCP as a transport, shared secret fixed to "radsec") and RADIUS/UDP (i.e., shared secret security with a secret manually configured by the administrator), and the RADIUS/UDP transport is the failover option if the TLS session cannot be established, a bidding-down attack can occur if an adversary can maliciously close the TCP connection or prevent it from being established. Situations where clients are configured in such a way are likely to occur during a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker can reduce the security of the packet payload from the selected TLS ciphersuite packet encryption to the classic MD5 per-attribute encryption. The situation should be avoided by disabling the weaker RADIUS/UDP transport as soon as the new RADIUS/TLS connection is established and tested. Disabling can happen at either the RADIUS client or server side:

TCPに基づいているため、TCP接続の確立を遅くしたり妨げたりする一般的な攻撃方法がいくつかあります。詳細については、[RFC4953]を参照してください。パケットが処理されるときにTCP接続がアップしていない場合、TCP接続は再確立されるため、このような攻撃は一般に、パフォーマンスのわずかな低下（接続の再確立にかかる時間）のみをもたらします。ただし、攻撃者がビッドダウン攻撃を行う可能性のある注目すべき例外が1つあります。 2つのデバイス間のピア通信がRADIUS / TLS（つまり、トランスポートとしてのTCPを介したTLSセキュリティ、「radsec」に固定された共有シークレット）とRADIUS / UDP（つまり、管理者が手動で設定したシークレットを使用した共有シークレットセキュリティ）の両方に対して構成されている場合）、およびTLSセッションを確立できない場合、RADIUS / UDPトランスポートはフェイルオーバーオプションであり、攻撃者が悪意を持ってTCP接続を閉じたり、確立を妨害したりすると、入札停止攻撃が発生する可能性があります。クライアントがこのように構成されている状況は、RADIUS / UDPからRADIUS / TLSへの移行フェーズ中に発生する可能性があります。攻撃者はTLSセッションのセットアップを防ぐことにより、選択したTLS ciphersuiteパケット暗号化から従来のMD5属性ごとの暗号化にパケットペイロードのセキュリティを下げることができます。新しいRADIUS / TLS接続が確立されてテストされたらすぐに、より弱いRADIUS / UDPトランスポートを無効にすることで、この状況を回避する必要があります。無効化は、RADIUSクライアント側またはサーバー側で発生する可能性があります。

o Client side: de-configure the failover setup, leaving RADIUS/TLS as the only communication option

o クライアント側：RADIUS / TLSを唯一の通信オプションとして残して、フェイルオーバー設定を構成解除します

o Server side: de-configure the RADIUS/UDP client from the list of valid RADIUS clients

o サーバー側：有効なRADIUSクライアントのリストからRADIUS / UDPクライアントを構成解除します

RADIUS/TLS provides authentication and encryption between RADIUS peers. In the presence of proxies, the intermediate proxies can still inspect the individual RADIUS packets, i.e., "end-to-end" encryption is not provided. Where intermediate proxies are untrusted, it is desirable to use other RADIUS mechanisms to prevent RADIUS packet payload from inspection by such proxies. One common method to protect passwords is the use of the Extensible Authentication Protocol (EAP) and EAP methods that utilize TLS.

RADIUS / TLSは、RADIUSピア間の認証と暗号化を提供します。プロキシが存在する場合でも、中間プロキシは個々のRADIUSパケットを検査できます。つまり、「エンドツーエンド」の暗号化は提供されません。中間プロキシが信頼できない場合、他のRADIUSメカニズムを使用して、RADIUSパケットペイロードがそのようなプロキシによって検査されないようにすることが望ましいです。パスワードを保護する一般的な方法の1つは、TLSを利用する拡張認証プロトコル（EAP）およびEAPの方法を使用することです。

When using certificate fingerprints to identify RADIUS/TLS peers, any two certificates that produce the same hash value (i.e., that have a hash collision) will be considered the same client. Therefore, it is important to make sure that the hash function used is cryptographically uncompromised so that an attacker is very unlikely to be able to produce a hash collision with a certificate of his choice. While this specification mandates support for SHA-1, a later revision will likely demand support for more contemporary hash functions because as of issuance of this document, there are already attacks on SHA-1.

証明書のフィンガープリントを使用してRADIUS / TLSピアを識別する場合、同じハッシュ値を生成する（つまり、ハッシュの衝突がある）2つの証明書は同じクライアントと見なされます。したがって、攻撃者が自分の選択した証明書とのハッシュ衝突を生成する可能性が非常に低いように、使用されるハッシュ関数が暗号的に妥協されていないことを確認することが重要です。この仕様ではSHA-1のサポートが義務付けられていますが、このドキュメントの発行時点でSHA-1への攻撃がすでにあるため、今後の改訂ではより現代的なハッシュ関数のサポートが必要になる可能性があります。

7. IANA Considerations

7. IANAに関する考慮事項

No new RADIUS attributes or packet codes are defined. IANA has updated the already assigned TCP port number 2083 to reflect the following:

新しいRADIUS属性やパケットコードは定義されていません。 IANAは、すでに割り当てられているTCPポート番号2083を更新して、以下を反映しています。

o Reference: [RFC6614] o Assignment Notes: The TCP port 2083 was already previously assigned by IANA for "RadSec", an early implementation of RADIUS/ TLS, prior to issuance of this RFC. This early implementation can be configured to be compatible to RADIUS/TLS as specified by the IETF. See RFC 6614, Appendix A for details.

o参照：[RFC6614] o割り当てに関する注意：TCPポート2083は、このRFCが発行される前に、RADIUS / TLSの初期実装である「RadSec」用にIANAによって以前に割り当てられていました。この初期の実装は、IETFで指定されているRADIUS / TLSと互換性を持つように構成できます。詳細については、RFC 6614の付録Aをご覧ください。

8. Acknowledgements

8. 謝辞

RADIUS/TLS was first implemented as "RADSec" by Open Systems Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS server product (see [radsec-whitepaper]).

RADIUS / TLSは、「Radiator」RADIUSサーバー製品（[radsec-whitepaper]を参照）のために、オーストラリアのカランビンウォーターズにあるOpen Systems Consultantsによって「RADSec」として最初に実装されました。

Funding and input for the development of this document was provided by the European Commission co-funded project "GEANT2" [geant2] and further feedback was provided by the TERENA Task Force on Mobility and Network Middleware [terena].

このドキュメントの開発のための資金と入力は、欧州委員会の共同出資プロジェクト「GEANT2」[geant2]によって提供され、さらなるフィードバックは、モレビリティとネットワークミドルウェアに関するTERENAタスクフォース[terena]によって提供されました。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.

[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。

[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[RFC2866]リグニー、C。、「RADIUSアカウンティング」、RFC 2866、2000年6月。

[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.

[RFC4279] Eronen、P。およびH. Tschofenig、「トランスポート層セキュリティ（TLS）の事前共有鍵暗号スイート」、RFC 4279、2005年12月。

[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.

[RFC5176] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、and B. Aboba、 "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 5176、January 2008。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。

[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.

[RFC5247] Aboba、B.、Simon、D。、およびP. Eronen、「Extensible Authentication Protocol（EAP）Key Management Framework」、RFC 5247、2008年8月。

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。

[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.

[RFC6066] Eastlake、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、2011年1月。

[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.

[RFC6613] DeKok、A。、「RADIUS over TCP」、RFC 6613、2012年5月。

9.2. Informative References

9.2. 参考引用

[DYNAMIC] Winter, S. and M. McCauley, "NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS", Work in Progress, July 2011.

[動的]冬、S。およびM.マッコーリー、「RADIUS / TLSおよびRADIUS / DTLSのためのNAIベースの動的ピア検出」、Work in Progress、2011年7月。

[MD5-attacks] Black, J., Cochran, M., and T. Highland, "A Study of the MD5 Attacks: Insights and Improvements", October 2006, <http://www.springerlink.com/content/40867l85727r7084/>.

[MD5-attacks] Black、J.、Cochran、M。、およびT. Highland、「A Study of the MD5 Attacks：Insights and Improvements」、2006年10月、<http://www.springerlink.com/content/40867l85727r7084 />。

[RADEXT-DTLS] DeKok, A., "DTLS as a Transport Layer for RADIUS", Work in Progress, October 2010.

[RADEXT-DTLS] DeKok、A。、「RADIUSのトランスポート層としてのDTLS」、作業中、2010年10月。

[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.

[RFC3539] Aboba、B。およびJ. Wood、「Authentication、Authorization and Accounting（AAA）Transport Profile」、RFC 3539、2003年6月。

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「Diameter Base Protocol」、RFC 3588、2003年9月。

[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.

[RFC4107] Bellovin、S。およびR. Housley、「暗号鍵管理のガイドライン」、BCP 107、RFC 4107、2005年6月。

[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、2006年4月。

[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.

[RFC4953] Touch、J。、「なりすまし攻撃に対するTCPの防御」、RFC 4953、2007年7月。

[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.

[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月。

[RFC6421] Nelson, D., "Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421, November 2011.

[RFC6421] Nelson、D。、「リモート認証ダイヤルインユーザーサービス（RADIUS）の暗号化アジリティ要件」、RFC 6421、2011年11月。

[eduroam] Trans-European Research and Education Networking Association, "eduroam Homepage", 2007, <http://www.eduroam.org/>.

[eduroam] Trans-European Research and Education Networking Association、「eduroam Homepage」、2007年、<http://www.eduroam.org/>。

[geant2] Delivery of Advanced Network Technology to Europe, "European Commission Information Society and Media: GEANT2", 2008, <http://www.geant2.net/>.

[geant2]ヨーロッパへの高度なネットワーク技術の提供、「European Commission Information Society and Media：GEANT2」、2008年、<http://www.geant2.net/>。

[radsec-whitepaper] Open System Consultants, "RadSec - a secure, reliable RADIUS Protocol", May 2005, <http://www.open.com.au/radiator/radsec-whitepaper.pdf>.

[radsec-whitepaper]オープンシステムコンサルタント、「RadSec-安全で信頼できるRADIUSプロトコル」、2005年5月、<http://www.open.com.au/radiator/radsec-whitepaper.pdf>。

[radsecproxy-impl] Venaas, S., "radsecproxy Project Homepage", 2007, <http://software.uninett.no/radsecproxy/>.

[radsecproxy-impl] Venaas、S。、「radsecproxy Project Homepage」、2007、<http://software.uninett.no/radsecproxy/>。

[terena] Trans-European Research and Education Networking Association (TERENA), "Task Force on Mobility and Network Middleware", 2008, <http://www.terena.org/activities/tf-mobility/>.

[terena] Trans-European Research and Education Networking Association（TERENA）、「モビリティとネットワークミドルウェアに関するタスクフォース」、2008年、<http://www.terena.org/activities/tf-mobility/>。

Appendix A. Implementation Overview: Radiator

付録A.実装の概要：ラジエーター

Radiator implements the RadSec protocol for proxying requests with the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator configuration file.

ラジエーターは、ラジエーター構成ファイルの<Authby RADSEC>および<ServerRADSEC>句を使用してリクエストをプロキシするためのRadSecプロトコルを実装します。

The <AuthBy RADSEC> clause defines a RadSec client, and causes Radiator to send RADIUS requests to the configured RadSec server using the RadSec protocol.

<AuthBy RADSEC>句はRadSecクライアントを定義し、RadiatorがRadSecプロトコルを使用して構成済みのRadSecサーバーにRADIUS要求を送信するようにします。

The <ServerRADSEC> clause defines a RadSec server, and causes Radiator to listen on the configured port and address(es) for connections from <Authby RADSEC> clients. When an <Authby RADSEC> client connects to a <ServerRADSEC> server, the client sends RADIUS requests through the stream to the server. The server then handles the request in the same way as if the request had been received from a conventional UDP RADIUS client.

<ServerRADSEC>句はRadSecサーバーを定義し、ラジエーターに<Authby RADSEC>クライアントからの接続を構成済みのポートとアドレスでリッスンさせます。 <Authby RADSEC>クライアントが<ServerRADSEC>サーバーに接続すると、クライアントはストリームを介してサーバーにRADIUS要求を送信します。サーバーは、要求が従来のUDP RADIUSクライアントから受信された場合と同じ方法で要求を処理します。

Radiator is compliant to RADIUS/TLS if the following options are used:

次のオプションが使用されている場合、ラジエーターはRADIUS / TLSに準拠しています。

* Protocol tcp

* プロトコルTCP

* UseTLS

* TLS_CertificateFile

* Secret radsec

* 秘密のラドセック

* Protocol tcp

* プロトコルTCP

* UseTLS

* TLS_RequireClientCert

* Secret radsec

* 秘密のラドセック

As of Radiator 3.15, the default shared secret for RadSec connections is configurable and defaults to "mysecret" (without quotes). For compliance with this document, this setting needs to be configured for the shared secret "radsec". The implementation uses TCP keepalive socket options, but does not send Status-Server packets. Once established, TLS connections are kept open throughout the server instance lifetime.

Radiator 3.15以降、RadSec接続のデフォルトの共有シークレットは設定可能であり、デフォルトで「mysecret」（引用符なし）になります。このドキュメントに準拠するには、この設定を共有シークレット「radsec」用に構成する必要があります。実装はTCPキープアライブソケットオプションを使用しますが、Status-Serverパケットを送信しません。 TLS接続は、いったん確立されると、サーバーインスタンスの存続期間中、開いたままになります。

Appendix B. Implementation Overview: radsecproxy

付録B.実装の概要：radsecproxy

The RADIUS proxy named radsecproxy was written in order to allow use of RadSec in current RADIUS deployments. This is a generic proxy that supports any number and combination of clients and servers, supporting RADIUS over UDP and RadSec. The main idea is that it can be used on the same host as a non-RadSec client or server to ensure RadSec is used on the wire; however, as a generic proxy, it can be used in other circumstances as well.

radsecproxyという名前のRADIUSプロキシは、現在のRADIUS展開でRadSecを使用できるようにするために作成されました。これは、クライアントとサーバーの任意の数と組み合わせをサポートする汎用プロキシであり、RADIUS over UDPおよびRadSecをサポートします。主なアイデアは、非RadSecクライアントまたはサーバーと同じホストで使用して、RadSecがネットワークで確実に使用されるようにすることです。ただし、汎用プロキシとして、他の状況でも使用できます。

The configuration file consists of client and server clauses, where there is one such clause for each client or server. In such a clause, one specifies either "type tls" or "type udp" for TLS or UDP transport. Versions prior to 1.6 used "mysecret" as a default shared secret for RADIUS/TLS; version 1.6 and onwards uses "radsec". For backwards compatibility with older versions, the secret can be changed (which makes the configuration not compliant with this specification).

構成ファイルは、クライアントとサーバーの句で構成されます。このような句は、クライアントまたはサーバーごとに1つあります。このような句では、TLSまたはUDPトランスポートに対して「type tls」または「type udp」を指定します。 1.6より前のバージョンでは、RADIUS / TLSのデフォルトの共有秘密として「mysecret」が使用されていました。バージョン1.6以降は「radsec」を使用します。古いバージョンとの下位互換性のために、シークレットを変更できます（これにより、構成がこの仕様に準拠しなくなります）。

In order to use TLS for clients and/or servers, one must also specify where to locate CA certificates, as well as certificate and key for the client or server. This is done in a TLS clause. There may be one or several TLS clauses. A client or server clause may reference a particular TLS clause, or just use a default one. One use for multiple TLS clauses may be to present one certificate to clients and another to servers.

クライアントまたはサーバー、あるいはその両方にTLSを使用するには、CA証明書の場所と、クライアントまたはサーバーの証明書とキーも指定する必要があります。これはTLS句で行われます。 1つまたは複数のTLS句がある場合があります。クライアントまたはサーバーの句は、特定のTLS句を参照するか、デフォルトのTLS句を使用します。複数のTLS句の用途の1つは、1つの証明書をクライアントに提示し、別の証明書をサーバーに提示することです。

If any RadSec (TLS) clients are configured, the proxy will, at startup, listen on port 2083, as assigned by IANA for the OSC RadSec implementation. An alternative port may be specified. When a client connects, the client certificate will be verified, including checking that the configured Fully Qualified Domain Name (FQDN) or IP address matches what is in the certificate. Requests coming from a RadSec client are treated exactly like requests from UDP clients.

RadSec（TLS）クライアントが構成されている場合、プロキシは起動時に、OSC RadSec実装用にIANAによって割り当てられたポート2083でリッスンします。代替ポートを指定できます。クライアントが接続すると、構成済みの完全修飾ドメイン名（FQDN）またはIPアドレスが証明書の内容と一致するかどうかのチェックなど、クライアント証明書が検証されます。 RadSecクライアントからの要求は、UDPクライアントからの要求とまったく同じように扱われます。

At startup, the proxy will try to establish a TLS connection to each (if any) of the configured RadSec (TLS) servers. If it fails to connect to a server, it will retry regularly. There is some back-off where it will retry quickly at first, and with longer intervals later. If a connection to a server goes down, it will also start retrying regularly. When setting up the TLS connection, the server certificate will be verified, including checking that the configured FQDN or IP address matches what is in the certificate. Requests are sent to a RadSec server, just like they would be to a UDP server.

起動時に、プロキシは構成されたRadSec（TLS）サーバーのそれぞれ（存在する場合）へのTLS接続を確立しようとします。サーバーへの接続に失敗した場合は、定期的に再試行します。最初はすぐに再試行し、後でより長い間隔で再試行するバックオフがあります。サーバーへの接続がダウンした場合、サーバーは定期的に再試行を開始します。 TLS接続をセットアップするとき、構成されたFQDNまたはIPアドレスが証明書の内容と一致することの確認を含め、サーバー証明書が検証されます。リクエストは、UDPサーバーと同様に、RadSecサーバーに送信されます。

The proxy supports Status-Server messages. They are only sent to a server if enabled for that particular server. Status-Server requests are always responded to.

プロキシはStatus-Serverメッセージをサポートします。特定のサーバーで有効になっている場合にのみ、サーバーに送信されます。 Status-Server要求は常に応答されます。

This RadSec implementation has been successfully tested together with Radiator. It is a freely available, open-source implementation. For source code and documentation, see [radsecproxy-impl].

このRadSec実装は、ラジエーターと一緒に正常にテストされています。自由に利用できるオープンソースの実装です。ソースコードとドキュメントについては、[radsecproxy-impl]をご覧ください。

Appendix C. Assessment of Crypto-Agility Requirements

付録C.暗号アジリティ要件の評価

The RADIUS Crypto-Agility Requirements document [RFC6421] defines numerous classification criteria for protocols that strive to enhance the security of RADIUS. It contains mandatory (M) and recommended (R) criteria that crypto-agile protocols have to fulfill. The authors believe that the following assessment about the crypto-agility properties of RADIUS/TLS are true.

RADIUS Crypto-Agility要件ドキュメント[RFC6421]は、RADIUSのセキュリティを強化するためのプロトコルの多数の分類基準を定義しています。暗号化アジャイルプロトコルが満たさなければならない必須（M）および推奨（R）基準が含まれています。著者は、RADIUS / TLSの暗号機敏性プロパティに関する以下の評価が真実であると信じています。

By virtue of being a transport profile using TLS over TCP as a transport protocol, the cryptographically agile properties of TLS are inherited, and RADIUS/TLS subsequently meets the following points:

トランスポートプロトコルとしてTLS over TCPを使用するトランスポートプロファイルであることにより、TLSの暗号学的に俊敏なプロパティが継承され、RADIUS / TLSはその後次の点を満たします。

(M) negotiation of cryptographic algorithms for integrity and auth

（M）整合性と認証のための暗号アルゴリズムの交渉

(M) negotiation of cryptographic algorithms for encryption

（M）暗号化のための暗号アルゴリズムの交渉

(M) replay protection

（M）リプレイ保護

(M) define mandatory-to-implement cryptographic algorithms

（M）実装に必須の暗号アルゴリズムを定義する

(M) generate fresh session keys for use between client and server

（M）クライアントとサーバー間で使用する新しいセッションキーを生成する

(R) support for Perfect Forward Secrecy in session keys

（R）セッションキーでのPerfect Forward Secrecyのサポート

(R) support X.509 certificate-based operation

（R）X.509証明書ベースの操作をサポート

(R) support Pre-Shared keys

（R）事前共有キーをサポート

(R) support for confidentiality of the entire packet

（R）パケット全体の機密性のサポート

(M/R) support Automated Key Management

（M / R）サポート自動鍵管理

The remainder of the requirements is discussed individually below in more detail:

残りの要件については、以下で個別に詳しく説明します。

(M) "...avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security" [RFC6421]. The existing algorithm, based on MD5, is not of any significance in RADIUS/TLS; its compromise does not compromise the outer transport security.

（M）「... RADIUS実装で利用されている既存の暗号アルゴリズムが、ほとんどまたはまったくセキュリティを提供できないほど弱いことが示されている状況でも、セキュリティの妥協を避けてください」[RFC6421]。 MD5に基づく既存のアルゴリズムは、RADIUS / TLSでは重要ではありません。その妥協は、外部の輸送の安全を危うくしません。

(R) mandatory-to-implement algorithms are to be NIST-Acceptable with no deprecation date - The mandatory-to-implement algorithm is TLS_RSA_WITH_3DES_EDE_CBC_SHA. This ciphersuite supports three-key 3DES operation, which is classified as Acceptable with no known deprecation date by NIST.

（R）実装に必須のアルゴリズムは、廃止予定日なしでNISTに対応する必要があります-実装に必須のアルゴリズムはTLS_RSA_WITH_3DES_EDE_CBC_SHAです。この暗号スイートは3キーの3DES操作をサポートします。これは、NISTによって非推奨の日付が不明なAcceptableとして分類されています。

(M) demonstrate backward compatibility with RADIUS - There are multiple implementations supporting both RADIUS and RADIUS/TLS, and the translation between them.

（M）RADIUSとの下位互換性を示す-RADIUSとRADIUS / TLSの両方をサポートする複数の実装と、それらの間の変換があります。

(M) After legacy mechanisms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible - In RADIUS, communication between client and server is always a manual configuration; after a compromise, the legacy client in question can be de-configured by the same manual configuration.

（M）レガシーメカニズムが侵害された後は、安全なアルゴリズムを使用する必要があります。これにより、下位互換性が失われます。RADIUSでは、クライアントとサーバー間の通信は常に手動構成です。妥協後、問題のレガシークライアントは、同じ手動構成によって構成解除できます。

(M) indicate a willingness to cede change control to the IETF - Change control of this protocol is with the IETF.

（M）変更管理をIETFに譲る意思があることを示します-このプロトコルの変更管理はIETFにあります。

(M) be interoperable between implementations based purely on the information in the specification - At least one implementation was created exclusively based on this specification and is interoperable with other RADIUS/TLS implementations.

（M）仕様の情報のみに基づいて実装間で相互運用可能-少なくとも1つの実装がこの仕様に基づいて排他的に作成され、他のRADIUS / TLS実装と相互運用可能です。

(M) apply to all packet types - RADIUS/TLS operates on the transport layer, and can carry all packet types.

（M）すべてのパケットタイプに適用-RADIUS / TLSはトランスポート層で動作し、すべてのパケットタイプを伝送できます。

(R) message data exchanged with Diameter SHOULD NOT be affected - The solution is Diameter-agnostic.

（R）Diameterと交換されたメッセージデータは影響を受けないはずです-解決策はDiameterに依存しません。

(M) discuss any inherent assumptions - The authors are not aware of any implicit assumptions that would be yet-unarticulated in the document.

（M）固有の仮定について話し合う-著者は、ドキュメントでまだ明確にされていない暗黙の仮定を認識していません。

(R) provide recommendations for transition - The Security Considerations section contains a transition path.

（R）移行の推奨事項を提供する-「セキュリティに関する考慮事項」セクションには、移行パスが含まれています。

(R) discuss legacy interoperability and potential for bidding-down attacks - The Security Considerations section contains a corresponding discussion.

（R）従来の相互運用性とビッドダウン攻撃の可能性について話し合う-「セキュリティに関する考慮事項」セクションには、対応する説明が含まれています。

Summarizing, it is believed that this specification fulfills all the mandatory and all the recommended requirements for a crypto-agile solution and should thus be considered UNCONDITIONALLY COMPLIANT.

要約すると、この仕様は暗号アジャイルソリューションのすべての必須要件とすべての推奨要件を満たしていると考えられているため、無条件に準拠していると見なす必要があります。

Authors' Addresses

著者のアドレス

Stefan Winter Fondation RESTENA 6, rue Richard Coudenhove-Kalergi Luxembourg 1359 Luxembourg

Stefan Winter Fondation RESTENA 6、rue Richard Coudenhove-Kalergi Luxembourg 1359ルクセンブルグ

Phone: +352 424409 1 Fax: +352 422473 EMail: stefan.winter@restena.lu URI: http://www.restena.lu.

電話：+352 424409 1ファックス：+352 422473メール：stefan.winter@restena.lu URI：http://www.restena.lu。

Mike McCauley Open Systems Consultants 9 Bulbul Place Currumbin Waters QLD 4223 Australia

Phone: +61 7 5598 7474 Fax: +61 7 5598 7070 EMail: mikem@open.com.au URI: http://www.open.com.au.

電話：+61 7 5598 7474ファックス：+61 7 5598 7070メール：mikem@open.com.au URI：http://www.open.com.au。

Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA

Stig Venaas Cisco Systems Tasman Drive San Jose、CA 95134 USA

   EMail: stig@cisco.com

Klaas Wierenga Cisco Systems International BV Haarlerbergweg 13-19 Amsterdam 1101 CH The Netherlands

Klaas Wierenga Cisco Systems International BV Haarlerbergweg 13-19アムステルダム1101 CHオランダ

   Phone: +31 (0)20 3571752
   EMail: klaas@cisco.com
   URI:   http://www.cisco.com