Network Working Group G. Camarillo
Request for Comments: 5018 Ericsson
Category: Standards Track September 2007
Connection Establishment in the Binary Floor Control Protocol (BFCP)
バイナリフロア制御プロトコル（BFCP）での接続の確立
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS).
バイナリフロア制御プロトコル（BFCP）クライアントは、オファー/アンサー交換のコンテキスト外でBFCPフロア制御サーバへの接続を確立する方法をこの文書では、指定します。クライアントとサーバーの認証はトランスポート層セキュリティ（TLS）に基づいています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. TCP Connection Establishment . . . . . . . . . . . . . . . . . 2
4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Certificate-Based Server Authentication . . . . . . . . . . 4
5.2. Client Authentication Based on a Pre-Shared Secret . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
As discussed in the BFCP (Binary Floor Control Protocol) specification [RFC4582], a given BFCP client needs a set of data in order to establish a BFCP connection to a floor control server. These data include the transport address of the server, the conference identifier, and the user identifier.
BFCP（バイナリフロア制御プロトコル）仕様[RFC4582]で説明したように、所与BFCPクライアントは、フロア制御サーバへBFCP接続を確立するためにデータのセットを必要とします。これらのデータは、サーバーのトランスポート・アドレス、会議識別子、及びユーザ識別子が含まれます。
Once a client obtains this information, it needs to establish a BFCP connection to the floor control server. The way this connection is established depends on the context of the client and the floor control server. How to establish such a connection in the context of an SDP (Session Description Protocol) [RFC4566] offer/answer [RFC3264] exchange between a client and a floor control server is specified in RFC 4583 [RFC4583]. This document specifies how a client establishes a connection to a floor control server outside the context of an SDP offer/answer exchange.
クライアントがこの情報を取得したら、それはフロア制御サーバへBFCP接続を確立する必要があります。この接続が確立されている方法は、クライアントのコンテキストとフロア制御サーバに依存します。 SDP（セッション記述プロトコル）のコンテキストで、このような接続を確立するためにどのように[RFC4566]オファー/アンサー[RFC3264]クライアントとフロア制御サーバ間の交換は、RFC 4583 [RFC4583]で指定されています。この文書では、クライアントがSDPオファー/アンサー交換のコンテキスト外でフロア制御サーバへの接続を確立する方法を指定します。
BFCP entities establishing a connection outside an SDP offer/answer exchange need different authentication mechanisms than entities using offer/answer exchanges. This is because offer/answer exchanges provide parties with an initial integrity-protected channel that clients and floor control servers can use to exchange the fingerprints of their self-signed certificates. Outside the offer/ answer model, such a channel is not typically available. This document specifies how to authenticate clients using PSK (Pre-Shared Key)-TLS (Transport Layer Security) [RFC4279] and how to authenticate servers using server certificates.
SDPオファー/アンサー交換の外の接続を確立BFCPエンティティは、オファー/アンサー交換を使用して、エンティティとは異なる認証メカニズムを必要としています。オファー/アンサー交換がクライアントとフロア制御サーバは自分の自己署名証明書のフィンガープリントを交換するために使用することができ、最初の整合性が保護チャネルを持つ関係者に提供するためです。オファー/アンサーモデル以外では、このようなチャネルは、一般的に利用できません。この文書では、PSK（事前共有キー）-TLS（トランスポート層セキュリティ）を使用してクライアントを認証する方法を指定し、[RFC4279]とどのようにサーバ証明書を使用してサーバーを認証します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
As stated in Section 1, a given BFCP client needs a set of data in order to establish a BFCP connection to a floor control server. These data include the transport address of the server, the conference identifier, and the user identifier. It is outside the scope of this document to specify how a client obtains this information. This document assumes that the client obtains this information using an out-of-band method.
第1節で述べたように、与えられたBFCPクライアントは、フロア制御サーバへBFCP接続を確立するために、データのセットを必要とします。これらのデータは、サーバーのトランスポート・アドレス、会議識別子、及びユーザ識別子が含まれます。これは、クライアントがこの情報を取得する方法を指定するには、この文書の範囲外です。この文書では、クライアントがアウトオブバンド方式を使用してこの情報を取得することを前提としています。
Once the client has the transport address (i.e., IP address and port) of the floor control server, it initiates a TCP connection towards it. That is, the client performs an active TCP open.
クライアントは、フロア制御サーバのトランスポートアドレス（すなわち、IPアドレスとポート）を持っていたら、それはそれに向けたTCP接続を開始します。つまり、クライアントが開いているアクティブなTCPを実行します。
If the client is provided with the floor control server's host name instead of with its IP address, the client MUST perform a DNS lookup in order to resolve the host name into an IP address. Clients eventually perform an A or AAAA DNS lookup (or both) on the host name.
クライアントは、フロア制御サーバのホスト名ではなく、そのIPアドレスが提供されている場合、クライアントはIPアドレスにホスト名を解決するために、DNSルックアップを実行しなければなりません。クライアントは、最終的には、ホスト名のAまたはAAAA DNSルックアップ（あるいはその両方）を行います。
In order to translate the target to the corresponding set of IP addresses, IPv6-only or dual-stack clients MUST use name resolution functions that implement the Source and Destination Address Selection algorithms specified in [RFC3484]. (On many hosts that support IPv6, APIs like getaddrinfo() provide this functionality and subsume existing APIs like gethostbyname().)
IPアドレスの対応するセットにターゲットを変換するためには、IPv6のみまたはデュアルスタッククライアントは[RFC3484]で指定された送信元および宛先アドレス選択アルゴリズムを実装して名前解決機能を使用しなければなりません。 （）は、IPv6をサポートする多くのホストでは、getaddrinfoは同様のAPI（）この機能を提供し、（のgethostbynameのような既存のAPIを包摂。）
The advantage of the additional complexity is that this technique will output an ordered list of IPv6/IPv4 destination addresses based on the relative merits of the corresponding source/destination pairs. This will result in the selection of a preferred destination address. However, the Source and Destination Selection algorithms of [RFC3484] are dependent on broad operating system support and uniform implementation of the application programming interfaces that implement this behavior.
付加的な複雑さの利点は、この手法が出力対応するソース/宛先ペアの優劣に基づいたIPv6 / IPv4宛先アドレスの順序付きリスト。これは、優先送信先アドレスの選択になります。しかしながら、[RFC3484]のソースおよびデスティネーションの選択アルゴリズムは、幅広いオペレーティングシステムのサポートと、この動作を実装するアプリケーション・プログラミング・インターフェースの均一なインプリメンテーションに依存しています。
Developers should carefully consider the issues described by Roy et al. [RFC4943] with respect to address resolution delays and address selection rules. For example, implementations of getaddrinfo() may return address lists containing IPv6 global addresses at the top of the list and IPv4 addresses at the bottom, even when the host is only configured with an IPv6 local scope (e.g., link-local) and an IPv4 address. This will, of course, introduce a delay in completing the connection.
開発者は慎重ロイらによって記載されている問題を考慮する必要があります。アドレス解決遅延及びアドレス選択ルールに関して[RFC4943]。例えば、のgetaddrinfo（）の実装では、リストの一番上にIPv6グローバルアドレスを含むアドレスリストを返すことができるとIPv4（例えば、リンクローカル）とホストがIPv6のみローカルスコープで構成されている場合でも、下部にアドレスIPv4アドレス。これは、当然のことながら、接続を完了するの遅延を紹介します。
The BFCP specification [RFC4582] describes a number of situations when the TCP connection between a client and the floor control server needs to be reestablished. However, that specification does not describe the reestablishment process because this process depends on how the connection was established in the first place.
クライアントとフロア制御サーバ間のTCP接続を再確立する必要があるときBFCP仕様[RFC4582]は多くの状況を説明しています。このプロセスは、接続が最初に確立された方法によって異なりますので、しかし、その仕様は、再確立プロセスを説明していません。
When the existing TCP connection is closed following the rules in [RFC4582], the client SHOULD reestablish the connection towards the floor control server. If a TCP connection cannot deliver a BFCP message from the client to the floor control server and times out, the client SHOULD reestablish the TCP connection.
既存のTCP接続が[RFC4582]の規則を次のように閉じているときに、クライアントは、フロア制御サーバへの接続を再確立すべきです。 TCP接続がフロア制御サーバとタイムアウトするまでクライアントからBFCPメッセージを配信できない場合、クライアントは、TCP接続を再確立すべきです。
[RFC4582] requires that all BFCP entities implement TLS [RFC4346] and recommends that they use it in all their connections. TLS provides integrity and replay protection, and optional confidentiality. The floor control server MUST always act as the TLS server.
[RFC4582]は、すべてのBFCPエンティティがTLS [RFC4346]を実装する必要があり、彼らはすべての接続でそれを使用することをお勧めします。 TLSは、整合性と再生保護、およびオプションの機密性を提供します。フロア制御サーバは常にTLSサーバとして動作しなければなりません。
A floor control server that receives a BFCP message over TCP (no TLS) SHOULD request the use of TLS by generating an Error message with an Error code with a value of 9 (Use TLS).
TCP（NO TLS）上BFCPメッセージを受信したフロア制御サーバは、9（使用TLS）の値にエラーコードとエラーメッセージを生成することによって、TLSの使用を要求すべきです。
BFCP supports client authentication based on pre-shared secrets and server authentication based on server certificates.
BFCPは、サーバ証明書に基づいた事前共有秘密とサーバーの認証に基づいてクライアント認証をサポートしています。
At TLS connection establishment, the floor control server MUST present its certificate to the client. The certificate provided at the TLS level MUST either be directly signed by one of the other party's trust anchors or be validated using a certification path that terminates at one of the other party's trust anchors [RFC3280].
TLS接続の確立では、フロア制御サーバがクライアントに証明書を提示しなければなりません。 TLSレベルで提供された証明書は、直接相手のトラストアンカーの一つによって署名されなければならないか、他の当事者の信頼アンカー[RFC3280]のいずれかで終了する証明書パスを使用して検証します。
A client establishing a connection to a server knows the server's host name or IP address. If the client knows the server's host name, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.
サーバーへの接続を確立するクライアントは、サーバのホスト名またはIPアドレスを知っています。クライアントがサーバーのホスト名を知っている場合man-in-the-middle攻撃を防ぐために、サーバーの証明書メッセージに提示され、クライアントはサーバのアイデンティティに対してそれをチェックしなければなりません。
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the subjectAltName instead.
型のdNSNameのsubjectAltName拡張が存在する場合、それはIDとして使用しなければなりません。それ以外の場合は、証明書のSubjectフィールドで（最も特定の）Common Nameフィールドを使用しなければなりません。共通名の使用は練習を既存しているが、それが廃止されており、認証機関は、代わりのsubjectAltNameを使用することが推奨されています。
Matching is performed using the matching rules specified by [RFC3280]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name), a match in any one of the set is considered acceptable. Names in Common Name fields may contain the wildcard character *, which is considered to match any single domain name component or component fragment (e.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com).
マッチングは、[RFC3280]で指定されたマッチングルールを使用して実行されます。与えられたタイプの複数のアイデンティティが証明書内に存在する場合（例えば、複数のdNSName名）は、セットのいずれかに一致が許容されると考えられます。共通名フィールドの名前は、任意の単一のドメイン名のコンポーネントまたはコンポーネントの断片に一致するように考えられているワイルドカード文字*を含むことができる（例えば、* .a.comはfoo.a.comなくbar.foo.a.com。F一致します* .COM一致するfoo.comではなく、bar.com）。
If the client does not know the server's host name and contacts the server directly using the server's IP address, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP address known to the client.
クライアントは、サーバが直接サーバーのIPアドレスを使用して、サーバのホスト名と連絡先を知らない場合は、IPアドレスのsubjectAltNameは証明書に存在していなければならないと正確にクライアントに知られているIPアドレスと一致する必要があります。
If the host name or IP address known to the client does not match the identity in the certificate, user-oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting that enables it.
クライアントに知られているホスト名またはIPアドレスが証明書で身元と一致しない場合、ユーザー指向のクライアントは、ユーザーに通知する（クライアントは、ユーザーが任意の場合の接続を継続する機会を与える場合があります）または接続を終えなければなりませんどちらか悪い証明書エラーと。自動化されたクライアントは、適切な監査ログにエラーを記録しなければならない（可能な場合）と（悪い証明書エラーで）接続を終了すべきです。自動化されたクライアントは、このチェックを無効にしますが、それを可能に設定を提供しなければならない構成設定を提供することができます。
Client authentication is based on a pre-shared secret between client and server. Authentication is performed using PSK-TLS [RFC4279].
クライアント認証は、クライアントとサーバ間の事前共有秘密に基づいています。認証は、PSK-TLS [RFC4279]を使用して実行されます。
The BFCP specification mandates support for the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. Additionally, clients and servers supporting this specification MUST support the TLS_RSA_PSK_WITH_AES_128_CBC_SHA ciphersuite as well.
BFCP仕様義務はTLS_RSA_WITH_AES_128_CBC_SHA暗号スイートをサポート。また、この仕様をサポートするクライアントとサーバは、同様にTLS_RSA_PSK_WITH_AES_128_CBC_SHAの暗号スイートをサポートしなければなりません。
Client and server authentication as specified in this document are based on the use of TLS. Therefore, it is strongly RECOMMENDED that TLS with non-null encryption is always used. Clients and floor control servers MAY use other security mechanisms as long as they provide similar security properties (i.e., replay and integrity protection, confidentiality, and client and server authentication).
この文書で指定されたクライアントとサーバーの認証は、TLSの使用に基づいています。したがって、強くnull以外の暗号化とTLSを常に使用することをお勧めします。クライアントとフロア制御サーバは、限り、彼らは同様のセキュリティ・プロパティ（すなわち、再生および完全性保護、機密性、およびクライアントとサーバーの認証）を提供するように、他のセキュリティ・メカニズムを使用するかもしれません。
TLS PSK simply relies on a pre-shared key without specifying the nature of the key. In practice, such keys have two sources: text passwords and randomly generated binary keys. When keys are derived from passwords, TLS PSK mode is subject to offline dictionary attacks. In DHE (Diffie-Hellman Exchange) and RSA modes, an attacker who can mount a single man-in-the-middle attack on a client/server pair can then mount a dictionary attack on the password. In modes without DHE or RSA, an attacker who can record communications between a client/server pair can mount a dictionary attack on the password. Accordingly, it is RECOMMENDED that, where possible, clients use certificate-based server authentication ciphersuites with password-derived PSKs in order to defend against dictionary attacks.
TLS PSKは、単にキーの性質を指定せずに事前共有キーに依存しています。テキストのパスワードとランダムに生成されたバイナリキー：実際には、このようなキーは、2つのソースを持っています。キーがパスワードから導出されている場合は、TLS PSKモードはオフライン辞書攻撃される可能性があります。 DHE（のDiffie-Hellmanの交換）とRSAのモードでは、クライアント/サーバのペア上の単一のman-in-the-middle攻撃をマウントすることができ、攻撃者は、パスワードの辞書攻撃を仕掛けることができます。 DHEまたはRSAなしのモードでは、クライアント/サーバのペアの間の通信を記録することができ、攻撃者は、パスワードの辞書攻撃を仕掛けることができます。したがって、可能な場合は、クライアントは辞書攻撃を防御するためにはパスワード由来PSKsと証明書ベースのサーバー認証の暗号スイートを使用することをお勧めします。
In addition, passwords SHOULD be chosen with enough entropy to provide some protection against dictionary attacks. Because the entropy of text varies dramatically and is generally far less than that of an equivalent random bitstring, no hard and fast rules about password length are possible. However, in general passwords SHOULD be chosen to be at least 8 characters and selected from a pool containing both upper and lower case, numbers, and special keyboard characters (note that an 8-character ASCII password has a maximum entropy of 56 bits and in general far lower). FIPS PUB 112 [PUB112] provides some guidance on the relevant issues. If possible, passphrases are preferable to passwords. It is RECOMMENDED that implementations support, at minimum, 16-character passwords or passphrases. In addition, a cooperating client and server pair MAY choose to derive the TLS PSK shared key from the passphrase via a password-based key derivation function such as PBKDF2 [RFC2898]. Because such key derivation functions may incorporate iteration functions for key strengthening, they provide some additional protection against dictionary attacks by increasing the amount of work that the attacker must perform.
また、パスワードは辞書攻撃に対する何らかの保護を提供するのに十分なエントロピーを選択する必要があります。テキストのエントロピーが劇的に変化し、一般的に同等のランダムビット列のそれよりもはるかに小さいので、パスワードの長さについての厳格なルールは不可能です。しかし、一般的なパスワードに少なくとも8文字であるように選択されるべきであり、大文字と小文字、数字、特殊なキーボード文字の両方を含むプールから選択された（8文字のASCIIパスワードが56ビットとの最大エントロピーを有することに注意）はるかに低い一般的。 FIPS PUBの112 [PUB112]は、関連する問題について、いくつかのガイダンスを提供します。可能であれば、パスフレーズはパスワードよりも好ましいです。これは、実装のサポート、最低でも、16文字のパスワードまたはパスフレーズことが推奨されます。加えて、協働するクライアントとサーバのペアは、PBKDF2 [RFC2898]として、パスワードベースの鍵導出関数を介して、パスフレーズからTLS PSK共有鍵を導出するために選ぶかもしれ。そのようなキー導出関数は、キーの強化のための反復機能を組み込むことができるので、彼らは、攻撃者が実行しなければならない仕事の量を増やすことで、辞書攻撃に対するいくつかの追加の保護を提供します。
When the keys are randomly generated and of sufficient length, dictionary attacks are not effective because such keys are highly unlikely to be in the attacker's dictionary. Where possible, keys SHOULD be generated using a strong random number generator as specified in [RFC4086]. A minimum key length of 80 bits SHOULD be used.
キーはランダムに生成され、十分な長さのものである場合には、そのようなキーが攻撃者の辞書にあると非常に低いですので、辞書攻撃は有効ではありません。 [RFC4086]で指定されるように、可能な場合、キーは強い乱数ジェネレータを使用して生成されるべきです。 80ビットの最小の鍵長を使用すべきです。
The remainder of this section analyzes some of the threats against BFCP and how they are addressed.
このセクションの残りの部分は、BFCPとそれらがどのように対処さに対する脅威のいくつかを分析します。
An attacker may attempt to impersonate a client (a floor participant or a floor chair) in order to generate forged floor requests or to grant or deny existing floor requests. Client impersonation is avoided by using TLS. The floor control server assumes that attackers cannot hijack TLS connections from authenticated clients.
攻撃者は、鍛造床要求を生成したり、既存の床の要求を許可または拒否するために、クライアント（フロア参加者やフロアチェア）を偽装しようとすることができます。クライアントの偽装は、TLSを使用することによって回避されます。フロア制御サーバは、攻撃者が認証されたクライアントからのTLS接続をハイジャックすることができないことを前提としています。
An attacker may attempt to impersonate a floor control server. A successful attacker would be able to make clients think that they hold a particular floor so that they would try to access a resource (e.g., sending media) without having legitimate rights to access it. Floor control server impersonation is avoided by having floor control servers present their server certificates at TLS connection establishment time.
攻撃者は、フロア制御サーバを偽装しようとすることができます。成功した攻撃者は、クライアントが、彼らはそれにアクセスするための正当な権利を持たずに（メディアを送信するなど、）リソースにアクセスしようとするように、彼らは、特定のフロアを保持することを考えさせることができるでしょう。フロア制御サーバの偽装は、フロア制御サーバはTLS接続確立時にそのサーバ証明書を提示することによって回避されます。
Attackers may attempt to modify messages exchanged by a client and a floor control server. The integrity protection provided by TLS connections prevents this attack.
攻撃者は、クライアントとフロア制御サーバで交換されるメッセージを変更しようとすることがあります。 TLS接続が提供する完全性保護は、この攻撃を防ぐことができます。
Attackers may attempt to pick messages from the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). TLS confidentiality prevents this attack. Therefore, it is RECOMMENDED that TLS is used with a non-null encryption algorithm.
攻撃者は、フロア制御サーバとクライアントの間で機密情報へのアクセスを取得するために、ネットワークからのメッセージを選択しようと試みてもよい（例えば、フロア要求が拒否された理由）。 TLSの機密性は、この攻撃を防ぐことができます。したがって、TLSがnull以外の暗号化アルゴリズムを使用することをお勧めします。
Sam Hartman, David Black, Karim El Malki, and Vijay Gurbani provided useful comments on this document. Eric Rescorla performed a detailed security analysis of this document.
サム・ハートマン、デビッド・ブラック、カリム・エルMalki、およびビジェイGurbaniはこのドキュメントの役に立つコメントを提供しました。エリックレスコラは、このドキュメントの詳細なセキュリティ分析を行いました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年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、RFC 4279 "トランスポート層セキュリティ（TLS）のための事前共有鍵暗号の組み合わせ"、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4582]キャマリロ、G.、オット、J.、およびK.糖剤、 "バイナリフロア制御プロトコル（BFCP）"、RFC 4582、2006年11月。
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
、RFC 4583、2006年11月[RFC4583]キャマリロ、G.、 "バイナリフロア制御プロトコル（BFCP）ストリームのセッション記述プロトコル（SDP）フォーマット"。
[PUB112] National Institute of Standards and Technology (NIST), "Password Usage", FIPS PUB 112, May 1985.
[PUB112]国立標準技術研究所（NIST）、 "パスワードの使用"、FIPS PUBの112、1985月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[RFC2898] Kaliski、B.、 "PKCS＃5：パスワードベースの暗号化仕様バージョン2.0"、RFC 2898、2000年9月。
[RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", RFC 4943, September 2007.
[RFC4943]ロイ、S.、デュラン、A.、およびJ. Paugh、2007年9月、RFC 4943、 "IPv6の近隣探索オンリンク仮定が有害と考えられ"。
Author's Address
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。