RFC5018 日本語訳

Network Working Group                                       G. Camarillo
Request for Comments: 5018                                      Ericsson
Category: Standards Track                                 September 2007

コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 5018年のエリクソンカテゴリ: 標準化過程2007年9月

  Connection Establishment in the Binary Floor Control Protocol (BFCP)

2進の床の制御プロトコルへのコネクション確立(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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

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

このドキュメントはBinary Floor Controlプロトコル(BFCP)クライアントがどう申し出/答え交換の文脈の外におけるBFCP床の制御サーバに取引関係を築くかを指定します。 クライアントとサーバ証明はTransport Layer Security(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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 TCPコネクション確立. . . . . . . . . . . . . . . . . 2 4。 TLS用法. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5。 認証. . . . . . . . . . . . . . . . . . . . . . . . 4 5.1。 証明書ベースのサーバー証明. . . . . . . . . . 4 5.2。 .5 6にプレ共有秘密キーに基づくクライアント認証。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 5 7。 承認. . . . . . . . . . . . . . . . . . . . . . . . 7 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 7 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 8

Camarillo                   Standards Track                     [Page 1]

RFC 5018                          BFCP                    September 2007

キャマリロ規格はBFCP2007年9月にRFC5018を追跡します[1ページ]。

1.  Introduction

1. 序論

   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(2進のFloor Controlプロトコル)仕様[RFC4582]で議論するように、与えられたBFCPクライアントは床の制御サーバにBFCP接続を確立するために1セットのデータを必要とします。これらのデータはサーバの輸送アドレス、会議識別子、およびユーザ識別子を含んでいます。

   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]交換の文脈にそのような接続を確立するかはRFC4583[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(プレShared Key)-TLS(輸送Layer Security)[RFC4279]を使用することでどのようにクライアントを認証するか、そして、サーバ証明書を使用することでどのようにサーバを認証するかを指定します。

2.  Terminology

2. 用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

3.  TCP Connection Establishment

3. TCPコネクション確立

   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接続を確立するために1セットのデータを必要とします。これらのデータはサーバの輸送アドレス、会議識別子、およびユーザ識別子を含んでいます。 クライアントがどうこの情報を得るかを指定するために、このドキュメントの範囲の外にそれはあります。 このドキュメントは、クライアントがバンドで出ているメソッドを使用することでこの情報を得ると仮定します。

   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を実行します。

Camarillo                   Standards Track                     [Page 2]

RFC 5018                          BFCP                    September 2007

キャマリロ規格はBFCP2007年9月にRFC5018を追跡します[2ページ]。

   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だけかデュアルスタッククライアントがSourceとDestination Address Selectionが[RFC3484]で指定されたアルゴリズムであると実装する名前解決機能を使用しなければなりません。 (getaddrinfo()のようなAPIは、IPv6をサポートする多くのホストの上では、この機能性を提供して、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]のSourceとDestination Selectionアルゴリズムはこの振舞いを実装するアプリケーションプログラミングインターフェースの広いオペレーティングシステムサポートと一定の実装に依存しています。

      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アドレスによって構成さえされるだけであるとき下部にリストの冒頭とIPv4アドレスにIPv6のグローバルなアドレスを保管している返送先リストがそうするかもしれません。 これはもちろん接続を終了する遅れを導入するでしょう。

   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]で約束を守りながら閉じられるとき、クライアントSHOULDは床の制御サーバに向かって接続を回復させます。TCP接続がクライアントから床の制御サーバと回までBFCPメッセージを外に提供できないなら、クライアントSHOULDはTCP接続を回復させます。

Camarillo                   Standards Track                     [Page 3]

RFC 5018                          BFCP                    September 2007

キャマリロ規格はBFCP2007年9月にRFC5018を追跡します[3ページ]。

4.  TLS Usage

4. TLS用法

   [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がない)SHOULDの上にBFCPメッセージを受け取る床の制御サーバは、9の値でErrorコードでErrorメッセージを生成することによって、TLSの使用を要求します(TLSを使用してください)。

5.  Authentication

5. 認証

   BFCP supports client authentication based on pre-shared secrets and
   server authentication based on server certificates.

BFCPはプレ共有秘密キーに基づくクライアント認証とサーバ証明書に基づくサーバ証明をサポートします。

5.1.  Certificate-Based Server Authentication

5.1. 証明書ベースのサーバー証明

   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コネクション確立では、床の制御サーバはクライアントに証明書を提示しなければなりません。 相手の信頼アンカー[RFC3280]のひとりで終わる証明経路を使用して、TLSレベルで提供された証明書を、相手の信頼アンカーのひとりによって直接署名されるか、または有効にしなければなりません。

   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アドレスを知っています。 クライアントがサーバのホスト名を知っているなら、クライアントはサーバのCertificateメッセージに示されるようにサーバのアイデンティティに対してそれをチェックしなければなりません、中の男性を防ぐために-、-中央が攻撃されます。

   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拡張子が存在しているなら、アイデンティティとしてそれを使用しなければなりません。 さもなければ、証明書のSubject分野における(最も特定)の俗称分野を使用しなければなりません。 俗称の使用は既存の習慣ですが、それは推奨しないです、そして、Certification Authoritiesが代わりに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]によって指定された合っている規則を使用することで実行されます。 与えられたタイプの1つ以上のアイデンティティが証明書(例えば、1つ以上のdNSName名)に存在しているなら、セットのどれかにおけるマッチは許容できると考えられます。 俗称分野の名前はワイルドカードキャラクタ*を含むかもしれません。(キャラクタはどんな単一領域名前コンポーネントやコンポーネント断片(bar.foo.a. com. fではなく、例えば、*.a. comマッチfoo.a. com bar.comではなく、*.comマッチfoo.com)も合わせると考えられます)。

Camarillo                   Standards Track                     [Page 4]

RFC 5018                          BFCP                    September 2007

キャマリロ規格はBFCP2007年9月にRFC5018を追跡します[4ページ]。

   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アドレスが証明書のアイデンティティに合っていないなら、利用者志向クライアントは、ユーザ(クライアントはどのような場合でも、接続を続行する機会をユーザに与えるかもしれない)に通知しなければならないか、または悪い証明書誤りとの関係を終えなければなりません。 自動化されたクライアントは適切な監査ログに誤りを登録しなければなりません、そして、(利用可能であるなら)SHOULDは接続(悪い証明書誤りがある)を終えます。 自動化されたクライアントは、それを設定すると無効にされる構成にこのチェックを提供するかもしれませんが、それを可能にする設定を提供しなければなりません。

5.2.  Client Authentication Based on a Pre-Shared Secret

5.2. プレ共有秘密キーに基づくクライアント認証

   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であるとサポートしなければなりません。

6.  Security Considerations

6. セキュリティ問題

   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はRECOMMENDEDですが、したがって、それは強くそうです。いつも使用されます。 同様のセキュリティ資産(すなわち、再生、保全保護、秘密性、クライアント、およびサーバ証明)を提供する限り、クライアントと床の制御サーバは他のセキュリティー対策を使用するかもしれません。

   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つのソースがあります: テキストパスワードと手当たりしだいに発生している2進のキー。 パスワードからキーを得るとき、TLS PSKモードはオフライン辞書攻撃を受けることがあります。 そして、DHE(ディフィー-ヘルマンExchange)とRSAモードで、クライアント/サーバ組に対する中央の独身の男性攻撃を仕掛けることができる攻撃者はパスワードに辞書攻撃を仕掛けることができます。 DHEもRSAのないモードで、クライアント/サーバ組のコミュニケーションを記録できる攻撃者はパスワードに辞書攻撃を仕掛けることができます。 それに従って、可能であるところでは、クライアントが辞書攻撃に対して防御するのにパスワードが引き出されている証明書ベースのサーバ証明ciphersuites PSKsを使用するのが、RECOMMENDEDです。

Camarillo                   Standards Track                     [Page 5]

RFC 5018                          BFCP                    September 2007

キャマリロ規格はBFCP2007年9月にRFC5018を追跡します[5ページ]。

   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.

追加、パスワードSHOULD、辞書攻撃に対する何らかの保護を提供できるくらいのエントロピーで、選ばれてください。 テキストのエントロピーがガラッと変わって、同等な無作為のbitstringのものよりはるかに一般に少ないので、パスワードの長さに関するどんな鉄則も可能ではありません。 しかしながら、一般に、パスワードSHOULDはともに上側で少なくとも8つのキャラクタになるように選ばれていて、プール含有から選ばれて、ケース、数、および特別なキーボードの文字(8キャラクタのASCIIパスワードが最大56ビットのエントロピーに一般にはるかに低くする注意)を下げます。 FIPS PUB112[PUB112]は当該の問題で何らかの指導を提供します。 できれば、パスフレーズはパスワードより望ましいです。 それは実装が最小の、そして、16キャラクタのパスワードかパスフレーズでサポートするRECOMMENDEDです。 さらに、協力関係を持っているクライアントとサーバ組は、パスフレーズから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]の強い乱数発生器であったならSHOULDを合わせます。 80ビットSHOULDの最小のキー長に、いてください。使用されます。

   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接続によって提供された保全保護はこの攻撃を防ぎます。

Camarillo                   Standards Track                     [Page 6]

RFC 5018                          BFCP                    September 2007

キャマリロ規格はBFCP2007年9月にRFC5018を追跡します[6ページ]。

   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が非ヌル暗号化アルゴリズムで使用されるのは、RECOMMENDEDです。

7.  Acknowledgments

7. 承認

   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.

サム・ハートマン、デヴィッドBlack、カリムEl Malki、およびビジェイGurbaniはこのドキュメントの役に立つコメントを提供しました。 エリック・レスコラはこのドキュメントの詳細な証券分析を実行しました。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、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.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

[RFC4086]イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。

   [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)のためのあらかじめ共有された主要なCiphersuites」、RFC4279、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.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。

   [RFC4582]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
              Control Protocol (BFCP)", RFC 4582, November 2006.

[RFC4582]キャマリロ、G.、オット、J.、およびK.Drage、「2進の床の制御プロトコル(BFCP)」、RFC4582 2006年11月。

Camarillo                   Standards Track                     [Page 7]

RFC 5018                          BFCP                    September 2007

キャマリロ規格はBFCP2007年9月にRFC5018を追跡します[7ページ]。

   [RFC4583]  Camarillo, G., "Session Description Protocol (SDP) Format
              for Binary Floor Control Protocol (BFCP) Streams",
              RFC 4583, November 2006.

[RFC4583]キャマリロ、G.、「2進の床の制御プロトコル(BFCP)ストリームのためのセッション記述プロトコル(SDP)形式」、RFC4583、2006年11月。

   [PUB112]   National Institute of Standards and Technology (NIST),
              "Password Usage", FIPS PUB 112, May 1985.

[PUB112]米国商務省標準技術局(NIST)(「パスワード用法」、FIPSパブ112)は1985がそうするかもしれません。

8.2.  Informative References

8.2. 有益な参照

   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
              Specification Version 2.0", RFC 2898, September 2000.

[RFC2898]Kaliski、B.、「PKCS#5:」 パスワードベースの暗号仕様バージョン2インチ、RFC2898、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、「リンクにおける有害であると考えられたIPv6隣人発見仮定」、RFC4943、2007年9月。

Author's Address

作者のアドレス

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド

   EMail: Gonzalo.Camarillo@ericsson.com

メール: Gonzalo.Camarillo@ericsson.com

Camarillo                   Standards Track                     [Page 8]

RFC 5018                          BFCP                    September 2007

キャマリロ規格はBFCP2007年9月にRFC5018を追跡します[8ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Camarillo                   Standards Track                     [Page 9]

キャマリロ標準化過程[9ページ]