Network Working Group J. Lennox
Request for Comments: 4572 Columbia U.
Updates: 4145 July 2006
Category: Standards Track
Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
コネクション指向メディアトランスポート・セッション記述プロトコルでTransport Layer Security（TLS）プロトコル（SDP）を超えます
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.
この文書では、セッション記述プロトコル（SDP）を使用して、トランスポート層セキュリティ（TLS）プロトコルを介したセキュアな接続指向のメディアトランスポートセッションを確立する方法を指定します。これは、新しいSDPプロトコル識別子、「TCP / TLS」を定義します。また、TLSセッションのために提示される証明書を識別するSDP「指紋」属性の構文とセマンティクスを定義します。このメカニズムは、TLS接続を介してメディアトランスポートがあれば、セッション記述の整合性が保証されるよう、しっかりと確立することができます。
This document extends and updates RFC 4145.
この文書は、RFC 4145を拡張し、更新されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................4
3.1. SDP Operational Modes ......................................4
3.2. Threat Model ...............................................5
3.3. The Need for Self-Signed Certificates ......................5
3.4. Example SDP Description for TLS Connection .................6
4. Protocol Identifiers ............................................6
5. Fingerprint Attribute ...........................................7
6. Endpoint Identification .........................................9
6.1. Certificate Choice .........................................9
6.2. Certificate Presentation ..................................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................12
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
The Session Description Protocol (SDP) [1] provides a general-purpose format for describing multimedia sessions in announcements or invitations. For many applications, it is desirable to establish, as part of a multimedia session, a media stream that uses a connection-oriented transport. RFC 4145, Connection-Oriented Media Transport in the Session Description Protocol (SDP) [2], specifies a general mechanism for describing and establishing such connection-oriented streams; however, the only transport protocol it directly supports is TCP. In many cases, session participants wish to provide confidentiality, data integrity, and authentication for their media sessions. This document therefore extends the Connection-Oriented Media specification to allow session descriptions to describe media sessions that use the Transport Layer Security (TLS) protocol [3].
セッション記述プロトコル（SDP）[1]アナウンス又は招待状でマルチメディアセッションを記述するための汎用的なフォーマットを提供します。多くのアプリケーションでは、マルチメディアセッション、接続指向のトランスポートを使用して、メディア・ストリームの一部として、確立することが望ましいです。 RFC 4145、セッション記述プロトコル（SDP）におけるコネクション指向メディアトランスポート[2]は、記述およびそのような接続指向のストリームを確立するための一般的な機構を指定します。しかし、それが直接サポートする唯一のトランスポートプロトコルがTCPです。多くの場合、セッションの参加者は、メディアセッションの機密性、データの整合性、および認証を提供したいです。この文書では、したがって、セッション記述は、トランスポート層セキュリティ（TLS）プロトコル[3]を使用してメディアセッションを記述できるようにするコネクション型メディアの仕様を拡張します。
The TLS protocol allows applications to communicate over a channel that provides confidentiality and data integrity. The TLS specification, however, does not specify how specific protocols establish and use this secure channel; particularly, TLS leaves the question of how to interpret and validate authentication certificates as an issue for the protocols that run over TLS. This document specifies such usage for the case of connection-oriented media transport.
TLSプロトコルは、アプリケーションが機密性、データ保全性を提供するチャネルを介して通信することを可能にします。 TLS仕様は、しかし、確立方法を、特定のプロトコルを指定し、このセキュアなチャネルを使用していません。特に、TLSは解釈し、TLS上で動作するプロトコルのための課題として認証証明書を検証する方法についての質問を残します。この文書では、接続指向のメディア転送の場合のために、このような使用方法を指定します。
Complicating this issue, endpoints exchanging media will often be unable to obtain authentication certificates signed by a well-known root certification authority (CA). Most certificate authorities charge for signed certificates, particularly host-based certificates; additionally, there is a substantial administrative overhead to obtaining signed certificates, as certification authorities must be able to confirm that they are issuing the signed certificates to the correct party. Furthermore, in many cases endpoints' IP addresses and host names are dynamic: they may be obtained from DHCP, for example. It is impractical to obtain a CA-signed certificate valid for the duration of a DHCP lease. For such hosts, self-signed certificates are usually the only option. This specification defines a mechanism that allows self-signed certificates can be used securely, provided that the integrity of the SDP description is assured. It provides for endpoints to include a secure hash of their certificate, known as the "certificate fingerprint", within the session description. Provided that the fingerprint of the offered certificate matches the one in the session description, end hosts can trust even self-signed certificates.
この問題を複雑に、メディアを交換するエンドポイントは、多くの場合、よく知られたルート証明機関（CA）によって署名された認証証明書を取得することができません。ほとんどの認証局が署名された証明書、特にホストベースの証明書を有料化。さらに、証明機関は、彼らが正しいパーティーに署名した証明書を発行していることを確認することができなければならないとして、署名証明書を得るためにかなりの管理オーバーヘッドがあります。さらに、多くの場合、エンドポイントのIPアドレスとホスト名が動的である：彼らは、たとえば、DHCPから取得することができます。 DHCPのリース期間のための有効なCA署名付き証明書を取得することは非現実的です。このようなホストの場合は、自己署名証明書は、通常は唯一の選択肢です。本明細書は、自己署名証明書を安全に使用することができる可能にするメカニズムを定義するSDP記述の完全性が保証されることを条件とします。エンドポイントがセッション記述の中に、「証明書のフィンガープリント」として知られている彼らの証明書のセキュアハッシュを含めることがあります。提供された証明書のフィンガープリントは、セッション記述のものと一致することを提供し、エンドホストであっても、自己署名証明書を信頼することができます。
The rest of this document is laid out as follows. An overview of the problem and threat model is given in Section 3. Section 4 gives the basic mechanism for establishing TLS-based connected-oriented media in SDP. Section 5 describes the SDP fingerprint attribute, which, assuming that the integrity of SDP content is assured, allows the secure use of self-signed certificates. Section 6 describes which X.509 certificates are presented, and how they are used in TLS. Section 7 discusses additional security considerations.
このドキュメントの残りは以下の通りレイアウトされています。問題と脅威モデルの概要は、第3節第4節で与えられているSDPにTLSベースの接続指向のメディアを確立するための基本的なメカニズムを提供します。第5節では、SDPの内容の整合性が保証されていることを想定して、自己署名証明書の安全な使用を可能にする、SDPの指紋属性を記述する。第6節は、X.509証明書が提示され、そしてそれらがTLSで使用されている方法を説明します。第7節では、追加のセキュリティ上の考慮事項について説明します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119に記載されるように解釈されるべきである[4]及び対応する実装の要求レベルを示します。
This section discusses the threat model that motivates TLS transport for connection-oriented media streams. It also discusses in more detail the need for end systems to use self-signed certificates.
このセクションでは、接続指向のメディアストリーム用のTLSトランスポートを動機脅威モデルについて説明します。それはまた、より詳細にエンドシステムは、自己署名証明書を使用するための必要性を論じています。
There are two principal operational modes for multimedia sessions: advertised and offer-answer. Advertised sessions are the simpler mode. In this mode, a server publishes, in some manner, an SDP session description of a multimedia session it is making available. The classic example of this mode of operation is the Session Announcement Protocol (SAP) [15], in which SDP session descriptions are periodically transmitted to a well-known multicast group. Traditionally, these descriptions involve multicast conferences, but unicast sessions are also possible. (Connection-oriented media, obviously, cannot use multicast.) Recipients of a session description connect to the addresses published in the session description. These recipients may not previously have been known to the advertiser of the session description.
宣伝とオファーの答え：二つの主要な運用マルチメディアセッションのためのモードがあります。アドバタイズセッションは単純モードです。このモードでは、サーバは、何らかの方法で、それが利用可能にされるマルチメディアセッションのSDPセッション記述を公開します。この動作モードの典型的な例は、SDPセッション記述は、定期的によく知られているマルチキャストグループに送信されるセッションアナウンスメントプロトコル（SAP）[15]、です。伝統的に、これらの記述は、マルチキャスト会議を伴うが、ユニキャストセッションも可能です。 （接続指向のメディアは、明らかに、マルチキャストを使用することはできません。）セッション記述の受信者は、セッション記述に発表されたアドレスに接続します。これらの受信者は、以前にセッション記述の広告主に知られていない可能性があります。
Alternatively, SDP conferences can operate in offer-answer mode [5]. This mode allows two participants in a multimedia session to negotiate the multimedia session between them. In this model, one participant offers the other a description of the desired session from its perspective, and the other participant answers with the desired session from its own perspective. In this mode, each of the participants in the session has knowledge of the other one. This is the mode of operation used by the Session Initiation Protocol (SIP) [16].
また、SDP会議は、[5]のオファー応答モードで動作することができます。このモードでは、マルチメディアセッション内の2人の参加者は、それらの間のマルチメディアセッションを交渉することができます。このモデルでは、一人の参加者は、その観点から、希望のセッションの他の記述、および独自の観点から必要なセッションと他の参加者の回答を提供しています。このモードでは、セッションの参加者のそれぞれは、他の知識を持っています。これは、セッション開始プロトコル（SIP）[16]によって使用される動作モードです。
Participants in multimedia conferences often wish to guarantee confidentiality, data integrity, and authentication for their media sessions. This section describes various types of attackers and the ways they attempt to violate these guarantees. It then describes how the TLS protocol can be used to thwart the attackers.
マルチメディア会議の参加者は、多くの場合、彼らのメディアセッションの機密性、データの整合性、および認証を保証したいです。このセクションでは、攻撃者と、彼らはこれらの保証に違反しようとする方法の様々な種類について説明します。その後、TLSプロトコルは攻撃を阻止するために使用する方法について説明します。
The simplest type of attacker is one who listens passively to the traffic associated with a multimedia session. This attacker might, for example, be on the same local-area or wireless network as one of the participants in a conference. This sort of attacker does not threaten a connection's data integrity or authentication, and almost any operational mode of TLS can provide media stream confidentiality.
攻撃者の最も簡単なタイプは、マルチメディアセッションに関連付けられたトラフィックに受動的にリッスン一つです。この攻撃者は、例えば、会議の参加者の一人として同じローカルエリアネットワークまたはワイヤレスネットワーク上にあるかもしれません。攻撃者がこの種のは、接続のデータの整合性や認証を脅かさない、とほとんどTLSのいずれかの動作モードは、メディアストリームの機密性を提供することができます。
More sophisticated is an attacker who can send his own data traffic over the network, but who cannot modify or redirect valid traffic. In SDP's 'advertised' operational mode, this can barely be considered an attack; media sessions are expected to be initiated from anywhere on the network. In SDP's offer-answer mode, however, this type of attack is more serious. An attacker could initiate a connection to one or both of the endpoints of a session, thus impersonating an endpoint, or acting as a man in the middle to listen in on their communications. To thwart these attacks, TLS uses endpoint certificates. So long as the certificates' private keys have not been compromised, the endpoints have an external trusted mechanism (most commonly, a mutually-trusted certification authority) to validate certificates, and the endpoints know what certificate identity to expect, endpoints can be certain that such an attack has not taken place.
より洗練された、ネットワーク上で自分のデータトラフィックを送信できる攻撃者ですが、誰が変更したり、有効なトラフィックをリダイレクトすることはできません。 SDPの「宣伝」動作モードでは、これはほとんどの攻撃とみなすことができます。メディアセッションは、ネットワーク上のどこからでも開始することが期待されます。 SDPの申し出応答モードでは、しかし、この種の攻撃はより深刻です。攻撃者は、このようにエンドポイントを偽装し、またはその通信を傍受する中間者として働く、1またはセッションのエンドポイントの両方への接続を開始することができます。これらの攻撃を阻止するために、TLSは、エンドポイントの証明書を使用しています。だから、長い証明書のプライベートキーが危険にさらされていないとして、エンドポイントが証明書を検証するために外部の信頼メカニズム（最も一般的に、相互に信頼された証明機関を）持っている、およびエンドポイントを期待するのか証明書のアイデンティティを知って、エンドポイントは、特定することができこのような攻撃は行われていません。
Finally, the most serious type of attacker is one who can modify or redirect session descriptions: for example, a compromised or malicious SIP proxy server. Neither TLS itself nor any mechanisms that use it can protect an SDP session against such an attacker. Instead, the SDP description itself must be secured through some mechanism; SIP, for example, defines how S/MIME [17] can be used to secure session descriptions.
例えば、妥協や悪意のあるSIPプロキシサーバ：最後に、攻撃者の最も深刻なタイプは変更またはセッション記述をリダイレクトすることができるものです。どちらもTLS自体も、そのような攻撃に対してSDPセッションを保護することができ、それを使用するメカニズム。代わりに、SDP記述自体は、いくつかの機構を介して固定されなければなりません。 SIPは、例えば、S / MIME [17]セッション記述を固定するために使用することができる方法を定義します。
SDP session descriptions are created by any endpoint that needs to participate in a multimedia session. In many cases, such as SIP phones, such endpoints have dynamically-configured IP addresses and host names and must be deployed with nearly zero configuration. For such an endpoint, it is for practical purposes impossible to obtain a certificate signed by a well-known certification authority.
SDPセッション記述は、マルチメディアセッションに参加する必要がある任意のエンドポイントによって作成されます。そのようなSIP電話などの多くのケースでは、そのようなエンドポイントは、動的に設定されたIPアドレスとホスト名を持ち、ほぼゼロ構成で展開する必要があります。そのようなエンドポイントのために、よく知られている認証局によって署名された証明書を取得するための実用的な目的のために不可能です。
If two endpoints have no prior relationship, self-signed certificates cannot generally be trusted, as there is no guarantee that an attacker is not launching a man-in-the-middle attack. Fortunately, however, if the integrity of SDP session descriptions can be assured, it is possible to consider those SDP descriptions themselves as a prior relationship: certificates can be securely described in the session description itself. This is done by providing a secure hash of a certificate, or "certificate fingerprint", as an SDP attribute; this mechanism is described in Section 5.
2つのエンドポイントは、事前の関係を持っていない場合は、攻撃者がman-in-the-middle攻撃を開始されていないという保証がないので、自己署名証明書は、一般的に、信頼することはできません。 SDPセッション記述の整合性を確保することができるならばしかし、幸いなことに、前の関係のように、それらのSDPの記述自体を考慮することが可能です。証明書は、安全にセッション記述自体に記述することができます。これは、SDP属性として、安全な証明書のハッシュ、または「証明書のフィンガープリント」を提供することで行われます。このメカニズムは、第5章で説明されています。
Figure 1 illustrates an SDP offer that signals the availability of a T.38 fax session over TLS. For the purpose of brevity, the main portion of the session description is omitted in the example, showing only the 'm' line and its attributes. (This example is the same as the first one in RFC 4145 [2], except for the proto parameter and the fingerprint attribute.) See the subsequent sections for explanations of the example's TLS-specific attributes.
図1は、TLS上T.38ファックスセッションの利用可能性を通知するSDPオファーを示す図です。簡潔の目的のために、セッション記述の主要部分は、「M」線及びその属性を示す、実施例では省略されています。 （この例では、RFC 4145で最初のものと同じである[2]、プロトパラメータと指紋属性を除く。）の例のTLS固有の属性の説明については次のセクションを参照されたいです。
(Note: due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content.)
（注：。。RFCの表記規則のために、この文書は、その内容が72文字を超える行にSDPを分割し、この行の折りたたみが行われたバックスラッシュ文字マークをこのバックスラッシュとその末尾のCRLFと空白文字は、実際のSDPのコンテンツには表示されません。 ）
m=image 54111 TCP/TLS t38 c=IN IP4 192.0.2.2 a=setup:passive a=connection:new a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
M =画像54111 TCP / TLSのT38のC = IN IP4 192.0.2.2のA =セットアップ：受動A =接続：新しいA =指紋：SHA-1 \ 4A：AD：B9：B1：3F：82：18：3B：54 ：02：12：DF：3E：5D：49：6B：19：E5：7C：AB
Figure 1: Example SDP Description Offering a TLS Media Stream
図1：TLSメディアストリームを提供する例SDPの説明
The 'm' line in SDP specifies, among other items, the transport protocol to be used for the media in the session. See the "Media Descriptions" section of SDP [1] for a discussion on transport protocol identifiers.
SDP指定に「M」の行は、他の項目のうち、トランスポートプロトコルは、セッション内のメディアに使用されます。トランスポート・プロトコル識別子に議論については、[1] SDPの「メディアの説明」を参照してください。
This specification defines a new protocol identifier, 'TCP/TLS', which indicates that the media described will use the Transport Layer Security protocol [3] over TCP. (Using TLS over other transport protocols is not discussed in this document.) The 'TCP/TLS' protocol identifier describes only the transport protocol, not the upper-layer protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify the protocol using a fmt identifier to indicate the application being run over TLS.
この仕様は、記述されるメディアは、TCP上で[3]トランスポート層セキュリティプロトコルを使用することを示し、新たなプロトコル識別子、「TCP / TLS」を、定義されています。 （本書で議論されていない他のトランスポートプロトコルの上にTLSを使用する。）「TCP / TLS」プロトコル識別子は、トランスポート・プロトコルではなく、上位層プロトコルが記載されています。 「TCP / TLS」を指定する「M」の行は、さらに、TLS上で実行中のアプリケーションを示すために、FMTの識別子を使用して、プロトコルを修飾する必要があります。
Media sessions described with this identifier follow the procedures defined in RFC 4145 [2]. They also use the SDP attributes defined in that specification, 'setup' and 'connection'.
この識別子を用いて説明したメディアセッションは、[2] RFC 4145で定義された手順に従います。彼らはまた、その仕様で定義されたSDP属性、「セットアップ」と「接続」を使用します。
Parties to a TLS session indicate their identities by presenting authentication certificates as part of the TLS handshake procedure. Authentication certificates are X.509 [6] certificates, as profiled by RFC 3279 [7], RFC 3280 [8], and RFC 4055 [9].
TLSセッションの締約国は、TLSハンドシェイク手順の一部として認証証明書を提示することによって自分のアイデンティティを示しています。認証証明書は、RFC 3279によって輪郭として、X.509 [6]の証明書である[7]、RFC 3280 [8]、およびRFC 4055 [9]。
In order to associate media streams with connections and to prevent unauthorized barge-in attacks on the media streams, endpoints MUST provide a certificate fingerprint. If the X.509 certificate presented for the TLS connection matches the fingerprint presented in the SDP, the endpoint can be confident that the author of the SDP is indeed the initiator of the connection.
接続でメディアストリームを関連付けると、メディアストリーム上の不正バージイン攻撃を防ぐために、エンドポイントは、証明書のフィンガープリントを提供しなければなりません。 TLS接続のために提示X.509証明書がSDPで提示指紋と一致した場合、エンドポイントは、SDPの著者が実際に接続の開始剤であることを確信することができます。
A certificate fingerprint is a secure one-way hash of the DER (distinguished encoding rules) form of the certificate. (Certificate fingerprints are widely supported by tools that manipulate X.509 certificates; for instance, the command "openssl x509 -fingerprint" causes the command-line tool of the openssl package to print a certificate fingerprint, and the certificate managers for Mozilla and Internet Explorer display them when viewing the details of a certificate.)
証明書のフィンガープリントは、証明書のDER（識別符号化規則）形式のセキュアな一方向ハッシュです。 （証明書のフィンガープリントは広くX.509証明書を操作するツールでサポートされています。例えば、コマンドが「opensslのX509 -fingerprint」OpenSSLパッケージのコマンドラインツールは、証明書のフィンガープリントを印刷させる、とMozillaとインターネットのための証明書の管理証明書の詳細を表示するときにエクスプローラーがそれらを表示します。）
A fingerprint is represented in SDP as an attribute (an 'a' line). It consists of the name of the hash function used, followed by the hash value itself. The hash value is represented as a sequence of uppercase hexadecimal bytes, separated by colons. The number of bytes is defined by the hash function. (This is the syntax used by openssl and by the browsers' certificate managers. It is different from the syntax used to represent hash values in, e.g., HTTP digest authentication [18], which uses unseparated lowercase hexadecimal bytes. It was felt that consistency with other applications of fingerprints was more important.)
指紋は、属性（「A」線）としてSDPに示されています。なお、ハッシュ値自体に続く使用するハッシュ関数の名前から成ります。ハッシュ値は、コロンで区切られた大文字進バイトのシーケンスとして表されます。バイト数は、ハッシュ関数によって定義されます。 （これは、OpenSSLによって、およびブラウザの証明書マネージャによって使用される構文である。これは、例えば、HTTP未分離の小文字の16進数バイトを使用する認証[18]、ダイジェストにハッシュ値を表すために使用される構文とは異なる。これは、その一貫性を感じました指紋の他のアプリケーションとのより重要でした。）
The formal syntax of the fingerprint attribute is given in Augmented Backus-Naur Form [10] in Figure 2. This syntax extends the BNF syntax of SDP [1].
指紋属性の正式な構文は、この構文は、SDPのBNF構文を拡張し、図2に増補バッカスナウア記法[10]に記載されている[1]。
attribute =/ fingerprint-attribute
属性= /指紋属性
fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint
指紋属性=「指紋」「：」ハッシュFUNCのSPの指紋
hash-func = "sha-1" / "sha-224" / "sha-256" / "sha-384" / "sha-512" / "md5" / "md2" / token ; Additional hash functions can only come ; from updates to RFC 3279
ハッシュFUNC = "SHA-1" / "SHA-224" / "SHA-256" / "SHA-384" / "SHA-512" / "MD5" / "MD2" /トークン。追加のハッシュ関数は来ることができます。 RFC 3279への更新から
fingerprint = 2UHEX *(":" 2UHEX) ; Each byte in upper-case hex, separated ; by colons.
指紋= 2UHEX *（ "：" 2UHEX）。分離された大文字ヘクス、各バイト。コロンによります。
UHEX = DIGIT / %x41-46 ; A-F uppercase
UHEX = DIGIT /％x41-46。 -Fの大文字
Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute
図2：指紋認証属性のためのバッカス正規の構文を拡張
A certificate fingerprint MUST be computed using the same one-way hash function as is used in the certificate's signature algorithm. (This ensures that the security properties required for the certificate also apply for the fingerprint. It also guarantees that the fingerprint will be usable by the other endpoint, so long as the certificate itself is.) Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the defined hash functions are 'SHA-1' [11] [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred. A new IANA registry of Hash Function Textual Names, specified in Section 8, allows for addition of future tokens, but they may only be added if they are included in RFCs that update or obsolete RFC 3279 [7]. Self-signed certificates (for which legacy certificates are not a consideration) MUST use one of the FIPS 180 algorithms (SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, and thus also MUST use it to calculate certificate fingerprints.
証明書の署名アルゴリズムに使用される証明書のフィンガープリントは、同じ一方向ハッシュ関数を用いて計算されなければなりません。 （これは、証明書に必要なセキュリティ特性はまた、指紋のために適用されることを保証する。また、指紋は、証明書自体である限り、他のエンドポイントによって使用可能になることを保証する。）RFC 3279に続いて[7] RFCによって更新されるよう4055 [9]、従って、定義されたハッシュ関数が 'SHA-1' [11] [19]、 'SHA-224' [11]、 'SHA-256' [11]、 'SHA-384' [11]であります、 'SHA-512' [11]、 'MD5' [12]、及び 'MD2' [13]、 'SHA-1' が好ましい有します。セクション8で指定されたハッシュ関数テキスト名の新しいIANAレジストリは、将来のトークンの追加を可能にするが、それらはRFCでその更新または古いRFC 3279に含まれている場合、彼らは、[7]を添加してもよいです。それらの署名アルゴリズムとしてFIPS 180アルゴリズム（SHA-1、SHA-224、SHA-256、SHA-384、またはSHA-512）のいずれかを使用する必要があり（従来の証明書が考慮されていないため）自己署名証明書、および従ってまた、証明書のフィンガープリントを計算するためにそれを使用しなければなりません。
The fingerprint attribute may be either a session-level or a media-level SDP attribute. If it is a session-level attribute, it applies to all TLS sessions for which no media-level fingerprint attribute is defined.
指紋属性はセッションレベルまたは媒体レベルのSDP属性のいずれであってもよいです。それは、セッション・レベルの属性である場合、それはメディアレベルの指紋属性が定義されていないすべてのTLSセッションに適用されます。
An X.509 certificate binds an identity and a public key. If SDP describing a TLS session is transmitted over a mechanism that provides integrity protection, a certificate asserting any syntactically valid identity MAY be used. For example, an SDP description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY assert any identity in the certificate securing the media connection.
X.509証明書は、IDと公開鍵をバインドします。 TLSセッションを記述するSDPは、完全性保護を提供するメカニズムを介して送信されている場合は、いずれかの構文的に有効なアイデンティティを主張する証明書を使用することができます。例えば、SDP記述は、メディア接続を確保する証明書内の任意のアイデンティティをアサートすることができるS / MIME [17]により、HTTP / TLS [20]を介して送信され、または固定されています。
Security protocols that provide only hop-by-hop integrity protection (e.g., the sips protocol [16], SIP over TLS) are considered sufficiently secure to allow the mode in which any valid identity is accepted. However, see Section 7 for a discussion of some security implications of this fact.
唯一のホップバイホップ完全性保護を提供するセキュリティプロトコル（例えば、SIPSプロトコル[16]、TLS上SIP）は、任意の有効なIDが受け付けられたモードを可能にするために十分に安全であると考えられます。しかし、この事実のいくつかのセキュリティへの影響についての議論は、セクション7を参照してください。
In situations where the SDP is not integrity-protected, however, the certificate provided for a TLS connection MUST certify an appropriate identity for the connection. In these scenarios, the certificate presented by an endpoint MUST certify either the SDP connection address, or the identity of the creator of the SDP message, as follows:
SDPは、完全性保護されていない状況では、しかしながら、TLS接続のために提供された証明書は接続のための適切なアイデンティティを証明しなければなりません。次のようにこれらのシナリオでは、エンドポイントによって提示された証明書は、SDP接続アドレス、またはSDPメッセージの作成者のIDのいずれかを証明しなければなりません。
o If the connection address for the media description is specified as an IP address, the endpoint MAY use a certificate with an iPAddress subjectAltName that exactly matches the IP in the connection-address in the session description's 'c' line. Similarly, if the connection address for the media description is specified as a fully-qualified domain name, the endpoint MAY use a certificate with a dNSName subjectAltName matching the specified 'c' line connection-address exactly. (Wildcard patterns MUST NOT be used.)
メディア記述のための接続アドレスがIPアドレスとして指定されている場合は、O、エンドポイントは正確にセッション記述の「C」ラインでの接続アドレスにIPと一致していることをIPアドレスのsubjectAltNameで証明書を使用するかもしれません。メディア記述のための接続アドレスが完全修飾ドメイン名として指定されている場合も同様に、エンドポイントは正確に指定した「C」線に接続-アドレスに一致するのdNSNameのsubjectAltNameで証明書を使用するかもしれません。 （ワイルドカードパターンを使用してはいけません。）
o Alternately, if the SDP session description of the session was transmitted over a protocol (such as SIP [16]) for which the identities of session participants are defined by uniform resource identifiers (URIs), the endpoint MAY use a certificate with a uniformResourceIdentifier subjectAltName corresponding to the identity of the endpoint that generated the SDP. The details of what URIs are valid are dependent on the transmitting protocol. (For more details on the validity of URIs, see Section 7.)
セッションのSDPセッション記述は、セッション参加者の身元は、ユニフォームリソース識別子（URIの）によって定義され、エンドポイントがuniformResourceIdentifierで用いて証明書を使用する可能性があるため（例えば、SIP [16]など）プロトコルを介して送信された場合、あるいはO SDPを生成したエンドポイントのIDに対応するのsubjectAltName。 URIが有効であるかの詳細については、送信プロトコルに依存しています。 （URIの有効性の詳細については、セクション7を参照してください）
Identity matching is performed using the matching rules specified by RFC 3280 [8]. 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. To support the use of certificate caches, as described in Section 7, endpoints SHOULD
同一のマッチングは、RFC 3280で指定されたマッチングルールを使用して行われる[8]。与えられたタイプの複数のアイデンティティが証明書内に存在する場合（例えば、複数のdNSName名）は、セットのいずれかに一致が許容されると考えられます。第7節で説明したように、証明書のキャッシュの使用をサポートするために、エンドポイントはSHOULD
consistently provide the same certificate for each identity they support.
一貫して、彼らがサポートする各IDに同じ証明書を提供しています。
In all cases, an endpoint acting as the TLS server (i.e., one taking the 'setup:passive' role, in the terminology of connection-oriented media) MUST present a certificate during TLS initiation, following the rules presented in Section 6.1. If the certificate does not match the original fingerprint, the client endpoint MUST terminate the media connection with a bad_certificate error.
すべての場合において、TLSサーバとして機能するエンドポイントは（すなわち、「セットアップ：受動的」取って1役割、接続指向のメディアの用語では）6.1節で提示規則に従って、TLS開始時に証明書を提示しなければなりません。証明書は、元の指紋と一致しない場合、クライアントのエンドポイントはbad_certificateエラーとメディアの接続を終えなければなりません。
If the SDP offer/answer model [5] is being used, the client (the endpoint with the 'setup:active' role) MUST also present a certificate following the rules of Section 6.1. The server MUST request a certificate, and if the client does not provide one, or if the certificate does not match the provided fingerprint, the server endpoint MUST terminate the media connection with a bad_certificate error.
SDPオファー/アンサーモデル[5]が使用されている場合、クライアント（とエンドポイントの「セットアップ：アクティブの役割）も、6.1節の規則次の証明書を提示しなければなりません。サーバーは、証明書を要求しなければなりませんし、クライアントが1つを提供しない場合、または証明書が提供指紋と一致しない場合は、サーバーのエンドポイントはbad_certificateエラーとメディアの接続を終えなければなりません。
Note that when the offer/answer model is being used, it is possible for a media connection to outrace the answer back to the offerer. Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' role, it MUST (as specified in RFC 4145 [2]) begin listening for an incoming connection as soon as it sends its offer. However, it MUST NOT assume that the data transmitted over the TLS connection is valid until it has received a matching fingerprint in an SDP answer. If the fingerprint, once it arrives, does not match the client's certificate, the server endpoint MUST terminate the media connection with a bad_certificate error, as stated in the previous paragraph.
オファー/アンサーモデルが使用されているとき、それが戻っオファー側への答えをoutraceするメディア接続可能であることに注意してください。このように、オファー側が提供した場合は、「セットアップ：受動的」または「セットアップ：actpassの役割、それ必要があります（RFC 4145に指定されている[2]）それはその提供を送信するとすぐに着信接続のリッスンを開始します。しかし、それはSDPの答えに一致する指紋を受信するまでTLS接続を介して送信されるデータが有効であると仮定してはいけません。それが到着したら、指紋は、クライアントの証明書と一致しない場合は、前の段落で述べたように、サーバーのエンドポイントは、bad_certificateエラーとのメディア接続を終えなければなりません。
If offer/answer is not being used (e.g., if the SDP was sent over the Session Announcement Protocol [15]), there is no secure channel available for clients to communicate certificate fingerprints to servers. In this case, servers MAY request client certificates, which SHOULD be signed by a well-known certification authority, or MAY allow clients to connect without a certificate.
オファー/アンサーが使用されていない場合（SDPは、セッションアナウンスメントプロトコルを介して送信された場合、例えば、[15]）、クライアントはサーバに証明書のフィンガープリントを通信するために利用可能なセキュアなチャネルが存在しません。この場合、サーバは、よく知られた認証局によって署名されるべき、クライアント証明書を要求することができる、またはクライアント証明書なしで接続することを可能にします。
This entire document concerns itself with security. The problem to be solved is addressed in Section 1, and a high-level overview is presented in Section 3. See the SDP specification [1] for security considerations applicable to SDP in general.
セキュリティを備えたこの文書全体の懸念そのもの。解決すべき問題は、セクション1にアドレス指定され、そして高レベルの概要[1]一般的にSDPに適用可能なセキュリティ問題のためのSDP仕様を見るセクション3に提示されています。
Offering a TCP/TLS connection in SDP (or agreeing to one in SDP offer/answer mode) does not create an obligation for an endpoint to accept any TLS connection with the given fingerprint. Instead, the endpoint must engage in the standard TLS negotiation procedure to ensure that the TLS stream cipher and MAC algorithm chosen meet the security needs of the higher-level application. (For example, an offered stream cipher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected in almost every application scenario.)
SDPでTCP / TLS接続を提供（またはSDPオファー/アンサーモードでは1に同意する）指定された指紋との任意のTLS接続を受け入れるためのエンドポイントのための義務を作成しません。代わりに、エンドポイントは、選択されたTLSストリーム暗号とMACアルゴリズムは、より高いレベルのアプリケーションのセキュリティニーズを満たすことを確実にするために、標準のTLSネゴシエーション手順に従事しなければなりません。 （例えば、TLS_NULL_WITH_NULL_NULLの提供ストリーム暗号は、ほとんどすべてのアプリケーションシナリオで拒否されるべきです。）
Like all SDP messages, SDP messages describing TLS streams are conveyed in an encapsulating application protocol (e.g., SIP, Media Gateway Control Protocol (MGCP), etc.). It is the responsibility of the encapsulating protocol to ensure the integrity of the SDP security descriptions. Therefore, the application protocol SHOULD either invoke its own security mechanisms (e.g., secure multiparts) or, alternatively, utilize a lower-layer security service (e.g., TLS or IPsec). This security service SHOULD provide strong message authentication as well as effective replay protection.
すべてのSDPメッセージのような、TLSストリームを記述するSDPメッセージは、カプセル化アプリケーションプロトコルに搬送される（例えば、SIP、メディアゲートウェイ制御プロトコル（MGCP）、等）。 SDPセキュリティ記述の整合性を確保するためのカプセル化プロトコルの責任です。したがって、アプリケーションプロトコルは、独自のセキュリティ機構を呼び出し（例えば、セキュアマルチパート）、あるいは、下層セキュリティサービス（例えば、TLSやIPsec）を利用すべきであるいずれか。このセキュリティサービスは、強力なメッセージ認証だけでなく、効果的な再生保護を提供する必要があります。
However, such integrity protection is not always possible. For these cases, end systems SHOULD maintain a cache of certificates that other parties have previously presented using this mechanism. If possible, users SHOULD be notified when an unsecured certificate associated with a previously unknown end system is presented and SHOULD be strongly warned if a different unsecured certificate is presented by a party with which they have communicated in the past. In this way, even in the absence of integrity protection for SDP, the security of this document's mechanism is equivalent to that of the Secure Shell (ssh) protocol [21], which is vulnerable to man-in-the-middle attacks when two parties first communicate, but can detect ones that occur subsequently. (Note that a precise definition of the "other party" depends on the application protocol carrying the SDP message.) Users SHOULD NOT, however, in any circumstances be notified about certificates described in SDP descriptions sent over an integrity-protected channel.
しかし、そのような完全性保護は常に可能ではありません。このような場合のために、エンドシステムは、他の当事者が以前にこのメカニズムを使用して提示している証明書のキャッシュを維持する必要があります。可能であれば、以前に未知のエンドシステムに関連するセキュリティで保護されていない証明書が提示され、別の無担保証明書は、彼らが過去に通信しているとのパーティが提示されている場合、強く警告される必要がある場合、ユーザーは通知する必要があります。このように、偶数SDPのため保全保護の非存在下で、この文書のメカニズムのセキュリティは、二つのman-in-the-middle攻撃に対して脆弱であるセキュアシェル（SSH）プロトコル[21]、と同等です当事者は最初に通信しますが、その後に発生したものを検出することができます。 （「相手方」の正確な定義は、SDPメッセージを運ぶアプリケーションプロトコルに依存することに注意してください。）ユーザーは、しかし、どのような状況に整合性が保護チャネルを介して送信されたSDP記述で説明した証明書について通知されるべきではありません。
To aid interoperability and deployment, security protocols that provide only hop-by-hop integrity protection (e.g., the sips protocol [16], SIP over TLS) are considered sufficiently secure to allow the mode in which any syntactically valid identity is accepted in a certificate. This decision was made because sips is currently the integrity mechanism most likely to be used in deployed networks in the short to medium term. However, in this mode, SDP integrity is vulnerable to attacks by compromised or malicious middleboxes, e.g., SIP proxy servers. End systems MAY warn users about SDP sessions that are secured in only a hop-by-hop manner, and definitions of media formats running over TCP/TLS MAY specify that only end-to-end integrity mechanisms be used.
相互運用性と展開を支援するために、唯一のホップバイホップ完全性保護（例えば、SIPSプロトコル[16]、TLSを超えるSIP）を提供するセキュリティプロトコルは、任意の構文的に有効なIDがで受け入れされるモードを可能にするために十分に安全であると考えています証明書。 SIPSは現在、中期的に短期で展開ネットワークで使用される可能性が最も高い整合性のメカニズムであるため、この決定がなされました。しかし、このモードでは、SDP整合性が損なわや悪意のあるミドルボックス、例えば、SIPプロキシサーバによる攻撃に対して脆弱です。エンドシステムのみホップバイホップ方法で固定されているSDPセッションについてユーザーに警告することができ、TCP / TLS上で実行されているメディアフォーマットの定義は、唯一のエンドツーエンドの完全性メカニズムを使用するように指定することができます。
Depending on how SDP messages are transmitted, it is not always possible to determine whether or not a subjectAltName presented in a remote certificate is expected for the remote party. In particular, given call forwarding, third-party call control, or session descriptions generated by endpoints controlled by the Gateway Control Protocol [22], it is not always possible in SIP to determine what entity ought to have generated a remote SDP response. In general, when not using authenticity and integrity protection of SDP descriptions, a certificate transmitted over SIP SHOULD assert the endpoint's SIP Address of Record as a uniformResourceIndicator subjectAltName. When an endpoint receives a certificate over SIP asserting an identity (including an iPAddress or dNSName identity) other than the one to which it placed or received the call, it SHOULD alert the user and ask for confirmation. This applies whether certificates are self-signed, or signed by certification authorities; a certificate for sip:bob@example.com may be legitimately signed by a certification authority, but may still not be acceptable for a call to sip:alice@example.com. (This issue is not one specific to this specification; the same consideration applies for S/MIME-signed SDP carried over SIP.)
送信されたかSDPメッセージによっては、リモート証明書に提示のsubjectAltNameは、相手のために期待されているかどうかを判断することは必ずしも可能ではありません。具体的には、呼転送、サードパーティ呼制御、またはゲートウェイ制御プロトコルによって制御されるエンドポイントによって生成されたセッション記述[22]が与えられると、それがどのようなエンティティは、リモートSDP応答を生成しているべきかを決定するためにSIP常に可能ではありません。 SDP記述の信憑性と整合性の保護を使用しない場合、一般的には、SIPを介して送信された証明書はuniformResourceIndicatorのsubjectAltNameとして録音のエンドポイントのSIPアドレスを主張すべきです。エンドポイントは、それが配置されるか、または呼を受信したもの以外（IPアドレスまたは同一のdNSName含む）アイデンティティをアサートSIP上の証明書を受信すると、ユーザに警告し、確認を求めるべきです。これは、証明書が自己署名、または証明機関によって署名されているかどうか適用されます。 SIPのための証明書：bob@example.comは、合法的に証明機関によって署名することができるが、それでも、SIPへの呼び出しのために許容されない場合がありますalice@example.com。 （この問題は、本明細書に固有のものではない、同じ考慮事項は、SIPを介して搬送されるS / MIME署名されたSDPのために適用されます）。
This document does not define any mechanism for securely transporting RTP and RTP Control Protocol (RTCP) packets over a connection-oriented channel. There was no consensus in the working group as to whether it would be better to send Secure RTP packets [23] over a connection-oriented transport [24], or whether it would be better to send standard unsecured RTP packets over TLS using the mechanisms described in this document. The group consensus was to wait until a use-case requiring secure connection-oriented RTP was presented.
この文書では、確実な接続指向チャネルを介してRTP及びRTP制御プロトコル（RTCP）パケットを輸送するための任意の機構を定義していません。そこには、接続指向のトランスポート[24]上にセキュアRTPパケット[23]を送信する方がよいかどうかのワーキンググループにはコンセンサスがなかったか、メカニズムを使用してTLS上の標準的なセキュリティで保護されていないRTPパケットを送信する方がよいかどうかこのドキュメントで説明します。グループのコンセンサスがユースケース要求する安全な接続指向のRTPが提示されるまで待つことでした。
TLS is not always the most appropriate choice for secure connection-oriented media; in some cases, a higher- or lower-level security protocol may be appropriate.
TLSは、常に安全な接続指向のメディアのための最も適切な選択肢ではありません。いくつかの場合において、higher-またはより低いレベルのセキュリティプロトコルが適切であり得ます。
This document defines an SDP proto value: 'TCP/TLS'. Its format is defined in Section 4. This proto value has been registered by IANA under "Session Description Protocol (SDP) Parameters" under "proto".
'TCP / TLS'：この文書では、SDP proto値を定義します。そのフォーマットは、第4項に定義されている。このproto値は「プロト」の下に「セッション記述プロトコル（SDP）パラメータ」の下でIANAによって登録されています。
This document defines an SDP session and media-level attribute: 'fingerprint'. Its format is defined in Section 5. This attribute has been registered by IANA under "Session Description Protocol (SDP) Parameters" under "att-field (both session and media level)".
「指紋」：この文書では、SDPセッションとメディアレベル属性を定義します。そのフォーマットは、第5節で定義されているこの属性は、「ATT-フィールド（セッションとメディアレベルの両方）」の「セッション記述プロトコル（SDP）パラメータ」の下でIANAによって登録されています。
The SDP specification [1] states that specifications defining new proto values, like the 'TCP/TLS' proto value defined in this one, must define the rules by which their media format (fmt) namespace is managed. For the TCP/TLS protocol, new formats SHOULD have an associated MIME registration. Use of an existing MIME subtype for the format is encouraged. If no MIME subtype exists, it is RECOMMENDED that a suitable one be registered through the IETF process [14] by production of, or reference to, a standards-track RFC that defines the transport protocol for the format.
SDP仕様は、[1]このいずれかで定義された「TCP / TLS」proto値のような新たなプロト値を定義する仕様は、それらのメディアフォーマット（FMT）名前空間を管理することによりルールを定義する必要があることを述べています。 TCP / TLSプロトコルの場合、新しいフォーマットは、関連するMIME登録を持っているべきです。フォーマットのための既存のMIMEサブタイプの使用が推奨されています。何MIMEサブタイプが存在しない場合、適切なものでの生産、またはフォーマットするためのトランスポートプロトコルを定義する標準トラックRFCを参照することによりIETFプロセス[14]を介して登録することが推奨されます。
This specification creates a new IANA registry named "Hash Function Textual Names". It will not be part of the SDP Parameters.
この仕様は、「ハッシュ関数テキスト名」という名前の新しいIANAレジストリを作成します。これは、SDPパラメータの一部ではありません。
The names of hash functions used for certificate fingerprints are registered by the IANA. Hash functions MUST be defined by standards-track RFCs that update or obsolete RFC 3279 [7].
証明書のフィンガープリントに使用するハッシュ関数の名前は、IANAによって登録されています。ハッシュ関数は、標準トラックRFCで規定されなければならないこと更新または廃止RFC 3279 [7]。
When registering a new hash function textual name, the following information MUST be provided:
新しいハッシュ関数のテキスト名を登録する場合、以下の情報を提供しなければなりません。
o The textual name of the hash function.
ハッシュ関数のテキスト名O。
o The Object Identifier (OID) of the hash function as used in X.509 certificates.
X.509証明書で使用されるハッシュ関数のオブジェクト識別子（OID）O。
o A reference to the standards-track RFC, updating or obsoleting RFC 3279 [7], defining the use of the hash function in X.509 certificates.
O規格トラックRFCへの参照、更新、またはRFC 3279を時代遅れ[7]、X.509証明書におけるハッシュ関数の使用を規定します。
Figure 3 contains the initial values of this registry.
図3は、このレジストリの初期値が含まれています。
Hash Function Name OID Reference
------------------ --- ---------
"md2" 1.2.840.113549.2.2 RFC 3279
"md5" 1.2.840.113549.2.5 RFC 3279
"sha-1" 1.3.14.3.2.26 RFC 3279
"sha-224" 2.16.840.1.101.3.4.2.4 RFC 4055
"sha-256" 2.16.840.1.101.3.4.2.1 RFC 4055
"sha-384" 2.16.840.1.101.3.4.2.2 RFC 4055
"sha-512" 2.16.840.1.101.3.4.2.3 RFC 4055
Figure 3: IANA Hash Function Textual Name Registry
図3：IANAハッシュ関数テキスト名のレジストリ
[1] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[1]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[2] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[2]ヨン、D.とG.キャマリロ、 "セッション記述プロトコル（SDP）におけるTCPベースのメディア交通"、RFC 4145、2005年9月。
[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[3]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[6] International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO Standard 9594-8, March 2000.
[6]国際電気通信連合、「情報技術 - 開放型システム間相互接続 - ディレクトリ：公開鍵と証明書の枠組みを属性」、ITU-T勧告X.509、ISO規格9594から8、2000年3月。
[7] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[7] Bassham、L.、ポーク、W.、およびR. Housley氏、 "アルゴリズムとインターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールの識別子"、RFC 3279、2002年4月。
[8] 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.
[8] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[9] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[9] Schaad、J.、Kaliski、B.、およびR. Housley氏、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールで使用するRSA暗号のための追加のアルゴリズムと識別子"、RFC 4055 、2005年6月。
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[10]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[11] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, <http://csrc.nist.gov/ publications/fips/fips180-2/fips180-2.pdf>.
[11]米国国立標準技術研究所、 "セキュアハッシュ標準"、FIPS PUB 180-2の、2002年8月、<http://csrc.nist.gov/出版/ FIPS / fips180-2 / fips180-2.pdf> 。
[12] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[12]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[13] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992.
[13] Kaliski、B.、 "MD2メッセージダイジェストアルゴリズム"、RFC 1319、1992年4月。
[14] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[14]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[15]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[16]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[17] Ramsdell、B.、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[18] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[18]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[19] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[19]イーストレイク、D.とP.ジョーンズ、2001年9月、RFC 3174 "米国はハッシュアルゴリズム1（SHA1）を固定します"。
[20] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[20]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[21] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[21] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、2006年1月。
[22] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[22]グローブ、C.、パンタレオ、M.、アンダーソン、T.、およびT.テイラー、 "ゲートウェイ制御プロトコルバージョン1"、RFC 3525、2003年6月。
[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[23] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[24] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
"接続指向のトランスポート上でリアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）パケットをフレーミング" [24]ラザロ、J.、RFC 4571、2006年7月。
Author's Address
著者のアドレス
Jonathan Lennox Columbia University Department of Computer Science 450 Computer Science 1214 Amsterdam Ave., M.C. 0401 New York, NY 10027 US
コンピュータサイエンスのジョナサン・レノックスコロンビア大学学部450コンピュータサイエンス1214年アムステルダムアベニュー、M.C。 0401ニューヨーク、NY 10027米国
EMail: lennox@cs.columbia.edu
メールアドレス：lennox@cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。