[要約] RFC 4572は、SDP内のTLSプロトコルを使用した接続指向のメディアトランスポートに関する仕様です。このRFCの目的は、セキュアなメディアトランスポートを提供するためにTLSを使用する方法を定義することです。
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)
セッション説明プロトコル（SDP）のトランスポートレイヤーセキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート
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).
Copyright（c）The Internet Society（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-Signed証明書を取得することは非現実的です。このようなホストの場合、通常、自己署名証明書が唯一のオプションです。この仕様は、SDP説明の整合性が保証されていれば、自己署名証明書を安全に使用できるメカニズムを定義します。セッションの説明内に、「証明書指紋」として知られる証明書の安全なハッシュを含むエンドポイントを提供します。提供された証明書の指紋がセッションの説明の1つと一致する場合、エンドホストは自己署名証明書でさえ信頼できます。
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.
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "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.
マルチメディアセッションには、宣伝とオファーアンスワーの2つの主要な運用モードがあります。広告されたセッションはよりシンプルなモードです。このモードでは、サーバーが何らかの方法で、利用可能になっているマルチメディアセッションのSDPセッションの説明を公開します。この操作モードの典型的な例は、セッションアナウンスプロトコル（SAP）[15]であり、SDPセッションの説明は、よく知られたマルチキャストグループに定期的に送信されます。従来、これらの説明にはマルチキャスト会議が含まれますが、ユニキャストセッションも可能です。（明らかに、接続指向のメディアはマルチキャストを使用できません。）セッションの説明の受信者は、セッションの説明で公開されているアドレスに接続します。これらの受信者は、セッションの説明の広告主に以前は知られていなかったかもしれません。
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人の参加者がマルチメディアセッションを交渉することができます。このモデルでは、1人の参加者が他の参加者にその観点から目的のセッションの説明を提供し、もう1人の参加者は独自の観点から目的のセッションに答えます。このモードでは、セッションの各参加者は他の参加者の知識を持っています。これは、セッション開始プロトコル（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.
最も単純なタイプの攻撃者は、マルチメディアセッションに関連するトラフィックに受動的に耳を傾ける人です。たとえば、この攻撃者は、会議の参加者の1人と同じローカルエリアまたはワイヤレスネットワークにいる場合があります。この種の攻撃者は、接続のデータの整合性または認証を脅かすことはなく、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のオファーアンスワーモードでは、このタイプの攻撃はより深刻です。攻撃者は、セッションのエンドポイントの一方または両方への接続を開始し、エンドポイントになりすましたり、コミュニケーションに耳を傾けるために真ん中の男として行動することができます。これらの攻撃を阻止するために、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つのエンドポイントに事前の関係がない場合、攻撃者が中間攻撃を開始していないという保証がないため、自己署名証明書を一般に信頼することはできません。しかし、幸いなことに、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 Faxセッションの可用性を示すSDPオファーを示しています。簡潔さの目的のために、セッションの説明の主要部分は例で省略されており、「M」行とその属性のみを示しています。（この例は、RFC 4145 [2]の最初の例と同じですが、Protoパラメーターと指紋属性を除きます。）例の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を分割します。このラインの折り畳みが行われたバックスラッシュ文字マーク。））
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
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」行は、他のアイテムの中でも、セッションのメディアに使用されるトランスポートプロトコルを指定しています。輸送プロトコル識別子に関する議論については、SDP [1]の「メディア説明」セクションを参照してください。
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/TLS」を定義します。これは、説明されているメディアがTCPよりもトランスポートレイヤーセキュリティプロトコル[3]を使用することを示しています。（このドキュメントでは、他の輸送プロトコルでTLSを使用していません。）「TCP/TLS」プロトコル識別子は、上層層プロトコルではなく、輸送プロトコルのみを記述します。「TCP/TLS」を指定する「M」行は、FMT識別子を使用してプロトコルをさらに適格にして、TLSで実行されているアプリケーションを示す必要があります。
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'.
この識別子で説明されているメディアセッションは、RFC 4145 [2]で定義されている手順に従います。また、その仕様、「セットアップ」、「接続」で定義されている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 [7]、RFC 3280 [8]、およびRFC 4055 [9]によって紹介されるX.509 [6]証明書です。
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パッケージのコマンドラインツールに証明書指紋を印刷し、モジラとインターネットの証明書マネージャーはExplorer証明書の詳細を表示するときにそれらを表示します。）
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.)
指紋は、SDPで属性（ 'a' line）として表されます。これは、使用されるハッシュ関数の名前で構成され、その後にハッシュ値自体が続きます。ハッシュ値は、コロンで分離された大文字の六肢バイトのシーケンスとして表されます。バイト数は、ハッシュ関数によって定義されます。（これは、OpenSSLおよびブラウザの証明書マネージャーが使用する構文です。たとえば、HTTPダイジェスト認証[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].
フィンガープリント属性の正式な構文は、図2の拡張されたバックスナウル形式[10]に示されています。この構文は、SDPのBNF構文を拡張します[1]。
attribute =/ fingerprint-attribute
fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint
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
fingerprint = 2UHEX *(":" 2UHEX)
; Each byte in upper-case hex, separated
; by colons.
UHEX = DIGIT / %x41-46 ; A-F uppercase
Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute
図2：指紋属性の拡張バックスNAUR構文
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.
証明書の署名アルゴリズムで使用されているのと同じ一方向ハッシュ関数を使用して、証明書指紋を計算する必要があります。（これにより、証明書に必要なセキュリティプロパティも指紋に適用されることが保証されます。また、証明書自体がある限り、指紋が他のエンドポイントによって使用できることも保証します。）したがって、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 3279を更新または廃止するRFCに含まれる場合にのみ追加できます[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が、整合性保護を提供するメカニズムを介して送信される場合、構文的に有効なIDを主張する証明書を使用することができます。たとえば、HTTP/TLS [20]を介して送信されたSDPの説明またはS/MIME [17]で保護されているSDPの説明は、メディア接続を保護する証明書のIDを主張する場合があります。
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接続に提供される証明書は、接続の適切なIDを証明する必要があります。これらのシナリオでは、エンドポイントによって提示された証明書は、次のように、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.)
o メディアの説明の接続アドレスがIPアドレスとして指定されている場合、エンドポイントは、セッション説明の「C」行の接続アドレスのIPと正確に一致するiPaddressの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.)
o あるいは、セッションのSDPセッションの説明が、セッション参加者のアイデンティティがユニフォームリソース識別子（URI）によって定義されるプロトコル（SIP [16]など）を介して送信された場合、エンドポイントは統一RuseUrceIdentifierのsubjectaltnameを使用して証明書を使用する場合があります。SDPを生成したエンドポイントのIDに対応します。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 consistently provide the same certificate for each identity they support.
アイデンティティマッチングは、RFC 3280 [8]で指定されたマッチングルールを使用して実行されます。特定のタイプの複数のIDが証明書に存在する場合（たとえば、複数のDNSName名）、セットのいずれかの一致が許容可能であると見なされます。セクション7で説明されているように、証明書キャッシュの使用をサポートするために、エンドポイントは、サポートする各アイデンティティに対して一貫して同じ証明書を提供する必要があります。
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サーバーとして機能するエンドポイント（つまり、接続指向のメディアの用語で「セットアップ：パッシブ」ロールを取得するもの）は、セクション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の規則に従って証明書を提示する必要があります。サーバーは証明書を要求する必要があり、クライアントがそれを提供しない場合、または証明書が指定された指紋と一致しない場合、サーバーエンドポイントは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.
オファー/回答モデルが使用されている場合、メディア接続がオファー担当者に回答を追いかけることが可能であることに注意してください。したがって、オファーが「セットアップ：パッシブ」または「セットアップ：actPass」の役割を提供した場合、（RFC 4145 [2]で指定されているように）オファーを送信するとすぐに、着信接続を聞き始めなければなりません。ただし、TLS接続を介して送信されたデータが、SDP回答で一致する指紋を受け取るまで有効であると仮定してはなりません。指紋が到着したら、クライアントの証明書と一致しない場合、前の段落に記載されているように、サーバーのエンドポイントは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で説明されており、高レベルの概要をセクション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、Media Gateway Controlプロトコル（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.
ただし、このような整合性保護は常に可能ではありません。これらの場合、ENDシステムは、他の当事者がこのメカニズムを使用して以前に提示した証明書のキャッシュを維持する必要があります。可能であれば、以前は未知のエンドシステムに関連付けられた無担保証明書が提示された場合、ユーザーに通知する必要があり、過去に通信した当事者によって別の無担保証明書が提示される場合は強く警告する必要があります。このように、SDPの整合性保護がない場合でも、このドキュメントのメカニズムのセキュリティは、安全なシェル（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）は、構文的に有効なアイデンティティが受け入れられるモードを許可するのに十分な安全性があると考えられています。証明書。この決定は、SIPが現在、短期的に展開されたネットワークで使用される可能性が最も高い整合性メカニズムであるために行われました。ただし、このモードでは、SDPの整合性は、SIPプロキシサーバーなど、侵害または悪意のあるミドルボックスによる攻撃に対して脆弱です。End Systemsは、TCP/TLSを介して実行されるメディア形式の定義のみで保護されているSDPセッションについてユーザーに警告する場合があります。
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メッセージの送信方法に応じて、リモートパーティにリモート証明書に提示されたsumberaltaltnameが予想されるかどうかを判断することは常に可能ではありません。特に、コール転送、サードパーティのコールコントロール、またはゲートウェイコントロールプロトコル[22]によって制御されるエンドポイントによって生成されたセッションの説明がある場合、SIPがリモートSDP応答を生成するべきエンティティを決定することは常に可能ではありません。一般に、SDPの説明の信頼性と整合性保護を使用しない場合、SIPに送信される証明書は、EndpointのSIPの記録アドレスをUniformResourceIndicatorのsubjectaltnameとして主張する必要があります。エンドポイントがSIPを介して証明書を受け取った場合（iPaddressまたはdnsname IDを含む）、コールを配置または受信したもの以外の場合は、ユーザーに警告し、確認を求める必要があります。これは、証明書が自己署名されているか、認定当局によって署名されているかどうかを適用します。sipの証明書：bob@example.comは、認証機関によって合法的に署名される場合がありますが、sip：alice@example.comへの呼び出しにはまだ受け入れられない場合があります。（この問題は、この仕様に固有のものではありません。S/MIME-SIGNED SDPにはSIPに掲載された同じ考慮事項が適用されます。）
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は、安全な接続指向のメディアにとって常に最も適切な選択ではありません。場合によっては、高レベルまたは低レベルのセキュリティプロトコルが適切かもしれません。
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".
このドキュメントは、SDPプロト値「TCP/TLS」を定義しています。その形式はセクション4で定義されています。このプロト値は、「プロト」の下にある「セッション説明プロトコル（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-Field（セッションレベルとメディアレベルの両方）」の下にある「セッション説明プロトコル（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」プロト値のような新しいプロト値を定義する仕様が、メディア形式（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.
この仕様では、「Hash Function Textual Names」という名前の新しい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 3279を更新または時代遅れの標準トラックRFCで定義する必要があります[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.
o X.509証明書で使用されるハッシュ関数のオブジェクト識別子（OID）。
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 3279 [7]を更新または廃止し、X.509証明書でのハッシュ関数の使用を定義する標準トラックRFCへの参照。
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] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Yon、D。およびG. Camarillo、「セッション説明プロトコル（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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、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] International Telecommunications Union、「情報技術 - オープンシステムの相互接続 - ディレクトリ：パブリックキーおよび属性証明書フレームワーク」、ITU-T推奨X.509、ISO Standard 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.、Polk、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.、Polk、W.、Ford、W。、およびD. Solo、「インターネット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、「インターネットで使用するRSA暗号化の追加アルゴリズムと識別子X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 4055、2005年6月。
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[10] Crocker、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] 国立標準技術研究所、「Secure Hash Standard」、Fips Pub 180-2、2002年8月、<http://csrc.nist.gov/ Publications/fips/fips180-2/fips180-2.pdf>。
[12] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[12] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[13] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992.
[13] Kaliski、B。、「The MD2 Message-Digest Algorithm」、RFC 1319、1992年4月。
[14] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[14] Freed、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] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、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。、「Secure/Multipurpose Internet Mail拡張機能（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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[19] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[19] Eastlake、D。and P. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[20] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[20] Rescorla、E。、「TLS上のHTTP」、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、「The Secure Shell（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] Groves、C.、Pantaleo、M.、Anderson、T。、およびT. Taylor、「Gateway Control Protocolバージョン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.、McGrew、D.、Naslund、M.、Carrara、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.
[24] Lazzaro、J。、「リアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）パケットを接続指向の輸送上のパケット」、2006年7月、RFC 4571。
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ニューヨーク、ニューヨーク10027 US
EMail: lennox@cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。