[要約] RFC 5018は、BFCP（Binary Floor Control Protocol）における接続確立に関する規格です。このRFCの目的は、BFCPセッションの確立と管理を効果的に行うための手順と要件を提供することです。
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]のコンテキストでこのような接続を確立する方法クライアントとフロアコントロールサーバーの間の交換は、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.
BFCPエンティティSDPオファー/回答交換の外側に接続を確立する必要には、オファー/回答の交換を使用するエンティティとは異なる認証メカニズムが必要です。これは、オファー/回答の交換が、クライアントとフロアコントロールサーバーが自己署名証明書の指紋を交換するために使用できる初期整合性保護チャネルをパーティーに提供するためです。オファー/回答モデルの外では、そのようなチャネルは通常使用できません。このドキュメントは、PSK（Pre-Shared Key）-TLS（Transport Layer Security）[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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
開発者は、Roy et al。によって説明されている問題を慎重に検討する必要があります。[RFC4943]アドレス解像度の遅延と選択ルールに対処することに関して。たとえば、getaddrinfo（）の実装は、リストの上部にIPv6グローバルアドレスを含むアドレスリストを返すことができ、ホストがIPv6ローカルスコープ（例：link-local）でのみ構成されている場合でも、下部にipv4アドレスをアドレスが返すことができます。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.
BFCP仕様[RFC4582]は、クライアントとフロアコントロールサーバーの間のTCP接続を再確立する必要がある場合の多くの状況を説明しています。ただし、この仕様では、このプロセスは、最初に接続がどのように確立されたかに依存するため、再確立プロセスを説明していません。
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.
[RFC4582]のルールに従って既存のTCP接続が閉じられた場合、クライアントはフロアコントロールサーバーへの接続を再確立する必要があります。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（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レベルで提供される証明書は、相手の信託アンカーのいずれかによって直接署名されるか、相手の1つの信頼アンカー[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アドレスを知っています。クライアントがサーバーのホスト名を知っている場合、クライアントは、中間の攻撃を防ぐために、サーバーの証明書メッセージに表示されるようにサーバーのIDに対してそれを確認する必要があります。
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のsumberaltaltname拡張が存在する場合、それはIDとして使用する必要があります。それ以外の場合、証明書の件名フィールドの（最も具体的な）一般名フィールドを使用する必要があります。一般名の使用は既存の慣行ですが、それは非推奨であり、認証当局は代わりに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]で指定されたマッチングルールを使用して、マッチングが実行されます。特定のタイプの複数のIDが証明書に存在する場合（たとえば、複数の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アドレスを使用してサーバーに直接連絡する場合、iPaddressの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アドレスが証明書のIDと一致しない場合、ユーザー指向のクライアントはユーザーに通知する必要があります（クライアントは、いずれにしてもユーザーに接続を継続する機会を与えます）、または接続を終了する必要があります悪い証明書エラーがあります。自動化されたクライアントは、エラーを適切な監査ログ（利用可能な場合）にログに記録する必要があり、接続を終了する必要があります（悪い証明書エラーを使用）。自動化されたクライアントは、このチェックを無効にする構成設定を提供する場合がありますが、それを有効にする設定を提供する必要があります。
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 CIPHERSUITEのサポートを義務付けています。さらに、この仕様をサポートするクライアントとサーバーは、TLS_RSA_PSK_WITH_AES_128_CBC_SHA CIPHERSUITEもサポートする必要があります。
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の使用に基づいています。したがって、非ヌル暗号化を備えた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 Exchange）およびRSAモードでは、クライアント/サーバーペアに1人の中間攻撃を行うことができる攻撃者がパスワードに辞書攻撃を行うことができます。DHEまたはRSAのないモードでは、クライアント/サーバーペア間で通信を記録できる攻撃者は、パスワードに辞書攻撃を行うことができます。したがって、可能であれば、クライアントは、辞書攻撃を防御するために、パスワード由来のPSKを使用して証明書ベースのサーバー認証暗号を使用することをお勧めします。
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]などのパスワードベースのキー派生関数を介して、PassPhraseからTLS共有キーを導出することを選択できます。このような重要な導出関数は、重要な強化のための反復関数を組み込んでいる可能性があるため、攻撃者が実行しなければならない作業の量を増やすことにより、辞書攻撃に対する追加の保護を提供します。
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は非ヌル暗号化アルゴリズムで使用することをお勧めします。
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.
サム・ハートマン、デビッド・ブラック、カリム・エル・マルキ、ヴィジェイ・ガルバニは、この文書に有用なコメントを提供しました。Eric Rescorlaは、この文書の詳細なセキュリティ分析を実施しました。
[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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット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。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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、「輸送層セキュリティのための事前共有キーシファースーツ（TLS）」、RFC 4279、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4582] Camarillo、G.、Ott、J。、およびK. Drage、「バイナリフロアコントロールプロトコル（BFCP）」、RFC 4582、2006年11月。
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
[RFC4583] Camarillo、G。、「セッション説明プロトコル（SDP）バイナリフロアコントロールプロトコル（BFCP）ストリームの形式」、RFC 4583、2006年11月。
[PUB112] National Institute of Standards and Technology (NIST), "Password Usage", FIPS PUB 112, May 1985.
[PUB112]国立標準技術研究所（NIST）、「パスワード使用」、FIPS Pub 112、1985年5月。
[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] Roy、S.、Durand、A。、およびJ. Paugh、「IPv6 Neighbor Discovery On-Link Assuttionが有害と見なされる」、RFC 4943、2007年9月。
Author's Address
著者の連絡先
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。