[要約] RFC 8862は、SIPでシグナリングされたRTPメディアのセキュリティを確保するためのベストプラクティスを提供します。このRFCの目的は、通信セッションのプライバシーと機密性を保護し、不正アクセスや盗聴から通信を守ることです。
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 8862 Neustar
BCP: 228 R. Barnes
Category: Best Current Practice Cisco
ISSN: 2070-1721 R. Housley
Vigil Security
January 2021
Best Practices for Securing RTP Media Signaled with SIP
SIPでシグナリングされたRTPメディアを固定するためのベストプラクティス
Abstract
概要
Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities.
セッション開始プロトコル（SIP）には、長年にわたる多数の仕様によって拡張されたセキュリティサービスの一連のセキュリティサービスが含まれていますが、SIPの使用方法を説明する方法は、機密メディアセッションを確立する方法はありません。さらに、既存のメカニズムには、汎用モニタリング脅威モデルに対処するために識別され解決される必要があるいくつかの機能ギャップがあります。この仕様は、メディア層をSIPレイヤーIDにバインドする包括的な保護ソリューションを含む、SIPを使用して機密メディアを交渉するためのベストプラクティスを説明しています。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモはインターネットの最高の現在の練習を文書化しています。
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 BCPs is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。BCPの詳細情報はRFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8862.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8862で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Security at the SIP and SDP Layer
4. STIR Profile for Endpoint Authentication and Verification
Services
4.1. Credentials
4.2. Anonymous Communications
4.3. Connected Identity Usage
4.4. Authorization Decisions
5. Media Security Protocols
6. Relayed Media and Conferencing
7. ICE and Connected Identity
8. Best Current Practices
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses
The Session Initiation Protocol (SIP) [RFC3261] includes a suite of security services, including Digest Authentication [RFC7616] for authenticating entities with a shared secret, TLS [RFC8446] for transport security, and (optionally) S/MIME [RFC8551] for body security. SIP is frequently used to establish media sessions -- in particular, audio or audiovisual sessions, which have their own security mechanisms available, such as the Secure Real-time Transport Protocol (SRTP) [RFC3711]. However, the practices needed to bind security at the media layer to security at the SIP layer, to provide an assurance that protection is in place all the way up the stack, rely on a great many external security mechanisms and practices. This document provides documentation to explain their optimal use as a best practice.
セッション開始プロトコル（SIP）[RFC3261]には、トランスポートセキュリティのための共有シークレット、TLS [RFC8446]、（オプションで）S / MIME [RFC8551]のためのエンティティを認証するためのダイジェスト認証[RFC7616]を含むセキュリティサービスの一連のセキュリティサービスが含まれています。ボディセキュリティSIPは、特に、セキュアリアルタイムトランスポートプロトコル（SRTP）[RFC3711]など、独自のセキュリティメカニズムを使用できるオーディオまたはオーディオビジュアルセッションを確立するために頻繁に使用されます。しかし、SIPレイヤでセキュリティをセキュリティにバインドするために必要とされる慣行は、保護がスタックのすべての途中にあるという保証を提供し、非常に多くの外部のセキュリティメカニズムと慣行に依存しているという保証を提供します。この資料は、最適な使用として最適な使用を説明するためのドキュメントを提供します。
Revelations about widespread pervasive monitoring of the Internet have led to a greater desire to protect Internet communications [RFC7258]. In order to maximize the use of security features, especially of media confidentiality, opportunistic measures serve as a stopgap when a full suite of services cannot be negotiated all the way up the stack. Opportunistic media security for SIP is described in [RFC8643], which builds on the prior efforts of [Best-Effort-SRTP]. With opportunistic encryption, there is an attempt to negotiate the use of encryption, but if the negotiation fails, then cleartext is used. Opportunistic encryption approaches typically have no integrity protection for the keying material.
インターネットの広範な普及監視についての啓示は、インターネット通信を保護したいという願望をもたらしました[RFC7258]。特にメディア機密性のセキュリティ機能の使用を最大化するために、国際スイートのサービスをスタック全体に交渉できない場合、日和見主義的措置はストップガップとして機能します。SIPのための日和見主義的なメディアセキュリティは[RFC8643]で説明されています。日和見論的暗号化では、暗号化の使用をネゴシエートする試みがありますが、ネゴシエーションが失敗した場合は、ClearTextが使用されます。日和見論的暗号化アプローチは、通常、キーイング材料の完全性保護はありません。
This document contains the SIP Best-practice Recommendations Against Network Dangers to privacY (SIPBRANDY) profile of Secure Telephone Identity Revisited (STIR) [RFC8224] for media confidentiality, providing a comprehensive security solution for SIP media that includes integrity protection for keying material and offers application-layer assurance that media confidentiality is in place. Various specifications that User Agents (UAs) must implement to support media confidentiality are given in the sections below; a summary of the best current practices appears in Section 8.
この文書には、ネットワークの危険に対するSIPベストプラクティス推奨事項が含まれています。メディアの機密性が整っているアプリケーション層保証。以下のセクションでは、メディア機密性をサポートするためにユーザーエージェント（UAS）が実装する必要がある様々な仕様を示しています。最良の現在の慣行の概要がセクション8に表示されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
There are two approaches to providing confidentiality for media sessions set up with SIP: comprehensive protection and opportunistic security (as defined in [RFC7435]). This document only addresses comprehensive protection.
SIP：包括的な保護と日和見的セキュリティ（[RFC7435]で定義されているように）のメディアセッションの機密性を提供するための2つのアプローチがあります。この文書は包括的な保護にのみ対処します。
Comprehensive protection for media sessions established by SIP requires the interaction of three protocols: the Session Initiation Protocol (SIP) [RFC3261], the Session Description Protocol (SDP) [RFC4566], and the Real-time Transport Protocol (RTP) [RFC3550] -- in particular, its secure profile SRTP [RFC3711]. Broadly, it is the responsibility of SIP to provide integrity protection for the media keying attributes conveyed by SDP, and those attributes will in turn identify the keys used by endpoints in the RTP media session(s) that SDP negotiates.
SIPによって確立されたメディアセッションの包括的な保護には、セッション開始プロトコル（SIP）[RFC3261]、セッション記述プロトコル（SDP）[RFC4566]、およびリアルタイムトランスポートプロトコル（RFC3550]。 - 特に、その安全なプロファイルSRTP [RFC3711]。概して、SDPによって伝達されたメディアキーイング属性に対する完全性保護を提供することはSIPの責任であり、それらの属性はSDPが交渉するRTPメディアセッション内のエンドポイントによって使用されるキーを識別します。
Note that this framework does not apply to keys that also require confidentiality protection in the signaling layer, such as the SDP "k=" line, which MUST NOT be used in conjunction with this profile.
このフレームワークは、SDP "k ="行など、シグナリングレイヤーの機密保護を必要とするキーには適用されません。これは、このプロファイルと一緒に使用してはいけません。
In that way, once SIP and SDP have exchanged the necessary information to initiate a session, media endpoints will have a strong assurance that the keys they exchange have not been tampered with by third parties and that end-to-end confidentiality is available.
このようにして、SIPとSDPがセッションを開始するために必要な情報を交換したら、メディアエンドポイントは、彼らが交換したキーが第三者によって改ざんされていないこと、そしてエンドツーエンドの機密性が利用可能であるという強い保証を持ちます。
To establish the identity of the endpoints of a SIP session, this specification uses STIR [RFC8224]. The STIR Identity header has been designed to prevent a class of impersonation attacks that are commonly used in robocalling, voicemail hacking, and related threats. STIR generates a signature over certain features of SIP requests, including header field values that contain an identity for the originator of the request, such as the From header field or P-Asserted-Identity field, and also over the media keys in SDP if they are present. As currently defined, STIR provides a signature over the "a=fingerprint" attribute, which is a fingerprint of the key used by DTLS-SRTP [RFC5763]; consequently, STIR only offers comprehensive protection for SIP sessions in concert with SDP and SRTP when DTLS-SRTP is the media security service. The underlying Personal Assertion Token (PASSporT) object [RFC8225] used by STIR is extensible, however, and it would be possible to provide signatures over other SDP attributes that contain alternate keying material. A profile for using STIR to provide media confidentiality is given in Section 4.
SIPセッションのエンドポイントの身元を確立するために、この仕様はSTIR [RFC8224]を使用しています。 Sticle Identityヘッダーは、RoboCalling、Voicemail Hacking、および関連する脅威に一般的に使用されるクラスの偽装攻撃を防ぐように設計されています。 SCITは、SIP要求の特定の機能を介してシグネチャを生成します。これは、[From Header]フィールドまたはPアサートIDフィールドなど、SDPのメディアキーを介して、SDPのメディアキーを介したヘッダーフィールド値を含むシグネチャを生成します。存在しています。現在定義されているように、STIONはDTLS-SRTP [RFC5763]によって使用されるキーの指紋である「a = fingerprint」属性を越えて署名を提供します。その結果、DTLS-SRTPがMedia Security Serviceである場合、STICはSDPとSRTPとのコンサートでSIPセッションの包括的な保護のみを提供します。攪拌によって使用される基礎となる個人的な主張トークン[RFC8225]は拡張可能であり、代替のキーイング材料を含む他のSDP属性よりも署名を提供することが可能であろう。めちゃくちゃの機密性を提供するためのプロファイルはセクション4に示されています。
STIR [RFC8224] defines the Identity header field for SIP, which provides a cryptographic attestation of the source of communications. This document includes a profile of STIR, called the SIPBRANDY profile, where the STIR verification service will act in concert with an SRTP media endpoint to ensure that the key fingerprints, as given in SDP, match the keys exchanged to establish DTLS-SRTP. To satisfy this condition, the verification service function would in this case be implemented in the SIP User Agent Server (UAS), which would be composed with the media endpoint. If the STIR authentication service or verification service functions are implemented at an intermediary rather than an endpoint, this introduces the possibility that the intermediary could act as a man in the middle, altering key fingerprints. As this attack is not in STIR's core threat model, which focuses on impersonation rather than man-in-the-middle attacks, STIR offers no specific protections against such interference.
STIR [RFC8224] SIPのIDヘッダーフィールドを定義します。これは、通信元の暗号化検証を提供します。この文書には、SPRANDYプロファイルと呼ばれるSTIPBRANDYプロファイルと呼ばれる、STRTPメディアエンドポイントがSDPで行われているように、SDPで行われたキーの指紋がDTLS-SRTPを確立するように確実に一致させるように、STIPBRANDYプロファイルと呼ばれるプロファイルを含みます。この状態を満たすために、この場合、検証サービス機能はSIPユーザエージェントサーバ（UAS）で実装され、これはメディアエンドポイントで構成されます。攪拌認証サービスまたは検証サービス機能がエンドポイントではなく仲介者に実装されている場合、これは仲介者が中央の男として機能し、キー指紋を変更する可能性をもたらします。この攻撃は、中間攻撃ではなく偽装に焦点を当てています。
The SIPBRANDY profile for media confidentiality thus shifts these responsibilities to the endpoints rather than the intermediaries. While intermediaries MAY provide the verification service function of STIR for SIPBRANDY transactions, the verification needs to be repeated at the endpoint to obtain end-to-end assurance. Intermediaries supporting this specification MUST NOT block or otherwise redirect calls if they do not trust the signing credential. The SIPBRANDY profile is based on an end-to-end trust model, so it is up to the endpoints to determine if they support signing credentials, not intermediaries.
メディア機密性のためのSipbrandyプロファイルは、これらの責任を仲介者ではなくエンドポイントにシフトします。仲介者はSipbrandyトランザクションのために攪拌の検証サービス機能を提供するかもしれませんが、エンドツーエンドの保証を得るためにエンドポイントで検証を繰り返す必要があります。この仕様をサポートする仲介者は、署名信用証明書を信頼していない場合は、呼び出しをブロックまたはリダイレクトしてはいけません。Sipbrandyプロファイルはエンドツーエンドの信頼モデルに基づいているので、仲介者ではなく資格情報の署名をサポートしているかどうかを判断するためのエンドポイント次第です。
In order to be compliant with best practices for SIP media confidentiality with comprehensive protection, UA implementations MUST implement both the authentication service and verification service roles described in [RFC8224]. STIR authentication services MUST signal their compliance with this specification by including the "msec" claim defined in this specification to the PASSporT payload. Implementations MUST provide key fingerprints in SDP and the appropriate signatures over them as specified in [RFC8225].
包括的な保護を備えたSIPメディア機密性のためのベストプラクティスに準拠するためには、UA実装は[RFC8224]に記載されている認証サービスと検証サービスの両方の役割を実装する必要があります。この仕様書に定義された「MSEC」請求をパスポートペイロードに含めることで、この仕様書に準拠している必要があります。実装は、SDP内のキー指紋と[RFC8225]で指定されているように適切な署名を提供する必要があります。
When generating either an offer or an answer [RFC3264], compliant implementations MUST include an "a=fingerprint" attribute containing the fingerprint of an appropriate key (see Section 4.1).
オファーまたはアンサー[RFC3264]のいずれかを生成する場合、準拠の実装には、適切なキーの指紋を含む「a = fingerprint」属性を含める必要があります（セクション4.1を参照）。
In order to implement the authentication service function in the UA, SIP endpoints will need to acquire the credentials needed to sign for their own identity. That identity is typically carried in the From header field of a SIP request and contains either a greenfield SIP URI (e.g., "sip:alice@example.com") or a telephone number (which can appear in a variety of ways, e.g., "sip:+17004561212@example.com;user=phone"). Section 8 of [RFC8224] contains guidance for separating the two and determining what sort of credential is needed to sign for each.
UAで認証サービス機能を実装するために、SIPエンドポイントは独自のアイデンティティを署名するのに必要な資格情報を取得する必要があります。その識別情報は通常、SIP要求のFrom Headerフィールドに搭載されており、Greenfield SIP URI（例： "SIP：alice@example.com"）または電話番号（さまざまな方法で現れることができる）のいずれかを含みます。"SIP：17004561212@example.com; user =電話"）。[RFC8224]のセクション8には、2つを分離するためのガイダンスが含まれており、それぞれの署名に必要な資格情報が必要なのかを判断します。
To date, few commercial certification authorities (CAs) issue certificates for SIP URIs or telephone numbers; though work is ongoing on systems for this purpose (such as [ACME-Auth-Token]), it is not yet mature enough to be recommended as a best practice. This is one reason why STIR permits intermediaries to act as an authentication service on behalf of an entire domain, just as in SIP a proxy server can provide domain-level SIP service. While CAs that offer proof-of-possession certificates similar to those used for email could be offered for SIP -- for either greenfield identifiers or telephone numbers -- this specification does not require their use.
今日までに、SIP URIまたは電話番号のための商業認証局（CAS）発行証明書はほとんどありません。仕事はこの目的のためにシステムに継続的に進行中ですが（ACME-AUTH-TOKEN]など）、ベストプラクティスとして推奨されるのはまだ成熟していません。これが、SIP APRES SERVER SIPサービスを提供できるのと同じように、仲介者がドメイン全体を代表する認証サービスとして機能することを可能にする理由の1つです。電子メールに使用されたものと同様の保有証明書証明書を提供するCASは、SIPのために - グリーンフィールド識別子または電話番号のいずれかのために提供されます - この仕様は彼らの使用を必要としません。
For users who do not possess such certificates, DTLS-SRTP [RFC5763] permits the use of self-signed public keys. The profile of STIR in this document, called the SIPBRANDY profile, employs the more relaxed authority requirements of [RFC8224] to allow the use of self-signed public keys for authentication services that are composed with UAs, by generating a certificate (per the guidance in [RFC8226]) with a subject corresponding to the user's identity. To obtain comprehensive protection with a self-signed certificate, some out-of-band verification is needed as well. Such a credential could be used for trust on first use (see [RFC7435]) by relying parties. Note that relying parties SHOULD NOT use certificate revocation mechanisms or real-time certificate verification systems for self-signed certificates, as they will not increase confidence in the certificate.
そのような証明書を所有していないユーザーの場合、DTLS-SRTP [RFC5763]は自己署名の公開鍵の使用を許可します。SIPBRANDYプロファイルと呼ばれるこの文書内でのかき混ぜるプロファイルは、証明書を生成することによって、UASで構成されている認証サービスのための自己署名の公開鍵の使用を可能にするために[RFC8224]のよりリラックスした権限要件を採用しています。ユーザーのアイデンティティに対応する対象となる[RFC8226]）で。自己署名証明書で包括的な保護を得るためには、一部の帯域外検証も必要です。そのような信任状は、信頼関係者によって最初の使用（RFC7435]を参照）の信頼に使用することができます。依拠当事者は、証明書の失効メカニズムまたはリアルタイムの証明書検証システムを使用しないでください。
Users who wish to remain anonymous can instead generate self-signed certificates as described in Section 4.2.
匿名を維持したいユーザーは、代わりにセクション4.2で説明されているように自己署名証明書を生成できます。
Generally speaking, without access to out-of-band information about which certificates were issued to whom, it will be very difficult for relying parties to ascertain whether or not the signer of a SIP request is genuinely an "endpoint". Even the term "endpoint" is a problematic one, as SIP UAs can be composed in a variety of architectures and may not be devices under direct user control. While it is possible that techniques based on certificate transparency [RFC6962] or similar practices could help UAs to recognize one another's certificates, those operational systems will need to ramp up with the CAs that issue credentials to end-user devices going forward.
一般的に言って、どの証明書がどの証明書に発行されたかについての帯域外の情報にアクセスすることなく、SIP要求の署名者が本当に「エンドポイント」であるかどうかを確認することは非常に困難であろう。「エンドポイント」という用語でさえも、SIP UASはさまざまなアーキテクチャで構成することができ、ダイレクトユーザーコントロールの下のデバイスではない可能性があるため、問題のあるものです。証明書の透明度[RFC6962]または同様の方法に基づくテクニックが、UASを1つの証明書を認識するのに役立つ可能性があるが、それらの運用システムは、将来のエンドユーザデバイスに資格情報を発行するCASを上昇させる必要がある。
In some cases, the identity of the initiator of a SIP session may be withheld due to user or provider policy. Following the recommendations of [RFC3323], this may involve using an identity such as "anonymous@anonymous.invalid" in the identity fields of a SIP request. [RFC8224] does not currently permit authentication services to sign for requests that supply this identity. It does, however, permit signing for valid domains, such as "anonymous@example.com", as a way of implementing an anonymization service as specified in [RFC3323].
場合によっては、SIPセッションのイニシエータのアイデンティティは、ユーザポリシーまたはプロバイダポリシーのために差し込むことがある。[RFC3323]の推奨事項に従って、これはSIP要求のIDフィールドに「anonymous @ anonymous.invalid」のような身元を使用することを含み得る。[RFC8224]現在、このIDを提供する要求に認証サービスが署名されていません。ただし、[RFC3323]で指定されているように匿名化サービスを実装する方法として、「anonymous@example.com」などの有効なドメインの署名を許可します。
Even for anonymous sessions, providing media confidentiality and partial SDP integrity is still desirable. One-time self-signed certificates for anonymous communications SHOULD include a subjectAltName of "sip:anonymous@anonymous.invalid". After a session is terminated, the certificate SHOULD be discarded, and a new one, with fresh keying material, SHOULD be generated before each future anonymous call. As with self-signed certificates, relying parties SHOULD NOT use certificate revocation mechanisms or real-time certificate verification systems for anonymous certificates, as they will not increase confidence in the certificate.
匿名のセッションでさえ、メディア機密性と部分的なSDPの完全性を提供することはまだ望ましいです。匿名通信のためのワンタイムの自己署名証明書には、「SIP：Anonymous @ anonymous.invalid」の題名名を含める必要があります。セッションが終了した後、証明書は破棄されるべきであり、新鮮なキーイングの資料を持つ新しいものは、将来の匿名の呼び出しの前に生成されるべきです。自己署名証明書と同様に、信頼者は証明書への信頼性を高めないため、匿名証明書の証明書失効メカニズムまたはリアルタイムの証明書検証システムを使用しないでください。
Note that when using one-time anonymous self-signed certificates, any man in the middle could strip the Identity header and replace it with one signed by its own one-time certificate, changing the "mky" parameters of PASSporT and any "a=fingerprint" attributes in SDP as it chooses. This signature only provides protection against non-Identity-aware entities that might modify SDP without altering the PASSporT conveyed in the Identity header.
ワンタイムの匿名の自己署名証明書を使用する場合、中央の任意の男性はIDヘッダーを削除し、それを独自の1回の証明書によって署名されたものと置き換えることができ、パスポートとA =の「MKY」パラメータを変更することができることに注意してください。選択されたSDPのフィンガープリントの属性。この署名は、IDヘッダーで伝達されているパスポートを変更せずにSDPを変更する可能性のある非ID対応のエンティティに対する保護を提供します。
STIR [RFC8224] provides integrity protection for the fingerprint attributes in SIP request bodies but not SIP responses. When a session is established, therefore, any SDP body carried by a 200-class response in the backwards direction will not be protected by an authentication service and cannot be verified. Thus, sending a secured SDP body in the backwards direction will require an extra RTT, typically a request sent in the backwards direction.
STIR [RFC8224]は、SIP要求本体の指紋属性の整合性保護を提供しますが、SIP応答はありません。したがって、セッションが確立された場合、後方方向に200クラスの応答が担うSDP本体は認証サービスによって保護されず、検証できない。したがって、保護されたSDP本体を後方方向に送信することは、典型的には後方方向に送信された要求を必要とする。
[RFC4916] explored the problem of providing "connected identity" to implementations of [RFC4474] (which is obsoleted by [RFC8224]); [RFC4916] uses a provisional or mid-dialog UPDATE request in the backwards (reverse) direction to convey an Identity header field for the recipient of an INVITE. The procedures in [RFC4916] are largely compatible with the revision of the Identity header in [RFC8224]. However, the following need to be considered:
[RFC4916] [RFC4474]の実装に「接続された識別情報」を提供するという問題を検討しました（RFC8224]によって廃止されます）。[RFC4916] INVITEの受信者のIDヘッダフィールドを逆方向（逆方向）方向に暫定的またはMID-Dialogの更新要求を使用します。[RFC4916]の手順は、[RFC8224]のIDヘッダーのリビジョンとほとんど互換性があります。ただし、以下のものを考慮する必要があります。
* The UPDATE carrying signed SDP with a fingerprint in the backwards direction needs to be sent during dialog establishment, following the receipt of a Provisional Response Acknowledgement (PRACK) after a provisional 1xx response.
* 暫定的な1xx応答の後の暫定応答確認応答（PRACK）の受信後、後方への指紋を持つSDPを搬送するアップデートSDPをダイアログ確立の間に送信する必要があります。
* For use with this SIPBRANDY profile for media confidentiality, the UAS that responds to the INVITE request needs to act as an authentication service for the UPDATE sent in the backwards direction.
* このSipbrandyプロファイルではメディア機密性のために使用するために、招待要求に応答するUASは、後方方向に送信された更新の認証サービスとして機能する必要があります。
* Per the text in Section 4.4.1 of [RFC4916] regarding the receipt at a User Agent Client (UAC) of error code 428, 436, 437, or 438 in response to a mid-dialog request, it is RECOMMENDED that the dialog be treated as terminated. However, Section 6.1.1 of [RFC8224] allows the retransmission of requests with repairable error conditions. In particular, an authentication service might retry a mid-dialog rather than treating the dialog as terminated, although only one such retry is permitted.
* [RFC4916]の[RFC4916]の[RFC4916]のテキストごとに[RFC4916]は、ダイアログ中のリクエストに応答してエラーコード428,436,437、または438のレシートについては、ダイアログがあることをお勧めします。終了したように扱われます。ただし、[RFC8224]のセクション6.1.1は、修復可能なエラー状態を持つ要求の再送信を可能にします。特に、認証サービスは、ダイアログを終了するのではなく、ダイアログ中のダイアログを再試行することができますが、そのようなリトライは1つだけです。
* Note that the examples in [RFC4916] are based on [RFC4474] and will not match signatures using [RFC8224].
* [RFC4916]の例は[RFC4474]に基づいており、[RFC8224]を使用してシグネチャと一致しません。
Future work may be done to revise [RFC4916] for STIR; that work should take into account any impacts on the SIPBRANDY profile described in this document. The use of [RFC4916] has some further interactions with Interactive Connectivity Establishment (ICE) [RFC8445]; see Section 7.
将来の作業は、かき混ぜるために[RFC4916]を改訂するために行われるかもしれません。その作業は、この文書に記載されているSipbrandyプロファイルへの影響を考慮に入れるべきです。[RFC4916]の使用は、インタラクティブ接続確立（氷）とのさらなる相互作用を持っています[RFC8445]。7を参照してください。
[RFC8224] grants STIR verification services a great deal of latitude when making authorization decisions based on the presence of the Identity header field. It is largely a matter of local policy whether an endpoint rejects a call based on the absence of an Identity header field, or even the presence of a header that fails an integrity check against the request.
[RFC8224] Identityヘッダーフィールドの存在に基づいて承認の決定を下すときに、撹拌検証サービスを大幅に寛大にしています。これは、EndpointがIDヘッダーフィールドの欠如に基づいてエンドポイントがコールを拒否しているか、または要求に対して整合性チェックに失敗したヘッダーの存在でさえも、エンドポイントがコールを拒否しているかどうかというローカルポリシーです。
For this SIPBRANDY profile of STIR, however, a compliant verification service that receives a dialog-forming SIP request containing an Identity header with a PASSporT type of "msec", after validating the request per the steps described in Section 6.2 of [RFC8224], MUST reject the request if there is any failure in that validation process with the appropriate status code per Section 6.2.2 of [RFC8224]. If the request is valid, then if a terminating user accepts the request, it MUST then follow the steps in Section 4.3 to act as an authentication service and send a signed request with the "msec" PASSporT type in its Identity header as well, in order to enable end-to-end bidirectional confidentiality.
しかしながら、このSIPBrandyプロファイルのために、[RFC8224]のセクション6.2で説明されているステップに要求を検証した後、Passportタイプの「MSEC」を含むIDヘッダを含むダイアログ形成SIP要求を受信する準拠検証サービス。[RFC8224]のセクション6.2.2のセクション6.2.2で適切なステータスコードを使用してその検証プロセスに失敗した場合は、要求を拒否する必要があります。要求が有効な場合は、終端ユーザーが要求を受け入れる場合は、セクション4.3の手順に従って認証サービスとして機能し、そのIDヘッダーで「MSEC」パスポートタイプで署名付き要求を送信する必要があります。エンドツーエンドの双方向機密性を可能にするために。
For the purposes of this profile, the "msec" PASSporT type can be used by authentication services in one of two ways: as a mandatory request for media security or as a merely opportunistic request for media security. As any verification service that receives an Identity header field in a SIP request with an unrecognized PASSporT type will simply ignore that Identity header, an authentication service will know whether or not the terminating side supports "msec" based on whether or not its UA receives a signed request in the backwards direction per Section 4.3. If no such requests are received, the UA may do one of two things: shut down the dialog, if the policy of the UA requires that "msec" be supported by the terminating side for this dialog; or, if policy permits (e.g., an explicit acceptance by the user), allow the dialog to continue without media security.
このプロファイルの目的のために、「MSEC」パスポートタイプは、2つの方法のうちの1つにおいて認証サービスによって使用され得る。メディアセキュリティに対する必須要求として、またはメディアセキュリティに対する単なる日和見的要求として。認識されていないパスポートタイプを持つSIP要求でIDヘッダーフィールドを受信するすべての検証サービスは、そのIDENTITITYヘッダーを単純に無視します。認証サービスは、そのUAが受信したかどうかに基づいて終端側が「MSEC」をサポートしているかどうかを知っています。セクション4.3あたりの後方方向に署名された要求。そのような要求が受信されない場合、UAは2つのことのうちの1つを実行することができる：このダイアログのポリシーが「MSEC」を必要とする場合は、このダイアログのための終了側でサポートされている場合は、ダイアログをシャットダウンします。あるいは、ポリシーが許可されている場合（例えば、ユーザーによる明示的な受け入れ）、ダイアログをメディアセキュリティなしで継続させることができます。
As there are several ways to negotiate media security with SDP, any of which might be used with either opportunistic or comprehensive protection, further guidance to implementers is needed. In [RFC8643], opportunistic approaches considered include DTLS-SRTP, security descriptions [RFC4568], and ZRTP [RFC6189].
SDPでメディアセキュリティを交渉する方法はいくつかありますので、日和見的または包括的な保護のいずれかで使用される可能性があるため、実装者へのさらなるガイダンスが必要です。[RFC8643]では、DTLS-SRTP、セキュリティ記述[RFC4568]、およびZRTP [RFC6189]を含む日和見的アプローチが含まれています。
Support for DTLS-SRTP is REQUIRED by this specification.
この仕様書にはDTLS-SRTPのサポートが必要です。
The "mky" claim of PASSporT provides integrity protection for "a=fingerprint" attributes in SDP, including cases where multiple "a=fingerprint" attributes appear in the same SDP.
Passportの「MKY」クレームは、SDP内の「A = FingerPrint」属性の整合性保護を提供し、複数の「A = FingerPrint」属性が同じSDPに表示される場合を含む。
Providing end-to-end media confidentiality for SIP is complicated by the presence of many forms of media relays. While many media relays merely proxy media to a destination, others present themselves as media endpoints and terminate security associations before re-originating media to its destination.
SIPのためのエンドツーエンドメディア機密性を提供することは、多くの形態のメディアリレーの存在によって複雑です。多くのメディアは単なるプロキシメディアを宛先に中継しますが、他のメディアはメディアエンドポイントとして自分自身を存在し、メディアを宛先に再発行する前にセキュリティアソシエーションを終了します。
Centralized conference bridges are one type of entity that typically terminates a media session in order to mux media from multiple sources and then to re-originate the muxed media to conference participants. In many such implementations, only hop-by-hop media confidentiality is possible. Work is ongoing to specify a means to encrypt both (1) the hop-by-hop media between a UA and a centralized server and (2) the end-to-end media between UAs, but it is not sufficiently mature at this time to become a best practice. Those protocols are expected to identify their own best-practice recommendations as they mature.
集中型カンファレンスブリッジは、通常、複数の情報源からのMUXメディアのためにメディアセッションを終了し、次に会議参加者へのマルコードメディアを再発信するためのメディアセッションを終了する1種類のエンティティです。そのような多くの実装形態では、ホップバイホップメディア機密性だけが可能である。UAと集中型サーバーとの間のホップごとのホップメディアを暗号化する手段を指定して、UAS間のエンドツーエンドメディアの両方を暗号化する手段を指定しますが、現時点では十分に成熟していません。ベストプラクティスになるために。それらのプロトコルは、彼らが成熟したときに彼ら自身のベストプラクティス勧告を識別することが期待されています。
Another class of entities that might relay SIP media are Back-to-Back User Agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879], it may be possible for B2BUAs to act as media relays while still permitting end-to-end confidentiality between UAs.
SIPメディアを中継する可能性がある他のクラスのエンティティは、バックツーバックユーザーエージェント（B2BUAS）です。B2BUAが[RFC7879]のガイダンスに従うと、B2BUASがUAS間のエンドツーエンドの機密性を可能にしながら、B2BUAがメディアリレーとして機能することが可能です。
Ultimately, if an endpoint can decrypt media it receives, then that endpoint can forward the decrypted media without the knowledge or consent of the media's originator. No media confidentiality mechanism can protect against these sorts of relayed disclosures or against a legitimate endpoint that can legitimately decrypt media and record a copy to be sent elsewhere (see [RFC7245]).
最終的に、エンドポイントが受信したメディアを復号化できる場合、そのエンドポイントはメディアの発信者の知識または同意なしに復号化されたメディアを転送できます。メディア機密保持メカニズムは、これらの種類の中継開示や合法的なエンドポイントから保護することも、メディアを正当に復号化し、他の場所に送信されるコピーを記録することができます（[RFC7245]参照）。
Providing confidentiality for media with comprehensive protection requires careful timing of when media streams should be sent and when a user interface should signify that confidentiality is in place.
包括的な保護を備えたメディアの機密性を提供するには、メディアストリームを送信する必要があるとき、およびユーザーインターフェイスが機密性が整っていることを意味する場合の慎重なタイミングが必要です。
In order to best enable end-to-end connectivity between UAs and to avoid media relays as much as possible, implementations of this specification MUST support ICE [RFC8445] [RFC8839]. To speed up call establishment, it is RECOMMENDED that implementations support Trickle ICE [RFC8838] [RFC8840].
UAS間のエンドツーエンド接続を最適にし、メディアリレーを避けるためにできるだけ最適に、この仕様の実装はICE [RFC8445] [RFC8839]をサポートしている必要があります。呼び出し確立をスピードアップするためには、実装がトリクルアイス[RFC8838] [RFC8840]をサポートすることをお勧めします。
Note that in the comprehensive protection case, the use of connected identity [RFC4916] with ICE implies that the answer containing the key fingerprints, and thus the STIR signature, will come in an UPDATE sent in the backwards direction, a provisional response, and a PRACK, rather than in any earlier SDP body. Only at such a time as that UPDATE is received will the media keys be considered exchanged in this case.
包括的な保護ケースでは、ICEを搭載した接続アイデンティティ[RFC4916]の使用は、キーフィンガープリントを含む回答、したがって撹拌シグネチャが、後方方向に送信された更新、暫定的な応答、および以前のSDPボディではなく、軽蔑します。その更新が受信されたほどの場合にのみ、メディアキーはこの場合交換されます。
Similarly, in order to prevent, or at least mitigate, the denial-of-service attack described in Section 19.5.1 of [RFC8445], this specification incorporates best practices for ensuring that recipients of media flows have consented to receive such flows. Implementations of this specification MUST implement the Session Traversal Utilities for NAT (STUN) usage for consent freshness defined in [RFC7675].
同様に、[RFC8445]のセクション19.5.1で説明されているサービス拒否攻撃を防止、または少なくとも軽減するために、この仕様は、メディアフローの受信者がそのようなフローを受信することが確実に同意したことを確実にするためのベストプラクティスを取り入れています。本明細書の実装は、[RFC7675]で定義されている同意鮮度のためのNAT（STUN）使用法のセッショントラバーサルユーティリティを実装しなければなりません。
The following are the best practices for SIP UAs to provide media confidentiality for SIP sessions.
SIPセッションのためのメディア機密性を提供するためのSIP UASのためのベストプラクティスです。
* Implementations MUST support the SIPBRANDY profile as defined in Section 4 and signal such support in PASSporT via the "msec" header element.
* 実装はセクション4で定義されているSipbrandyプロファイルをサポートし、「MSEC」ヘッダー要素を介してパスポートでそのようなサポートをシグナルにする必要があります。
* Implementations MUST follow the authorization decision behavior described in Section 4.4.
* 実装は、セクション4.4で説明されている承認判決の行動に従う必要があります。
* Implementations MUST support DTLS-SRTP for management of keys, as described in Section 5.
* セクション5で説明されているように、実装はキーの管理のためにDTLS-SRTPをサポートしなければなりません。
* Implementations MUST support ICE and the STUN consent freshness mechanism, as specified in Section 7.
* セクション7で指定されているように、実装はICEとSTUNの同意の鮮度メカニズムをサポートしなければなりません。
This specification defines a new value for the "Personal Assertion Token (PASSporT) Extensions" registry called "msec". IANA has added the entry to the registry with a value pointing to this document.
この仕様では、「Personal Assertion Token（Passport）拡張子」という新しい値が「MSEC」と呼ばれるレジストリを定義しています。IANAはこの文書を指す値を使用してレジストリへのエントリを追加しました。
This document describes the security features that provide media sessions established with SIP with confidentiality, integrity, and authentication.
このドキュメントでは、SIPで確立されたメディアセッションを機密性、整合性、および認証に提供するセキュリティ機能について説明します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3261] 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, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https：//ww.rfc-editor.org/ info / rfc3264>。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, <https://www.rfc-editor.org/info/rfc3323>.
[RFC3323] Peterson、J.、「セッション開始プロトコルのプライバシーメカニズム（SIP）」、RFC 3323、DOI 10.17487 / RFC3323、2002年11月、<https：//www.rfc-editor.org/info/rfc3323>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、「RTP：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E.、K.Norrman、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004年、<https：//www.rfc-editor.org/info/rfc3711>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566]ハンドリー、M.、Jacobson、V.、およびC.Perkins、「SDP：セッション記述プロトコル」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https：//www.rfc-editor.org/情報/ RFC4566>。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, <https://www.rfc-editor.org/info/rfc4568>.
[RFC4568] Andreasen、F.、Baugher、M.、D. Wing、Media Streamsの「セッション記述プロトコル（SDP）セキュリティ説明」、RFC 4568、DOI 10.17487 / RFC4568、2006年7月、<https：// www。rfc-editor.org/info/rfc4568>。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 2007, <https://www.rfc-editor.org/info/rfc4916>.
[RFC4916] Elwell、J.、「セッション開始プロトコル（SIP）」、RFC 4916、DOI 10.17487 / RFC4916、2007年6月、<https：//www.rfc-editor.org/info/rfc4916>。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC5763] FISCHL、J.、TSCHOFENIG、H.、およびE.RESCORLA、「データグラムトランスポート層セキュリティ（DTLS）」、RFC 5763、DOI 10.17487 /を使用したセキュリティコンテキスト（SRTP）セキュリティコンテキストを確立するためのフレームワーク。2010年5月、<https://www.rfc-editor.org/info/rfc5763>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S.およびH.Tschofenig、「Pervasive Monitoringは攻撃」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<https：//www.rfc-editor.org/info/rfc7258>。
[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, October 2015, <https://www.rfc-editor.org/info/rfc7675>.
[RFC7675]概要、M.、Wing、D.、Ravindranath、R.、Redddy、T.、およびM.Thomson、「セッショントラバーサル・ユーティリティ・コンセント・フリーネスのためのセッショントラバーサル・ユーティリティ」、RFC 7675、DOI 10.17487 / RFC76752015年10月、<https://www.rfc-editor.org/info/rfc7675>。
[RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, <https://www.rfc-editor.org/info/rfc7879>.
[RFC7879] Ravindranath、R.、Reddy、T.、Salgueiro、G.、Pascal、V.、およびP. Ravindran、「SIPバックツーバックユーザーエージェントのDTLS-SRTP処理」、RFC 7879、DOI 10.17487 /2016年5月、<https://www.rfc-editor.org/info/rfc7879>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, <https://www.rfc-editor.org/info/rfc8224>.
[RFC8224] Peterson、J.、Jennings、C、Rescorla、E.、およびC.Wendt、「セッション開始プロトコル（SIP）」、RFC 8224、DOI 10.17487 / RFC8224、2018年2月、<HTTPS）//www.rfc-editor.org/info/rfc8224>。
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, <https://www.rfc-editor.org/info/rfc8225>.
[RFC8225] Wendt、C.およびJ.Peterson、 "Passport：Personal Assertion Token"、RFC 8225、DOI 10.17487 / RFC8225、2018年2月、<https：//www.rfc-editor.org/info/rfc8225>。
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, <https://www.rfc-editor.org/info/rfc8226>.
[RFC8226] Peterson、J.およびS. Turner、「Secure Phereth Identity Credentials：証明書」、RFC 8226、DOI 10.17487 / RFC8226、2018年2月、<https：//www.rfc-editor.org/info/rfc8226>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445]ケラネン、A.、Holmberg、C.、J.Rosenberg、「インタラクティブ接続施設（氷）：ネットワークアドレス翻訳者のためのプロトコル」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", RFC 8838, DOI 10.17487/RFC8838, January 2021, <https://www.rfc-editor.org/info/rfc8838>.
[RFC8838] IVOV、E.、Uberti、J.、およびP.Saint-Andre、「トリクルアイス：インタラクティブ接続確立の候補（ICE）プロトコルの候補の増分プロビジョニング」、RFC 8838、DOI 10.17487 / RFC8838、2021年1月、<https://www.rfc-editor.org/info/rfc8838>。
[RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, A., and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, January 2021, <https://www.rfc-editor.org/info/rfc8839>.
[RFC8839] Petit-Huguenin、M.、Nandakumar、S.、Holmberg、C.、Keränen、A.、R. Shpount、「セッション説明プロトコル（SDP）オファー/回答手順インタラクティブ接続確立（ICE）」RFC 8839、DOI 10.17487 / RFC8839、2021年1月、<https：//www.rfc-editor.org/info/rfc8839>。
[RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)", RFC 8840, DOI 10.17487/RFC8840, January 2021, <https://www.rfc-editor.org/info/rfc8840>.
[RFC8840] IVOV、E.、STACH、T.、Marocco、E.、およびC.Holmberg、「インタラクティブ接続確立の候補者の増分プロビジョニングのためのセッション開始プロトコル（SIP）使用法」、RFC 8840、DOI 10.17487 / RFC8840、2021年1月、<https：//www.rfc-editor.org/info/rfc8840>。
[ACME-Auth-Token] Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME Challenges Using an Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-05, 9 March 2020, <https://tools.ietf.org/html/draft-ietf-acme-authority-token-05>.
[acme-auth-token] Peterson、J.、Barnes、M.、Hancock、D.、およびC. Wendt、「Acme Challengesは、権限トークンを使用している課題」、進行中の作業、インターネットドラフト、ドラフト-IETF-acme-<https://tools.ietf.org/html/draft-ietf-acme-authority-token-05>。
[Best-Effort-SRTP] Kaplan, H. and F. Audet, "Session Description Protocol (SDP) Offer/Answer Negotiation For Best-Effort Secure Real-Time Transport Protocol", Work in Progress, Internet-Draft, draft-kaplan-mmusic-best-effort-srtp-01, 25 October 2006, <https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01>.
[ベストエフォートSRTP] Kaplan、H.およびF. Audet、「セッション記述プロトコル（SDP）提供安全リアルタイムトランスポートプロトコルのためのオファー/回答交渉」、進行中の作業、インターネットドラフト、ドラフトカプラン-Mmusic-Best-Froms-SRTP-01,2006、<https：//tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01>
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, <https://www.rfc-editor.org/info/rfc4474>.
[RFC4474] Peterson、J.およびC. Jennings、「セッション開始プロトコル（SIP）」、RFC 4474、DOI 10.17487 / RFC4474、<https：//www.rfc-編集者における「認証済みアイデンティティ管理の強化」。ORG / INFO / RFC4474>。
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, DOI 10.17487/RFC6189, April 2011, <https://www.rfc-editor.org/info/rfc6189>.
[RFC6189] Zimmermann、P.、Johnston、A.、ED。、およびJ.Callas、 "Zrtp：ユニキャストセキュアRTPのメディアパスキー契約RFC 6189、DOI 10.17487 / RFC6189、2011年4月、<https：//www.rfc-editor.org/info/rfc6189>。
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.
[RFC6962] Laurie、B.、Langley、A。、およびE. Kasper、「証明書透明度」、RFC 6962、DOI 10.17487 / RFC6962、2013年6月、<https：//www.rfc-editor.org/info/rfc6962>。
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, "An Architecture for Media Recording Using the Session Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 2014, <https://www.rfc-editor.org/info/rfc7245>.
[RFC7245] Hutton、A.、ED。、Portman、L.、Ed。、Jain、R.、およびK. Rehor、「セッション開始プロトコルを使用したメディア録画のアーキテクチャ」、RFC 7245、DOI 10.17487 / RFC7245、2014年5月、<https：//www.rfc-editor.org/info/rfc7245>。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V.、「日和見主義的セキュリティ：ほとんどの保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<https：//www.rfc-editor.org/info/rfc7435>。
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>.
[RFC7616] Shekh-Yusef、R.、Ed。、Ahrens、D.、およびS.ブレーマー、「HTTPダイジェスト認証」、RFC 7616、DOI 10.17487 / RFC7616、2015年9月、<https：//www.rfc-editor.org/info/rfc7616>。
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8551] Schaad、J.、Ramsdell、B.、およびS。ターナー、「セキュア/多目的インターネットメール拡張（S / MIME /多目的インターネットメール拡張」、RFC 8551、DOI 10.17487 / RFC8551、2019年4月、<https：//www.rfc-editor.org/info/rfc8551>。
[RFC8643] Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T. Stach, "An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)", RFC 8643, DOI 10.17487/RFC8643, August 2019, <https://www.rfc-editor.org/info/rfc8643>.
[RFC8643] Johnston、A.、Aboba、B.、Hutton、A.、Jesske、R.、T. Stach、「安全なリアルタイムトランスポートプロトコルのための日和見的アプローチ（OSRTP）」、RFC 8643、DOI 10.17487 /RFC8643、2019年8月、<https://www.rfc-editor.org/info/rfc8643>。
Acknowledgements
謝辞
We thank Eric Rescorla, Adam Roach, Andrew Hutton, and Ben Campbell for contributions to this problem statement and framework. We thank Liang Xia and Alissa Cooper for their careful review.
私たちは、この問題の声明とフレームワークへの貢献について、Eric Rescorla、Adam Roach、Andrew Hutton、Ben Campbellに感謝します。私たちは慎重なレビューのためにLiang XiaとAlissa Cooperに感謝します。
Authors' Addresses
著者の住所
Jon Peterson Neustar, Inc.
Jon Peterson Neustar、Inc。
Email: jon.peterson@team.neustar
Richard Barnes Cisco
リチャードバーンズシスコ
Email: rlb@ipv.sx
Russ Housley Vigil Security, LLC
Russ Housley Vigil Security、LLC
Email: housley@vigilsec.com