RFC 8122 - Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8122
タイトル : RFC 8122 - セッション記述プロトコル（SDP）のトランスポート層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート
翻訳編集 : 自動生成

[要約] RFC 8122は、セッション記述プロトコル（SDP）内のトランスポート層セキュリティ（TLS）プロトコルを介した接続指向メディアトランスポートに関する仕様です。このRFCの目的は、SDPを使用してTLSを介したセキュアなメディアトランスポートを実現するためのガイドラインを提供することです。

Internet Engineering Task Force (IETF)                         J. Lennox
Request for Comments: 8122                                         Vidyo
Obsoletes: 4572                                              C. Holmberg
Category: Standards Track                                       Ericsson
ISSN: 2070-1721                                               March 2017

Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)

セッション記述プロトコル（SDP）のトランスポート層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート

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 the 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 obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.

このドキュメントは、複数のフィンガープリントの使用を明確にすることにより、RFC 4572を廃止します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8122.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8122で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Changes from RFC 4572 . . . . . . . . . . . . . . . . . .   4
   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 . . . . . . . . . .   6
     3.4.  Example SDP Description for TLS Connection  . . . . . . .   6
   4.  Protocol Identifiers  . . . . . . . . . . . . . . . . . . . .   7
   5.  Fingerprint Attribute . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Multiple Fingerprints . . . . . . . . . . . . . . . . . .   9
   6.  Endpoint Identification . . . . . . . . . . . . . . . . . . .  10
     6.1.  Certificate Choice  . . . . . . . . . . . . . . . . . . .  10
     6.2.  Certificate Presentation  . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1. Introduction

1. はじめに

The Session Description Protocol (SDP) [8] 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, "TCP-Based Media Transport in the Session Description Protocol (SDP)" [7], 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. Therefore, this document extends the TCP-Based Media specification to allow session descriptions to describe media sessions that use the Transport Layer Security (TLS) protocol [10].

セッション記述プロトコル（SDP）[8]は、アナウンスまたは招待状でマルチメディアセッションを記述するための汎用フォーマットを提供します。多くのアプリケーションでは、マルチメディアセッションの一部として、コネクション型トランスポートを使用するメディアストリームを確立することが望まれます。 RFC 4145、「Session Description Protocol（SDP）でのTCPベースのメディアトランスポート」[7]は、そのようなコネクション型ストリームを記述および確立するための一般的なメカニズムを規定しています。ただし、直接サポートするトランスポートプロトコルはTCPのみです。多くの場合、セッションの参加者は、メディアセッションに機密性、データの整合性、および認証を提供することを望んでいます。したがって、このドキュメントでは、TCPベースのメディア仕様を拡張して、セッションの説明でトランスポート層セキュリティ（TLS）プロトコルを使用するメディアセッションを説明できるようにします[10]。

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 the endpoints' IP addresses and host names are dynamic, for example, they may be obtained from DHCP. 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 to be used securely, provided that the integrity of the SDP description is assured. It allows 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 the 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では、セキュリティに関するその他の考慮事項について説明します。

1.1. Changes from RFC 4572

1.1. RFC 4572からの変更

This document obsoletes RFC 4572 [20] but remains backwards compatible with older implementations. The changes from RFC 4572 [20] are as follows:

このドキュメントはRFC 4572 [20]を廃止しますが、古い実装との後方互換性は維持されます。 RFC 4572 [20]からの変更点は次のとおりです。

o clarifies that multiple 'fingerprint' attributes can be used to carry fingerprints (calculated using different hash functions) associated with a given certificate and to carry fingerprints associated with multiple certificates.

o は、複数の「フィンガープリント」属性を使用して、特定の証明書に関連付けられたフィンガープリント（異なるハッシュ関数を使用して計算）を運び、複数の証明書に関連付けられたフィンガープリントを運ぶことができることを明確にします。

o clarifies the fingerprint matching procedure when multiple fingerprints are provided.

o 複数の指紋が提供される場合の指紋照合手順を明確にします。

o updates the preferred hash function with a stronger cipher suite and removes the requirement to use the same hash function for calculating a certificate fingerprint and certificate signature.

o 優先ハッシュ関数をより強力な暗号スイートで更新し、証明書のフィンガープリントと証明書の署名の計算に同じハッシュ関数を使用する必要をなくします。

2. Terminology

2. 用語

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

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [3]で説明されているように解釈されます。

3. Overview

3. 概観

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トランスポートを動機付ける脅威モデルについて説明します。また、エンドシステムが自己署名証明書を使用する必要性についても詳しく説明します。

3.1. SDP Operational Modes

3.1. SDP動作モード

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.

マルチメディアセッションには、アドバタイズドモードとオファーアンサーモードの2つの主要な動作モードがあります。アドバタイズされたセッションは、より単純なモードです。このモードでは、サーバーは、使用可能なマルチメディアセッションのSDPセッション記述を何らかの方法で公開します。この動作モードの典型的な例は、Session Announcement Protocol（SAP）[15]です。このプロトコルでは、SDPセッションの説明が定期的に既知のマルチキャストグループに送信されます。

Traditionally, these descriptions involve multicast conferences, but unicast sessions are also possible. (Obviously, connection-oriented media cannot use multicast.) Recipients of a session description connect to the addresses published in the session description. These recipients may not have been previously known to the advertiser of the session description.

従来、これらの説明にはマルチキャスト会議が含まれていましたが、ユニキャストセッションも可能です。（明らかに、コネクション型メディアはマルチキャストを使用できません。）セッション記述の受信者は、セッション記述で公開されたアドレスに接続します。これらの受信者は、セッションの説明の広告主に以前に知られていない可能性があります。

Alternatively, SDP conferences can operate in offer-answer mode [4]. 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) [17].

または、SDP会議はオファー/アンサーモードで動作することもできます[4]。このモードでは、マルチメディアセッションの2人の参加者が、それらの間のマルチメディアセッションをネゴシエートできます。このモデルでは、1人の参加者が他の参加者に目的のセッションの説明をその観点から提供し、他の参加者が目的のセッションで自分の観点から回答します。このモードでは、セッションの各参加者が他の参加者の知識を持っています。これは、Session Initiation Protocol（SIP）[17]によって使用される動作モードです。

3.2. Threat Model

3.2. 脅威モデル

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 externally trusted mechanism (most commonly, a mutually trusted certification authority) to validate certificates. Because the endpoints know what certificate identity to expect, endpoints can be certain that such an attack has not taken place.

さらに巧妙なのは、自分のデータトラフィックをネットワーク経由で送信できるが、有効なトラフィックを変更またはリダイレクトできない攻撃者です。 SDPの「アドバタイズ」動作モードでは、これはほとんど攻撃とは見なされません。メディアセッションは、ネットワーク上のどこからでも開始できることが期待されています。ただし、SDPのオファー応答モードでは、このタイプの攻撃はより深刻です。攻撃者は、セッションの一方または両方のエンドポイントへの接続を開始し、エンドポイントを偽装したり、途中で通信を傍受したりする可能性があります。これらの攻撃を阻止するために、TLSはエンドポイント証明書を使用します。証明書の秘密鍵が危険にさらされていない限り、エンドポイントには、証明書を検証するための外部的に信頼されたメカニズム（最も一般的には、相互に信頼された認証局）があります。エンドポイントは予期する証明書IDを知っているので、エンドポイントはそのような攻撃が行われていないことを確信できます。

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 [22] can be used to secure session descriptions.

最後に、最も深刻なタイプの攻撃者は、セッションの説明を変更またはリダイレクトできる攻撃者です。たとえば、侵害された、または悪意のあるSIPプロキシサーバーです。 TLS自体もそれを使用するメカニズムも、そのような攻撃者からSDPセッションを保護することはできません。代わりに、SDPの記述自体を何らかのメカニズムで保護する必要があります。たとえば、SIPは、S / MIME [22]を使用してセッション記述を保護する方法を定義します。

3.3. The Need for Self-Signed Certificates

3.3. 自己署名証明書の必要性

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で説明します。

3.4. Example SDP Description for TLS Connection

3.4. TLS接続のSDP説明の例

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 [7], 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」行とその属性のみを示しています。（この例は、protoパラメーターとフィンガープリント属性を除いて、RFC 4145 [7]の最初の例と同じです。）例の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-256 \
    12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
    3E:5D:49:6B:19:E5:7C:AB:4A:AD
 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説明の例

4. Protocol Identifiers

4. プロトコル識別子

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 [8] for a discussion on transport protocol identifiers.

SDPの「m」行は、特に、セッションのメディアに使用されるトランスポートプロトコルを指定します。トランスポートプロトコル識別子の説明については、SDP [8]の「Media Descriptions」セクションを参照してください。

This specification defines the protocol identifier, 'TCP/TLS', which indicates that the media described will use the Transport Layer Security protocol [10] 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 an fmt identifier to indicate the application being run over TLS.

この仕様は、プロトコル識別子「TCP / TLS」を定義します。これは、説明されているメディアがTCPを介してトランスポート層セキュリティプロトコル[10]を使用することを示します。（他のトランスポートプロトコルでのTLSの使用については、このドキュメントでは説明していません。）「TCP / TLS」プロトコル識別子は、トランスポートプロトコルのみを記述し、上位層プロトコルは記述しません。「TCP / TLS」を指定する「m」行は、アプリケーションがTLSで実行されていることを示すために、fmt識別子を使用してプロトコルをさらに修飾する必要があります。

Media sessions described with this identifier follow the procedures defined in RFC 4145 [7]. They also use the SDP attributes defined in that specification, 'setup' and 'connection'.

この識別子で記述されたメディアセッションは、RFC 4145 [7]で定義された手順に従います。また、その仕様で定義されている「セットアップ」および「接続」のSDP属性も使用します。

5. Fingerprint Attribute

5. 指紋属性

Parties to a TLS session indicate their identities by presenting authentication certificates as part of the TLS handshake procedure. Authentication certificates are X.509 [2] certificates, as profiled by RFCs 3279 [5], 5280 [11], and 4055 [6].

TLSセッションの当事者は、TLSハンドシェイク手順の一部として認証証明書を提示することにより、IDを示します。認証証明書は、RFC 3279 [5]、5280 [11]、および4055 [6]でプロファイルされているX.509 [2]証明書です。

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 Distinguished Encoding Rules (DER) 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.)

証明書のフィンガープリントは、証明書のDistinguished Encoding Rules（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, for example, HTTP digest authentication [24], which uses unseparated lowercase hexadecimal bytes. Consistency with other applications of fingerprints was considered more important.)

指紋はSDPで属性（「a」行）として表されます。これは、使用されるハッシュ関数の名前と、それに続くハッシュ値自体で構成されます。ハッシュ値は、コロンで区切られた一連の大文字の16進数バイトとして表されます。バイト数はハッシュ関数によって定義されます。（これは、opensslおよびブラウザーの証明書マネージャーによって使用される構文です。これは、たとえば、分離されていない小文字の16進バイトを使用するHTTPダイジェスト認証[24]でハッシュ値を表すために使用される構文とは異なります。他のアプリケーションとの整合性指紋の方がより重要であると考えられました。）

The formal syntax of the fingerprint attribute is given in Augmented Backus-Naur Form [9] in Figure 2. This syntax extends the BNF syntax of SDP [8].

指紋属性の正式な構文は、図2のAugmented Backus-Naur Form [9]に示されています。この構文は、SDP [8]のBNF構文を拡張したものです。

attribute =/ fingerprint-attribute

属性= /指紋属性

fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint

指紋属性= "指紋" "："ハッシュ関数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

fingerprint = 2UHEX *(":" 2UHEX) ; Each byte in upper-case hex, separated ; by colons.

フィンガープリント= 2UHEX *（ "：" 2UHEX）;大文字の16進数で区切られた各バイト。コロンによって。

   UHEX                   =  DIGIT / %x41-46 ; A-F uppercase

Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute

図2：指紋属性の拡張バッカスナウア構文

Following RFC 3279 [5] as updated by RFC 4055 [6], the defined hash functions are 'SHA-1' [1] [16], 'SHA-224' [1], 'SHA-256' [1], 'SHA-384' [1], 'SHA-512' [1], 'MD5' [13], and 'MD2' [23], with 'SHA-256' preferred. A new IANA registry, named "Hash Function Textual Names", specified in Section 8, allows for the addition of future tokens, but they may only be added if they are included in RFCs that update or obsolete RFC 3279 [5].

RFC 4055 [6]によって更新されたRFC 3279 [5]に従い、定義されているハッシュ関数は「SHA-1」[1] [16]、「SHA-224」[1]、「SHA-256」[1]、「SHA-384」[1]、「SHA-512」[1]、「MD5」[13]、および「MD2」[23]。「SHA-256」が推奨されます。セクション8で指定された「ハッシュ関数テキスト名」という名前の新しいIANAレジストリでは、将来のトークンを追加できますが、RFC 3279を更新または廃止するRFCに含まれている場合にのみ追加できます[5]。

Implementations compliant with this specification MUST NOT use the MD2 and MD5 hash functions to calculate fingerprints or to verify received fingerprints that have been calculated using them.

この仕様に準拠する実装は、MD2およびMD5ハッシュ関数を使用してフィンガープリントを計算したり、それらを使用して計算された受信フィンガープリントを検証したりしてはなりません（MUST NOT）。

Note: The MD2 and MD5 hash functions are listed in this specification so that implementations can recognize them. Implementations that log unused hash functions might log occurrences of these algorithms differently to unknown hash algorithms.

注：MD2およびMD5ハッシュ関数は、実装が認識できるように、この仕様にリストされています。未使用のハッシュ関数をログに記録する実装では、これらのアルゴリズムの発生を未知のハッシュアルゴリズムとは異なる方法で記録する場合があります。

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セッションに適用されます。

5.1. Multiple Fingerprints

5.1. 複数の指紋

Multiple SDP fingerprint attributes can be associated with an 'm' line. This can occur if multiple fingerprints have been calculated for a certificate using different hash functions. It can also occur if one or more fingerprints associated with multiple certificates have been calculated. This might be needed if multiple certificates will be used for media associated with an 'm' line (e.g., if separate certificates are used for RTP and the RTP Control Protocol (RTCP)) or where it is not known which certificate will be used when the fingerprints are exchanged. In such cases, one or more fingerprints MUST be calculated for each possible certificate.

複数のSDPフィンガープリント属性を「m」行に関連付けることができます。これは、異なるハッシュ関数を使用して証明書の複数のフィンガープリントが計算された場合に発生する可能性があります。また、複数の証明書に関連付けられた1つ以上のフィンガープリントが計算されている場合にも発生する可能性があります。これは、「m」行に関連付けられたメディアに複数の証明書が使用される場合（たとえば、RTPとRTP制御プロトコル（RTCP）に別々の証明書が使用される場合）、またはどの証明書をいつ使用するかわからない場合に必要になることがあります。指紋が交換されます。そのような場合、1つまたは複数のフィンガープリントを、考えられる証明書ごとに計算する必要があります。

An endpoint MUST, as a minimum, calculate a fingerprint using both the 'SHA-256' hash function algorithm and the hash function used to generate the signature on the certificate for each possible certificate. Including the hash from the signature algorithm ensures interoperability with strict implementations of RFC 4572 [20]. Either of these fingerprints MAY be omitted if the endpoint includes a hash with a stronger hash algorithm that it knows that the peer supports, if it is known that the peer does not support the hash algorithm, or if local policy mandates use of stronger algorithms.

エンドポイントは、最低限、「SHA-256」ハッシュ関数アルゴリズムと、可能な証明書ごとに証明書の署名を生成するために使用されるハッシュ関数の両方を使用してフィンガープリントを計算する必要があります。署名アルゴリズムからのハッシュを含めることにより、RFC 4572 [20]の厳密な実装との相互運用性が保証されます。エンドポイントに、ピアがサポートしていることがわかっているより強力なハッシュアルゴリズムのハッシュが含まれている場合、ピアがハッシュアルゴリズムをサポートしていないことがわかっている場合、またはローカルポリシーがより強力なアルゴリズムの使用を要求している場合は、これらのフィンガープリントのいずれかを省略できます。

If fingerprints associated with multiple certificates are calculated, the same set of hash functions MUST be used to calculate fingerprints for each certificate associated with the 'm' line.

複数の証明書に関連付けられたフィンガープリントを計算する場合、同じハッシュ関数のセットを使用して、「m」行に関連付けられた各証明書のフィンガープリントを計算する必要があります。

An endpoint MUST select the set of fingerprints that use its most preferred hash function (out of those offered by the peer) and verify that each certificate used matches one fingerprint out of that set.

エンドポイントは、（ピアによって提供されたものから）最も好ましいハッシュ関数を使用するフィンガープリントのセットを選択し、使用される各証明書がそのセットからの1つのフィンガープリントと一致することを確認する必要があります。

If a certificate does not match any such fingerprint, the endpoint MUST NOT establish the TLS connection.

証明書がそのようなフィンガープリントと一致しない場合、エンドポイントはTLS接続を確立してはなりません（MUST NOT）。

Note: The SDP fingerprint attribute does not contain a reference to a specific certificate. Endpoints need to compare the fingerprint with a certificate hash in order to look for a match.

注：SDPフィンガープリント属性には、特定の証明書への参照は含まれていません。エンドポイントは、一致を探すために、フィンガープリントを証明書ハッシュと比較する必要があります。

6. Endpoint Identification

6. エンドポイントの識別

6.1. Certificate Choice

6.1. 証明書の選択

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 [14] or secured by S/MIME [22] MAY assert any identity in the certificate securing the media connection.

X.509証明書は、IDと公開鍵をバインドします。 TLSセッションを記述するSDPが完全性保護を提供するメカニズムを介して送信される場合、構文的に有効なIDを表明する証明書が使用される場合があります。たとえば、HTTP / TLS [14]経由で送信された、またはS / MIMEによって保護された[22] SDP記述は、メディア接続を保護する証明書のIDをアサートできます。

Security protocols that provide only hop-by-hop integrity protection (e.g., the SIPS scheme [17], 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スキーム[17]、SIP over TLS）は、有効なIDが受け入れられるモードを許可するのに十分に安全であると見なされます。ただし、この事実のセキュリティへの影響については、セクション7を参照してください。

In situations where the SDP is not integrity-protected, 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 [17]) 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セッション記述がプロトコル（SIP [17]など）を介して送信され、セッション参加者のIDがURI（Uniform Resource Identifier）によって定義されている場合、エンドポイントは、uniformResourceIdentifierを持つ証明書を使用できます（MAY） SDPを生成したエンドポイントのIDに対応するsubjectAltName。どのURIが有効であるかの詳細は、送信プロトコルによって異なります。（URIの有効性の詳細については、セクション7を参照してください。

Identity matching is performed using the matching rules specified by RFC 5280 [11]. 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.

IDマッチングは、RFC 5280 [11]で指定されているマッチングルールを使用して実行されます。特定のタイプの複数のIDが証明書に存在する場合（たとえば、複数のdNSName名）、セットのいずれか1つでの一致は許容できると見なされます。セクション7で説明されているように、証明書キャッシュの使用をサポートするために、エンドポイントは、サポートするアイデンティティごとに一貫して同じ証明書を提供する必要があります（SHOULD）。

6.2. Certificate Presentation

6.2. 証明書の提示

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サーバーとして機能するエンドポイント（つまり、接続指向メディアの用語で「setup：passive」の役割を担うエンドポイント）は、セクション6.1で提示された規則に従って、TLSの開始時に証明書を提示する必要があります。証明書が元のフィンガープリントと一致しない場合、クライアントエンドポイントはbad_certificateエラーでメディア接続を終了する必要があります。

If the SDP offer/answer model [4] 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; if the client does not provide one, or if the certificate does not match a provided fingerprint, the server endpoint MUST terminate the media connection with a bad_certificate error.

SDPオファー/アンサーモデル[4]が使用されている場合、クライアント（「setup：active」ロールを持つエンドポイント）は、セクション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 [7]) 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.

オファー/アンサーモデルが使用されている場合、メディア接続が回答よりも長くオファーを返す可能性があることに注意してください。したがって、提供者が「setup：passive」または「setup：actpass」の役割を提供した場合、提供者は（RFC 4145 [7]で指定されているように）提供を送信するとすぐに着信接続の待機を開始する必要があります。ただし、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がSession Announcement Protocol [15]を介して送信された場合など）、クライアントが証明書のフィンガープリントをサーバーに通信するために使用できる安全なチャネルはありません。この場合、サーバーはクライアント証明書を要求することができ（MAY）、既知の証明機関によって署名される必要があります（SHOULD）、またはクライアントが証明書なしで接続できるようにする場合があります（MAY）。

7. Security Considerations

7. セキュリティに関する考慮事項

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 [8] for security considerations applicable to SDP in general.

このドキュメント全体は、セキュリティに関するものです。解決すべき問題はセクション1で扱われ、高レベルの概要はセクション3で提示されます。SDP全般に適用可能なセキュリティの考慮事項については、SDP仕様[8]を参照してください。

Offering a TCP/TLS connection in SDP (or agreeing to one in the 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オファー/アンサーモードで同意する）ことで、エンドポイントが指定されたフィンガープリントを使用してTLS接続を受け入れる義務が生じることはありません。代わりに、エンドポイントは標準のTLSネゴシエーション手順を実行して、選択されたTLSストリーム暗号とMACアルゴリズムが上位アプリケーションのセキュリティニーズを満たすようにする必要があります。（たとえば、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など）を利用する必要があります（SHOULD）。このセキュリティサービスは、強力なメッセージ認証と効果的なリプレイ保護を提供する必要があります（SHOULD）。

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 [18], 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 the SDP descriptions sent over an integrity-protected channel.

ただし、このような整合性保護は常に可能であるとは限りません。これらの場合、エンドシステムは、このメカニズムを使用して他のパーティが以前に提示した証明書のキャッシュを維持する必要があります（SHOULD）。可能であれば、以前は不明であったエンドシステムに関連付けられた非セキュアな証明書が提示されたときにユーザーに通知する必要があり（SHOULD）、過去に通信した当事者が別の非セキュアな証明書を提示した場合は強く警告する必要があります。このように、SDPの整合性保護がない場合でも、このドキュメントのメカニズムのセキュリティは、セキュアシェル（SSH）プロトコル[18]のセキュリティと同等です。これは、2つの場合に中間者攻撃に対して脆弱です。当事者は最初に通信しますが、その後発生するものを検出できます。（「相手」の正確な定義は、SDPメッセージを伝送するアプリケーションプロトコルに依存することに注意してください。）ただし、ユーザーは、整合性保護されたチャネルを介して送信されるSDPの説明に記載されている証明書について通知されるべきではありません。

To aid interoperability and deployment, security protocols that provide only hop-by-hop integrity protection (e.g., the SIPS scheme [17], 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スキーム[17]、SIP over TLS）は、構文的に有効な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 [21], 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 the 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 it 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がリモートパーティに期待されるかどうかを常に判断できるとは限りません。特に、コール転送、サードパーティコール制御、またはゲートウェイ制御プロトコル[21]によって制御されるエンドポイントによって生成されたセッション記述が与えられた場合、SIPでリモートSDP応答を生成する必要があるエンティティを特定することが常に可能であるとは限りません。一般に、SDP記述の信頼性と整合性保護を使用しない場合、SIPを介して送信される証明書は、エンドポイントのレコードのSIPアドレスをuniformResourceIndicator subjectAltNameとしてアサートする必要があります（SHOULD）。エンドポイントがSIPを介して証明書を受信すると、通話の発信または受信以外のID（iPAddressまたはdNSName IDを含む）をアサートする場合、エンドポイントはユーザーに警告して確認を求める必要があります。これは、証明書が自己署名されているか、証明機関によって署名されているかに関係なく適用されます。「sip：bob@example.com」の証明書は、認証局によって正当に署名されている可能性がありますが、「sip：alice@example.com」への呼び出しにはまだ受け入れられない場合があります。（この問題は、この仕様に固有の問題ではありません。SIPで伝送されるS / MIME署名付きSDPにも同じ考慮事項が適用されます。）

This document does not define a mechanism for securely transporting RTP and RTCP packets over a connection-oriented channel. Please see RFC 7850 [19] for more details.

このドキュメントでは、コネクション型チャネルを介してRTPおよびRTCPパケットを安全に転送するメカニズムを定義していません。詳細については、RFC 7850 [19]を参照してください。

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 improves security from RFC 4572 [20]. It updates the preferred hash function from SHA-1 to SHA-256 and deprecates the usage of the MD2 and MD5 hash functions.

このドキュメントはRFC 4572 [20]からセキュリティを改善します。優先ハッシュ関数をSHA-1からSHA-256に更新し、MD2およびMD5ハッシュ関数の使用を廃止します。

By clarifying the usage and handling of multiple fingerprints, the document also enables hash agility and incremental deployment of newer and more secure hash functions.

複数のフィンガープリントの使用と処理を明確にすることにより、ドキュメントはハッシュの俊敏性と、より新しく安全なハッシュ関数の段階的な展開も可能にします。

8. IANA Considerations

8. IANAに関する考慮事項

IANA has updated the registrations defined in RFC 4572 [20] to refer to this specification.

IANAは、RFC 4572 [20]で定義されている登録を更新して、この仕様を参照しています。

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 the "proto" registry within the "Session Description Protocol (SDP) Parameters" registry.

このドキュメントでは、SDPプロト値「TCP / TLS」を定義しています。その形式はセクション4で定義されています。このproto値は、IANAによって「Session Description Protocol（SDP）Parameters」レジストリ内の「proto」レジストリの下に登録されています。

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 the "att-field (both session and media level)" registry within the "Session Description Protocol (SDP) Parameters" registry.

このドキュメントでは、SDPセッションとメディアレベルの属性「fingerprint」を定義しています。その形式はセクション5で定義されています。この属性は、IANAによって「Session Description Protocol（SDP）Parameters」レジストリ内の「att-field（session and media level）」レジストリの下に登録されています。

The SDP specification [8] 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 [12] by production of, or reference to, a Standards Track RFC that defines the transport protocol for the format.

SDP仕様[8]では、このプロトコルで定義されている「TCP / TLS」プロト値のような新しいプロト値を定義する仕様は、メディアフォーマット（fmt）名前空間を管理するルールを定義する必要があると述べています。 TCP / TLSプロトコルの場合、新しいフォーマットにはMIME登録が関連付けられている必要があります（SHOULD）。フォーマットに既存のMIMEサブタイプを使用することをお勧めします。 MIMEサブタイプが存在しない場合は、形式のトランスポートプロトコルを定義するStandards Track RFCの作成または参照によって、IETFプロセス[12]を通じて適切なサブタイプを登録することをお勧めします。

IANA has updated the "Hash Function Textual Names" registry (which was originally created in [20]) to refer to this document.

IANAは、このドキュメントを参照するために（[20]で最初に作成された） "Hash Function Textual Names"レジストリを更新しました。

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 [5].

証明書のフィンガープリントに使用されるハッシュ関数の名前は、IANAによって登録されます。ハッシュ関数は、RFC 3279を更新または廃止するStandards Track RFCによって定義する必要があります[5]。

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 that updates or obsoletes RFC 3279 [5] and defines the use of the hash function in X.509 certificates.

o RFC 3279 [5]を更新または廃止し、X.509証明書でのハッシュ関数の使用を定義する、Standards Track RFCへの参照。

Table 1 contains the initial values of this registry.

表1には、このレジストリの初期値が含まれています。

        +--------------------+------------------------+-----------+
        | 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 |
        +--------------------+------------------------+-----------+

Table 1: IANA Hash Function Textual Name Registry

表1：IANAハッシュ関数テキスト名レジストリ

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[1] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.

[1] 国立標準技術研究所、「Secure Hash Standard（SHS）」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<http://nvlpubs.nist.gov/nistpubs/FIPS / NIST.FIPS.180-4.pdf>。

[2] International Organization for Standardization, "Information technology -- Open Systems Interconnection -- The Directory -- Part 8: Public-key and attribute certificate frameworks", ISO/IEC 9594-8:2014, March 2014, <https://www.iso.org/standard/64854.html>.

[2] 国際標準化機構、「情報技術-オープンシステム相互接続-ディレクトリ-パート8：公開鍵および属性証明書フレームワーク」、ISO / IEC 9594-8：2014、2014年3月、<https：// www。 iso.org/standard/64854.html>。

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[3] Bradner、S.、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。

[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.

[4] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<http://www.rfc-editor.org/info/ rfc3264>。

[5] 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, DOI 10.17487/RFC3279, April 2002, <http://www.rfc-editor.org/info/rfc3279>.

[5] 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、DOI 10.17487 / RFC3279、April 2002、 <http://www.rfc-editor.org/info/rfc3279>。

[6] 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, DOI 10.17487/RFC4055, June 2005, <http://www.rfc-editor.org/info/rfc4055>.

[6] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号化の追加のアルゴリズムと識別子」、RFC 4055、DOI 10.17487 / RFC4055、2005年6月、<http://www.rfc-editor.org/info/rfc4055>。

[7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, <http://www.rfc-editor.org/info/rfc4145>.

[7] Yon、D.、G。Camarillo、「Session Description Protocol（SDP）におけるTCPベースのメディアトランスポート」、RFC 4145、DOI 10.17487 / RFC4145、2005年9月、<http://www.rfc-editor.org/info / rfc4145>。

[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.

[8] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/info/rfc4566 >。

[9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

[9] クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。

[10] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[10] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info/rfc5246> 。

[11] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.

[11] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile」、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。

[12] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.

[12] Freed、N.、Klensin、J。、およびT. Hansen、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<http://www.rfc-editor.org / info / rfc6838>。

9.2. Informative References

9.2. 参考引用

[13] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.

[13] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、DOI 10.17487 / RFC1321、1992年4月、<http://www.rfc-editor.org/info/rfc1321>。

[14] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.

[14] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。

[15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>.

[15] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、DOI 10.17487 / RFC2974、2000年10月、<http://www.rfc-editor.org/info/rfc2974>。

[16] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, <http://www.rfc-editor.org/info/rfc3174>.

[16] Eastlake 3rd、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、DOI 10.17487 / RFC3174、2001年9月、<http://www.rfc-editor.org/info/rfc3174>。

[17] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.

[17] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」、RFC 3261 、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。

[18] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <http://www.rfc-editor.org/info/rfc4251>.

[18] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、DOI 10.17487 / RFC4251、2006年1月、<http://www.rfc-editor.org/info/rfc4251 >。

[19] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, <http://www.rfc-editor.org/info/rfc4571>.

[19] Lazzaro、J。、「接続指向のトランスポートを介したフレーミングリアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）パケット」、RFC 4571、DOI 10.17487 / RFC4571、2006年7月、<http：//www.rfc- editor.org/info/rfc4571>。

[20] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, DOI 10.17487/RFC4572, July 2006, <http://www.rfc-editor.org/info/rfc4572>.

[20] Lennox、J。、「セッション記述プロトコル（SDP）のトランスポート層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」、RFC 4572、DOI 10.17487 / RFC4572、2006年7月、<http：//www.rfc- editor.org/info/rfc4572>。

[21] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, DOI 10.17487/RFC5125, February 2008, <http://www.rfc-editor.org/info/rfc5125>.

[21] テイラーT。、「RFC 3525の歴史的分類」、RFC 5125、DOI 10.17487 / RFC5125、2008年2月、<http://www.rfc-editor.org/info/rfc5125>。

[22] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.

[22] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、DOI 10.17487 / RFC5751、2010年1月、<http://www.rfc-editor.org / info / rfc5751>。

[23] Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, DOI 10.17487/RFC6149, March 2011, <http://www.rfc-editor.org/info/rfc6149>.

[23] ターナー、S。およびL.チェン、「MD2 to Historic Status」、RFC 6149、DOI 10.17487 / RFC6149、2011年3月、<http://www.rfc-editor.org/info/rfc6149>。

[24] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.

[24] Shekh-Yusef、R.、Ed。、Ahrens、D.、and S. Bremer、 "HTTP Digest Access Authentication"、RFC 7616、DOI 10.17487 / RFC7616、September 2015、<http://www.rfc-editor.org / info / rfc7616>。

Acknowledgments

謝辞

This document included significant contributions by Cullen Jennings, Paul Kyzivat, Roman Shpount, and Martin Thomson. Elwyn Davies performed the Gen-ART review of the document.

このドキュメントには、カレンジェニングス、ポールキジバット、ローマンシュプント、マーティントムソンによる重要な寄稿が含まれています。 Elwyn DaviesがドキュメントのGen-ARTレビューを行いました。

Authors' Addresses

著者のアドレス

Jonathan Lennox Vidyo

ジョナサンレノックスVidyo

   Email: jonathan@vidyo.com

Christer Holmberg Ericsson

クリスター・ホルムバーグ・エリクソン

   Email: christer.holmberg@ericsson.com