[要約] RFC 6043は、マルチメディアインターネットキーイング（MIKEY）におけるチケットベースの鍵配布モードについての要約です。このRFCの目的は、MIKEYプロトコルでの鍵配布の効率性とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) J. Mattsson
Request for Comments: 6043 Ericsson
Category: Informational T. Tian
ISSN: 2070-1721 ZTE
March 2011
MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
Mikey-Ticket：マルチメディアインターネットキーイング（Mikey）におけるキーディストリビューションのチケットベースのモード
Abstract
概要
The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing. Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session.
マルチメディアインターネットキーイング（Mikey）仕様は、リアルタイムアプリケーションの重要な管理スキームについて説明しています。このドキュメントでは、現在定義されているマイキーモードは、集中化されたキー管理サービスを中心に構築された展開シナリオに対処するには不十分であることに注意してください。このような展開への関心は増加しています。したがって、このようなシナリオでうまく機能する新しいマイキーモードのセットが定義されています。新しいモードでは、信頼できるキー管理サービスと、Kerberosと同様のチケットコンセプトを使用しています。新しいモードは、多くの既存のアプリケーションで使用される機能もサポートしています。他のエンドポイントの正確なアイデンティティは、通信セッションの開始時に知られていない場合があります。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション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/rfc6043.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6043で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................4
2.1. Definitions and Notation ...................................5
2.2. Abbreviations ..............................................6
2.3. Payloads ...................................................6
3. Design Considerations ...........................................7
4. MIKEY-TICKET ....................................................9
4.1. Overview ...................................................9
4.1.1. Modes ..............................................12
4.2. Exchanges .................................................13
4.2.1. Ticket Request .....................................13
4.2.2. Ticket Transfer ....................................16
4.2.3. Ticket Resolve .....................................19
5. Key Management Functions .......................................23
5.1. Key Derivation ............................................23
5.1.1. Deriving Forked Keys ...............................25
5.1.2. Deriving Keys from an Envelope Key/PSK/MPK .........26
5.1.3. Deriving Keys from a TGK/GTGK ......................27
5.2. CSB Updating ..............................................28
5.3. Ticket Reuse ..............................................29
5.4. Error Handling ............................................29
5.5. MAC/Signature Coverage ....................................30
6. Payload Encoding ...............................................31
6.1. Common Header Payload (HDR) ...............................31
6.1.1. The GENERIC-ID Map Type ............................33
6.2. Key Data Transport Payload (KEMAC) ........................34
6.2.1. Key Data Sub-Payload ...............................35
6.3. Timestamp Payload (T) .....................................36
6.4. Timestamp Payload with Role Indicator (TR) ................36
6.5. ID Payload (ID) ...........................................37
6.6. ID Payload with Role Indicator (IDR) ......................37
6.7. Cert Hash Payload (CHASH) .................................38
6.8. RAND Payload with Role Indicator (RANDR) ..................38
6.9. Error Payload (ERR) .......................................39
6.10. Ticket Policy Payload (TP) / Ticket Payload (TICKET) .....39
7. Transport Protocols ............................................43
8. Pre-Encrypted Content ..........................................43
9. Group Communication ............................................44
9.1. Key Forking ...............................................45
10. Signaling between Different KMSs ..............................45
11. Adding New Ticket Types to MIKEY-TICKET .......................46
12. Security Considerations .......................................47
12.1. General ..................................................47
12.2. Key Forking ..............................................48
12.3. Denial of Service ........................................49
12.4. Replay ...................................................49
12.5. Group Key Management .....................................50
13. Acknowledgements ..............................................50
14. IANA Considerations ...........................................50
15. References ....................................................53
15.1. Normative References .....................................53
15.2. Informative References ...................................53
Appendix A. MIKEY Base Ticket ....................................55
A.1. Components of the Ticket Data .............................55
A.2. Key Derivation ............................................56
A.2.1. Deriving Keys from a TPK ..............................56
A.2.2. Deriving MPKi and MPKr ................................57
A.3. Ticket Header Payload (THDR) ..............................57
Appendix B. Alternative Use Cases ................................58
B.1. Compatibility Mode ........................................58
Key management systems are either based on negotiation and exchange directly between peers (e.g., Diffie-Hellman-based schemes), pre-distribution of user credentials (shared secrets/certificates), or availability of a trusted Key Management Service (KMS). The modes described in the Multimedia Internet KEYing (MIKEY) specification [RFC3830] and its extensions [RFC4650] [RFC4738] are all variants of the first two alternatives.
主要な管理システムは、交渉と交換に基づいて、ピア間の直接交換（例：Diffie-Hellmanベースのスキーム）、ユーザー資格情報の事前分配（共有秘密/証明書）、または信頼できるキー管理サービス（KMS）の可用性のいずれかです。マルチメディアインターネットキーイング（Mikey）仕様[RFC3830]とその拡張[RFC4650] [RFC4738]で説明されているモードは、すべて最初の2つの代替品のバリアントです。
In security systems serving a large number of users, a solution based on a key management service is often preferred. With such a service in place, there is no need to pre-distribute credentials that directly can be used to establish security associations between peers for protected communication, as users can request such credentials when needed. Solutions based on a trusted key management service also scale well when the number of users grows.
多数のユーザーにサービスを提供するセキュリティシステムでは、主要な管理サービスに基づくソリューションが望まれます。このようなサービスが導入されている場合、ユーザーは必要に応じてそのような資格情報を要求できるため、保護されたコミュニケーションのためにピア間のセキュリティ関連を確立するために直接使用できる資格情報を事前に分配する必要はありません。信頼できるキー管理サービスに基づくソリューションは、ユーザーの数が増えたときにも十分にスケーリングします。
This document introduces a set of new MIKEY modes that go under the common name MIKEY-TICKET. The new modes support a ticket concept, similar to that in Kerberos [RFC4120], which is used to identify and deliver keys. A high-level outline of MIKEY-TICKET as defined herein is that the Initiator requests keys and a ticket from the KMS and sends the ticket to the Responder. The ticket contains a reference to the keys, or the enveloped keys. The Responder then sends the ticket to the KMS, which returns the appropriate keys.
このドキュメントでは、Mikey-Ticketの共通名で行く新しいMikeyモードのセットを紹介します。新しいモードは、キーを識別および配信するために使用されるKerberos [RFC4120]と同様のチケットの概念をサポートしています。ここで定義されているマイキーチケットのハイレベルの概要は、イニシエーターがKMSからキーとチケットを要求し、チケットをレスポンダーに送信することです。チケットには、キーへの参照、または包まれたキーが含まれています。その後、レスポンダーはKMSにチケットを送信し、適切なキーを返します。
MIKEY-TICKET is primarily designed to be used for media plane security in the 3rd Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS) [3GPP.33.328]. This implies that some extensions to the basic Kerberos concept are needed. For instance, the Initiator may not always know the exact identity of the Responder when the communication with the key management server is initiated.
Mikey-Ticketは、主に第3世代パートナーシッププロジェクト（3GPP）IPマルチメディアサブシステム（IMS）[3GPP.33.328]でメディア飛行機のセキュリティに使用されるように設計されています。これは、基本的なKerberosコンセプトへのいくつかの拡張が必要であることを意味します。たとえば、イニシエーターは、キー管理サーバーとの通信が開始されたときに、レスポンダーの正確なアイデンティティを常に知っているとは限りません。
This document defines a signaling framework enabling peers to request, transfer, and resolve various Ticket Types using a key management service. A default Ticket Type is also defined. To allow the use of 256-bit keys for users with high security requirements, additional encryption, authentication, and pseudorandom functions are defined. And to eliminate the limitations with the existing SRTP-ID map type, a new CS ID map type called GENERIC-ID is defined.
このドキュメントでは、ピアがキー管理サービスを使用してさまざまなチケットタイプを要求、転送、解決できるシグナリングフレームワークを定義します。デフォルトのチケットタイプも定義されています。セキュリティ要件が高いユーザーに256ビットキーを使用できるようにするには、追加の暗号化、認証、および擬似ランダム関数が定義されています。既存のSRTP-IDマップタイプで制限を排除するために、Generic-IDと呼ばれる新しいCS IDマップタイプが定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Definitions of terms and notation will, unless otherwise stated, be as defined in [RFC3830].
用語と表記の定義は、特に明記しない限り、[RFC3830]で定義されます。
Forking: The delivery of a request to multiple endpoints (multiple devices owned by a single user or multiple users).
フォーキング：複数のエンドポイントへのリクエストの配信（単一のユーザーまたは複数のユーザーが所有する複数のデバイス）。
Key forking: When used in conjunction with forking, key forking refers to the process of modifying keys, making them cryptographically unique for each responder targeted by the forking.
キーフォーキング：フォーキングと組み合わせて使用する場合、キーフォーキングとは、キーを変更するプロセスを指し、フォーキングが標的とする各レスポンダーに対して暗号化にユニークにすることです。
(Media) session: The communication session intended to be secured by the MIKEY-TICKET provided key(s).
（メディア）セッション：Mikey-Ticketが提供するキーによって保護されることを目的とした通信セッション。
Session information: Information related to the security protocols used to protect the media session: keys, salts, algorithms, etc.
セッション情報：メディアセッションの保護に使用されるセキュリティプロトコルに関連する情報：キー、塩、アルゴリズムなど。
Ticket: A Kerberos-like object used to identify and deliver keys over an untrusted network.
チケット：信頼されていないネットワーク上でキーを識別および配信するために使用されるKerberosのようなオブジェクト。
Ticket Data: Ticket part with information intended only for the party that resolves the ticket (e.g., keys).
チケットデータ：チケット部品は、チケットを解決するパーティー（キーなど）のみを対象とした情報を使用します。
Ticket Request: Exchange used by the Initiator to request keys and a ticket from a trusted KMS.
チケットリクエスト：イニシエーターがキーと信頼できるKMSからチケットを要求するために使用される交換。
Ticket Transfer: Exchange used to transfer the ticket as well as session information from the Initiator to the Responder.
チケットの転送：チケットの転送に使用される交換と、イニシエーターからレスポンダーへのセッション情報。
Ticket Resolve: Exchange used by the Responder to request the KMS to return the keys encoded in a ticket.
チケットの解決：レスポンダーが使用する交換は、KMSにチケットにエンコードされたキーを返すように要求します。
Ticket Policy: Policy for ticket generation and resolution, authorized applications, key derivation, etc.
チケットポリシー：チケットの生成と解決、認定申請、キー派生などのポリシー。
Ticket Type: Defines ticket format and processing. May further have subtype and version.
チケットの種類：チケットの形式と処理を定義します。さらにサブタイプとバージョンがある場合があります。
Solid arrows (----->) indicate mandatory messages.
Dashed arrows (- - ->) indicate optional messages.
E(k, p) Encryption of p with the key k PKx Public Key of entity x k' The forked key k [p] p is optional {p} Zero or more occurrences of p (p) One or more occurrences of p
E（K、P）キーK PKXのエンティティX K 'のpkx PKX公開キーによるPの暗号化キーK [P] Pはオプション{P}ゼロゼロゼロ（P）P（P）Pの1つ以上の発生の発生以上です。
|| Concatenation | OR (selection operator)
||連結|または（選択オペレーター）
3GPP: 3rd Generation Partnership Project AAA: Authentication, Authorization, and Accounting ACL: Access Control List AES: Advanced Encryption Standard CA: Certification Authority CS: Crypto Session CSB: Crypto Session Bundle IMS: IP Multimedia Subsystem GTGK: Group TGK HMAC: Hash-based Message Authentication Code KMS: Key Management Service MAC: Message Authentication Code MIKEY: Multimedia Internet KEYing NSPS: National Security and Public Safety MKI: Master Key Identifier MPK: MIKEY Protection Key NTP: Network Time Protocol PET: Privacy Enhancing Technologies PK: Public Key PRF: Pseudorandom Function PRNG: Pseudorandom Number Generator PSK: Pre-Shared Key RTSP: Real Time Streaming Protocol SDP: Session Description Protocol SHA: Secure Hash Algorithm SIP: Session Initiation Protocol SPI: Security Parameters Index SRTP: Secure Realtime Transport Protocol TEK: Traffic Encryption Key TGK: TEK Generation Key TPK: Ticket Protection Key UTC: Coordinated Universal Time
3GPP：第3世代パートナーシッププロジェクトAAA：認証、承認、および会計ACL：アクセス制御リストAES：高度な暗号化標準CA：認定機関CS：暗号セッションCSB：IPマルチメディアサブシステムGTGK：グループTGK HMAC：HASH- HASH-ベースのメッセージ認証コードKMS：キー管理サービスMAC：メッセージ認証コードマイキー：マルチメディアインターネットキーイングNSP：国家安全保障と公共安全MKI：マスターキー識別子MPK：マイキー保護キーNTP：ネットワークタイムプロトコルPET：プライバシー強化テクノロジーPK：公開キーPRF：擬似ランダム関数PRNG：擬似ランダム番号ジェネレーターPSK：事前共有キーRTSP：リアルタイムストリーミングプロトコルSDP：セッション説明プロトコルSHA：セキュアハッシュアルゴリズムSIP：セッション開始プロトコルSPI：セキュリティパラメーターインデックスSRTP：セキュアリアルタイムトランスポートプロトコルTEK：交通量暗号化キーTGK：Tek Generation Key TPK：チケット保護キーUTC：調整されたユニバーサル時間
CERTx: Certificate of entity x
CHASH: Hash of the certificate used
HDR: Common Header payload
ID: Identity payload
IDRx: Identifier for entity x
IDRpsk: Identifier for pre-shared key
IDRapp: Identifier for application/service
KEMAC: Key data transport payload
PKE: Encrypted envelope key
RAND: RAND payload
RANDRx: Random value generated by entity x
SIGNx: Signature created using entity x's private key
SP: Security Policy payload
T: Timestamp payload
TRy: Timestamp payload with role indicator y
THDR: Ticket Header payload
TICKET: Ticket payload
TP: Ticket Policy payload
V: Verification payload
where x is in the set {i, r, kms} (Initiator, Responder, KMS) and y is in the set {i, s, e, r} (time of Issue, Start time, End time, Rekeying interval).
ここで、xはセット{i、r、kms}（イニシエーター、レスポンダー、kms）にあり、yはset {i、s、e、r}（問題の時間、開始時間、終了時間、再キーイングの間隔）にあります。
The IDR, RANDR, TR, TICKET, and TP payloads are defined in Section 6. Note that in [RFC3830], there is defined both a V payload (carrying the authentication tag) and a V flag in the HDR payload (indicating whether or not a response message is expected).
IDR、RANDR、TR、チケット、およびTPペイロードはセクション6で定義されています。[RFC3830]には、HDRペイロードのVペイロード（認証タグを運ぶ）とVフラグの両方が定義されていることに注意してください。応答メッセージは予想されていません）。
As mentioned in the introduction, none of the previously defined MIKEY modes are based on a KMS. The pre-shared key method and the public-key encryption method defined in [RFC3830] are examples of systems based on pre-distribution of user credentials. The Diffie-Hellman method [RFC3830] is an example of a system based on negotiation and exchange directly between peers.
導入部で述べたように、以前に定義されたMikeyモードはどれもKMSに基づいていません。[RFC3830]で定義されている事前共有キーメソッドとパブリックキー暗号化方法は、ユーザー資格情報の事前分配に基づくシステムの例です。Diffie-Hellmanメソッド[RFC3830]は、交渉とピア間の直接交換に基づくシステムの例です。
In some situations, a request may be delivered to multiple endpoints. The endpoints may be multiple devices owned by a single user (e.g., mobile phone, fixed phone, and computer), or multiple users (e.g., IT-support@example.com, a group of users where only one is supposed to answer). In the following, the term "forking" will be used to describe all such cases. One example of delivery to multiple endpoints is forking and retargeting in SIP [RFC3261]. To prevent any form of eavesdropping, only the endpoint that answers should get access to the session keys. The naive application of [RFC3830] where all endpoints share the same pre-shared/private key is not secure when it comes to forking, as all endpoints get access to the session keys. Conversely, having per-user unique pre-shared keys/ certificates creates more fundamental problems with forking, as the initiator does not know which pre-shared key/certificate to use at session initiation. SIP-signaled media protection is described in [RFC5479] and the applicability of different MIKEY modes is discussed in [RFC5197].
状況によっては、複数のエンドポイントにリクエストが配信される場合があります。エンドポイントは、単一のユーザー（携帯電話、固定電話、コンピューターなど）が所有する複数のデバイス、または複数のユーザー（itsupport@example.com、1つだけが回答することになっているユーザーのグループ）が所有する複数のデバイスである場合があります。。以下では、「フォーキング」という用語を使用して、そのようなすべてのケースを記述します。複数のエンドポイントへの配信の1つの例は、SIP [RFC3261]でのフォーキングとリターゲティングです。あらゆる形態の盗聴を防ぐために、回答するエンドポイントのみがセッションキーにアクセスする必要があります。すべてのエンドポイントを共有する[RFC3830]の素朴なアプリケーションは、すべてのエンドポイントがセッションキーにアクセスできるため、フォーキングに関しては同じもの/秘密キーを共有します。逆に、ユーザーごとのユニークな事前共有キー/証明書を持つことは、セッション開始時に使用する事前共有キー/証明書をイニシエーターが知らないため、フォーキングにより多くの根本的な問題を作成します。SIPシグナルメディア保護は[RFC5479]で説明されており、さまざまなマイキーモードの適用性について[RFC5197]で説明しています。
In security systems serving a large number of users, a solution based on a key management service is often preferred. With such a service in place, there is no need to pre-distribute credentials that directly can be used to establish security associations between peers for protected communication, as users can request such credentials when needed. In many applications, e.g., National Security and Public Safety (NSPS), the controlling organization wants to enforce policies on the use of keys. A trusted KMS fits these applications well, as it makes it easier to enforce policies centrally. Solutions based on a trusted KMS also scale well when the number of users grows. A KMS based on symmetric keys has particular advantages, as symmetric key algorithms are generally much less computationally intensive than asymmetric key algorithms.
多数のユーザーにサービスを提供するセキュリティシステムでは、主要な管理サービスに基づくソリューションが望まれます。このようなサービスが導入されている場合、ユーザーは必要に応じてそのような資格情報を要求できるため、保護されたコミュニケーションのためにピア間のセキュリティ関連を確立するために直接使用できる資格情報を事前に分配する必要はありません。多くのアプリケーション、例えば、国家安全保障と公共安全（NSP）では、管理組織はキーの使用に関するポリシーを実施したいと考えています。信頼できるKMSは、これらのアプリケーションによく適合します。これにより、ポリシーを中央に実施しやすくなります。信頼できるKMSに基づいたソリューションは、ユーザーの数が増えるとよくスケーリングします。対称キーアルゴリズムは一般に非対称キーアルゴリズムよりもはるかに計算的に集中的ではないため、対称キーに基づくKMSには特に利点があります。
Systems based on a KMS require a signaling mechanism that allows peers to retrieve other peers' credentials. A convenient way to implement such a signaling scheme is to use a ticket concept, similar to that in Kerberos [RFC4120] to identify and deliver keys. The ticket can be forwarded in the signaling associated with the session setup. The initiator requests a ticket from the KMS and sends the ticket to the responder. The responder forwards the ticket to the KMS, which returns the corresponding keys.
KMSに基づくシステムには、ピアが他のピアの資格情報を取得できるようにするシグナリングメカニズムが必要です。このようなシグナル伝達スキームを実装する便利な方法は、Kerberos [RFC4120]と同様に、チケットの概念を使用してキーを識別および配信することです。チケットは、セッションのセットアップに関連する信号で転送できます。イニシエーターはKMSからチケットを要求し、チケットをレスポンダーに送信します。レスポンダーはチケットをKMSに転送し、対応するキーを返します。
It should be noted that Kerberos does not require that the responder also contact the KMS. However, in order to support also the aforementioned forking scenarios, it becomes necessary that the ticket is not bound to the exact identity (or credentials) of the responder until the final responder becomes fully determined. Group and forking communication scenarios can also be improved from access control point of view if authorization to access the keys can be enforced with higher granularity at the responder side. The mechanism specified in this document is useful for any system where the initial message may be transferred to arbitrarily many potential responders and where the set of responders may change at any time. In addition to being able to meet the requirements just described, the mechanism specified in this document also supports group key management.
Kerberosは、ResponderがKMSにも接触する必要がないことに注意する必要があります。ただし、前述のフォーキングシナリオもサポートするために、最終レスポンダーが完全に決定されるまで、チケットがレスポンダーの正確なアイデンティティ（または資格情報）にバインドされないことが必要になります。グループとフォーキングのコミュニケーションシナリオは、アクセス制御の観点から改善することもできます。キーへのアクセスの許可を、レスポンダー側でより高い粒度で実施できます。このドキュメントで指定されたメカニズムは、最初のメッセージが多くの潜在的な応答者に任意に転送される可能性があり、レスポンダーのセットがいつでも変更される可能性があるシステムに役立ちます。このドキュメントで指定されているメカニズムは、今説明した要件を満たすことができることに加えて、グループキー管理もサポートしています。
The ticket can contain a reference to keys held by the key management system or it can hold the keys itself. In the latter case, the ticket needs to be confidentiality and integrity protected (enveloped). In the following, the term "encoded keys" will be used to describe both cases as well as keys derived from such keys.
チケットには、キー管理システムが保持するキーへの参照を含めることができます。または、キー自体を保持できます。後者の場合、チケットは機密性と整合性の保護（包括された）である必要があります。以下では、「エンコードされたキー」という用語を使用して、両方のケースとそのようなキーから派生したキーを記述します。
By using different Ticket Types and ticket policies, some allowing the initiator or responder to create or resolve the tickets without assistance from the KMS, a wide range of different security levels and use cases can be supported. This has a number of advantages, as it offers a framework that is flexible enough to satisfy users with a broad range of security and functional needs.
さまざまなチケットタイプとチケットポリシーを使用することにより、イニシエーターまたはレスポンダーがKMSの支援なしにチケットを作成または解決できるようにすることにより、さまざまなセキュリティレベルとユースケースをサポートできます。これには、幅広いセキュリティと機能のニーズを持つユーザーを満足させるほど柔軟なフレームワークを提供するため、多くの利点があります。
The use of a ticket-based system may also help in the handling of keys for deferred delivery of end-to-end protected content to currently offline users. Such scenarios exclude all key management schemes that are based on some type of direct online negotiation between peers (e.g., Diffie-Hellman-based schemes) as the responder cannot rely on contacting the initiator to get access to keys.
チケットベースのシステムの使用は、現在オフラインユーザーにエンドツーエンドの保護コンテンツを延期するためのキーの処理にも役立ちます。このようなシナリオは、Responderがキーにアクセスするためにイニシエーターに連絡することに頼ることができないため、ピア間の何らかのタイプの直接的なオンライン交渉（Diffie-Hellmanベースのスキームなど）に基づいたすべての主要な管理スキームを除外します。
At the same time, it is also important to be aware that (centralized) key management services may introduce a single point of (security) failure. The security requirements on the implementation and protection of the KMS may therefore, in high-security applications, be more or less equivalent to the requirements of an AAA (Authentication, Authorization, and Accounting) server or a Certification Authority (CA).
同時に、（集中化された）主要な管理サービスが（セキュリティ）障害の単一のポイントを導入する可能性があることに注意することも重要です。したがって、KMSの実装と保護に関するセキュリティ要件は、高セキュリティアプリケーションでは、AAA（認証、承認、および会計）サーバーまたは認証機関（CA）の要件に多かれ少なかれ同等になる可能性があります。
All previously defined MIKEY modes consist of a single (or half) round trip between two peers. MIKEY-TICKET differs from these modes as it consists of up to three different round trips (Ticket Request, Ticket Transfer, and Ticket Resolve) involving three parties (Initiator, Responder, and KMS). Since the number of round trips and order of messages may vary, MIKEY-TICKET is actually the common name for a set of modes, all revolving around a ticket concept. The third party, the KMS, is only involved in some of the MIKEY exchanges and not at all in the resulting secure media session. The Ticket Request and Ticket Resolve exchanges are meant to be used in combination with the Ticket Transfer exchange and not on their own. In Figure 1, the signaling for the full three round-trip MIKEY-TICKET mode is depicted.
以前に定義されていたすべてのMikeyモードは、2人のピア間の単一の（または半分の）往復で構成されています。Mikey-Ticketは、3つのパーティー（イニシエーター、レスポンダー、KMS）を含む最大3つの異なるラウンドトリップ（チケットリクエスト、チケット転送、チケットの解決）で構成されているため、これらのモードとは異なります。往復の数とメッセージの順序は異なる場合があるため、マイキーチケットは実際にはモードのセットの一般名であり、すべてチケットの概念を中心に回転しています。サードパーティのKMSは、マイキーの交換の一部にのみ関与しており、結果として生じる安全なメディアセッションではまったくありません。チケットリクエストとチケットの解決交換は、独自ではなく、チケット移籍の交換と組み合わせて使用することを目的としています。図1では、3つの往復マイキーチケットモードの完全なシグナリングを示しています。
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
REQUEST_INIT
-------------------------------->
REQUEST_RESP
<--------------------------------
TRANSFER_INIT
---------------------------------------------------------------->
RESOLVE_INIT
<--------------------------------
RESOLVE_RESP
-------------------------------->
TRANSFER_RESP
<----------------------------------------------------------------
Figure 1: Full three round-trip signaling
図1：完全な3つの往復シグナル伝達
The Initiator (I) wants to establish a secure media session with the Responder (R). The Initiator and the Responder do not share any credentials; instead, they trust a third party, the KMS, with which they both have or can establish shared credentials. These pre-established trust relations are used to establish a security association between I and R. The assumed trust model is illustrated in Figure 2.
イニシエーター（i）は、レスポンダー（R）との安全なメディアセッションを確立したいと考えています。イニシエーターとレスポンダーは資格情報を共有しません。代わりに、彼らは第三者であるKMを信頼しており、彼らは共有された資格情報を確立するか、または確立することができます。これらの事前に確立された信頼関係は、IとRの間のセキュリティ関連を確立するために使用されます。想定される信頼モデルを図2に示します。
Pre-established trust relation Pre-established trust relation
<------------------------------> <------------------------------>
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
<--------------------------------------------------------------->
Security association based on ticket
Figure 2: Trust model
図2：信頼モデル
Note that rather than a single KMS, multiple KMSs may be involved, e.g., one for the Initiator and one for the Responder; this is discussed in Section 10.
単一のkmsではなく、複数のkmsが関与している可能性があることに注意してください。これについては、セクション10で説明します。
The Initiator requests keys and a ticket (encoding the same keys) from the KMS by sending a REQUEST_INIT message. The REQUEST_INIT message includes session information (e.g., identities of the authorized responders) and is integrity protected by a MAC based on a pre-shared key or by a signature (similar to the pre-shared key and public-key encryption modes in [RFC3830]). If the request is authorized, the KMS generates the requested keys, encodes them in a ticket, and returns the keys and the ticket in a REQUEST_RESP message. The Ticket Request exchange is OPTIONAL (depending on the Ticket Type), and MAY be omitted if the Initiator can create the ticket without assistance from the KMS (see mode 3 of Section 4.1.1).
イニシエーターは、request_initメッセージを送信して、KMSからキーとチケット（同じキーをエンコード）を要求します。request_initメッセージには、セッション情報（承認されたレスポンダーのアイデンティティなど）が含まれており、事前共有キーまたは署名に基づいてMACによって保護されています（[RFC3830の事前共有キーおよびパブリックキー暗号化モードに似ています）]）。リクエストが承認されている場合、KMSは要求されたキーを生成し、チケットにそれらをエンコードし、request_respメッセージでキーとチケットを返します。チケットリクエストの交換はオプションであり（チケットの種類によって異なります）、イニシエーターがKMSの支援なしでチケットを作成できる場合は省略できます（セクション4.1.1のモード3を参照）。
The Initiator next includes the ticket in a TRANSFER_INIT message, which is sent to the Responder. The TRANSFER_INIT message is protected by a MAC based on an MPK (MIKEY Protection Key) encoded in the ticket. If the Responder finds the Ticket Policy and session security policies acceptable, the Responder forwards the ticket to the KMS. This is done with a RESOLVE_INIT message, which asks the KMS to return the keys encoded in the ticket. The RESOLVE_INIT message is protected by a MAC based on a pre-shared key (between Responder and KMS) or by a signature. The Ticket Resolve exchange is OPTIONAL (depending on the Ticket Policy), and SHOULD only be used when the Responder is unable to resolve the ticket without assistance from the KMS (see mode 2 of Section 4.1.1).
次に、イニシエーターには、Responderに送信されるTransfer_initメッセージのチケットが含まれます。Transfer_initメッセージは、チケットにエンコードされたMPK（Mikey Protection Key）に基づいたMACによって保護されています。レスポンダーがチケットポリシーとセッションセキュリティポリシーが許容できると判断した場合、レスポンダーはチケットをKMSに転送します。これは、Resolve_initメッセージで行われ、KMSにチケットにエンコードされたキーを返すように依頼します。Resolve_initメッセージは、事前共有キー（レスポンダーとKMSの間）または署名に基づいたMACによって保護されます。チケットResolve Exchangeはオプションであり（チケットポリシーによって異なります）、ResponderがKMSの支援なしにチケットを解決できない場合にのみ使用する必要があります（セクション4.1.1のモード2を参照）。
The KMS resolves the ticket. If the Responder is authorized to receive the keys encoded in the ticket, the KMS retrieves the keys and other information. If key forking is used, the keys are modified (bound to the Responder) by the KMS, see Section 5.1.1. The keys and additional information are then sent in a RESOLVE_RESP message to the Responder. The Responder then sends a TRANSFER_RESP message to the Initiator as verification. The TRANSFER_RESP message might include information used for further key derivation.
KMSはチケットを解決します。レスポンダーがチケットにエンコードされたキーを受信することが許可されている場合、KMSはキーやその他の情報を取得します。キーフォーキングを使用する場合、キーはKMSによって（レスポンダーにバインドされている）変更されます。セクション5.1.1を参照してください。キーと追加情報は、Resolve_RespメッセージでResponderに送信されます。その後、レスポンダーは検証として導入_ respメッセージをイニシエーターに送信します。Transf_Respメッセージには、さらにキー派生に使用される情報が含まれる場合があります。
The use case and signaling described above is the full three round-trip mode, but other modes are allowed, see Section 4.1.1. Pre-encrypted content is discussed in Section 8, group communication is discussed in Section 9, and signaling between different KMSs is discussed in Section 10. An alternative use case is discussed in Appendix B.
上記のユースケースとシグナリングは完全な3つの往復モードですが、他のモードが許可されています。セクション4.1.1を参照してください。事前に暗号化されたコンテンツについては、セクション8で説明し、グループコミュニケーションについてはセクション9で説明し、異なるKMS間のシグナル伝達についてセクション10で説明します。代替のユースケースについては、付録Bで説明します。
The session keys are normally generated/supplied by the KMS (encoded in the ticket), but in certain use cases (see Section 8) the session key may be supplied by the Initiator or Responder (sent in a separate KEMAC protected with keys derived from the MPK).
セッションキーは通常、KMSによって生成/提供されます（チケットにエンコードされています）が、特定のユースケース（セクション8を参照）では、セッションキーはイニシエーターまたはレスポンダー（MPK）。
MIKEY-TICKET offers a framework that is flexible enough to satisfy users with a broad range of security and functional needs. The framework consists of the three exchanges for which different Ticket Types can be defined. The ticket consists of a Ticket Policy as well as Ticket Data. The Ticket Policy contains information intended for all parties involved, whereas the Ticket Data is only intended for the party that resolves the ticket. The Ticket Data could be a reference to information (keys, etc.) stored by the key management service, it could contain all the information itself, or it could be a combination of the two alternatives. The format of the Ticket Data depends on the Ticket Type signaled in the Ticket Policy. The Ticket Data corresponding to the default Ticket Type, called MIKEY base ticket, is defined in Appendix A and requirements regarding new Ticket Types are given in Section 11.
Mikey-Ticketは、幅広いセキュリティと機能のニーズを持つユーザーを満足させるほど柔軟なフレームワークを提供します。フレームワークは、異なるチケットタイプを定義できる3つの交換で構成されています。チケットは、チケットポリシーとチケットデータで構成されています。チケットポリシーには、関係するすべての関係者向けの情報が含まれていますが、チケットデータはチケットを解決する当事者のみを対象としています。チケットデータは、キー管理サービスによって保存されている情報（キーなど）への参照である可能性があります。すべての情報自体を含めるか、2つの選択肢の組み合わせである可能性があります。チケットデータの形式は、チケットポリシーで合図されたチケットタイプに依存します。マイキーベースチケットと呼ばれるデフォルトのチケットタイプに対応するチケットデータは、付録Aで定義されており、新しいチケットタイプに関する要件はセクション11に記載されています。
As MIKEY-TICKET is based on [RFC3830], the same terminology, processing, and considerations still apply unless otherwise stated. Just like in [RFC3830], the messages are integrity protected and encryption is only applied to the keys and not to the entire messages.
Mikey-Ticketは[RFC3830]に基づいているため、特に明記しない限り、同じ用語、処理、および考慮事項がまだ適用されます。[RFC3830]と同様に、メッセージは整合性保護されており、暗号化はメッセージ全体にのみ適用されます。
Depending on the Ticket Type and the Ticket Policy, some of the exchanges might be optional or not used at all, see Figure 3. If the ticket protection is based on a key known only by the KMS, both the Initiator and the Responder have to contact the KMS to request/ resolve tickets (mode 1). If the key used to protect the ticket is shared between the KMS and the Responder, the Ticket Resolve exchange can be omitted (similar to Kerberos), as the Responder can resolve the ticket without assistance from the KMS (mode 2).
チケットの種類とチケットポリシーに応じて、交換の一部はオプションであるか、まったく使用されていない場合があります。図3を参照してください。チケット保護がKMSのみが知っているキーに基づいている場合、イニシエーターとレスポンダーの両方がしなければならない場合KMSに連絡して、チケットを要求/解決します（モード1）。チケットを保護するために使用されるキーがKMSとレスポンダーの間で共有される場合、レスポンダーはKMSからの支援なしでチケットを解決できるため、チケットの解決交換（Kerberosと同様）を省略できます（モード2）。
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
Ticket Request
(1) <------------------------------> Ticket Transfer
<------------------------------------------------------------->
<------------------------------>
Ticket Resolve
Ticket Request
(2) <------------------------------> Ticket Transfer
<------------------------------------------------------------->
Ticket Transfer
(3) <------------------------------------------------------------->
<------------------------------>
Ticket Resolve
Ticket Transfer
(4) <------------------------------------------------------------->
Figure 3: Modes
図3：モード
If the key protecting the ticket is shared between the Initiator and the KMS, the Ticket Request exchange can be omitted (similar to the Otway-Rees protocol [Otway-Rees]), as the Initiator can create the ticket without assistance from the KMS (mode 3). If the key protecting the ticket is shared between the Initiator and the Responder, both the Ticket Request and Ticket Resolve exchanges can be omitted (mode 4). This can be seen as a variation of the pre-shared key method of [RFC3830] with a mutual key-freshness guarantee.
チケットを保護するキーがイニシエーターとKMSの間で共有されている場合、チケットリクエストの交換を省略できます（Otway-Reesプロトコル[Otway-Rees]と同様）、イニシエーターはKMSの支援なしでチケットを作成できます（モード3）。チケットを保護するキーがイニシエーターとレスポンダーの間で共有されている場合、チケットリクエストとチケットの解決交換の両方を省略できます（モード4）。これは、相互のキーフレッシュ性保証を使用して、[RFC3830]の事前共有キーメソッドのバリエーションと見なすことができます。
In modes 1 and 2, the Ticket Request exchange can be omitted if the tickets and the corresponding keys are distributed from the KMS to the Initiator in some other way. In addition, as tickets may be reused (see Section 5.3), a single Ticket Request exchange may be followed by several Ticket Transfer exchanges.
モード1および2では、チケットと対応するキーがKMSからイニシエーターに他の方法で配布される場合、チケットリクエスト交換を省略できます。さらに、チケットが再利用される可能性があるため（セクション5.3を参照）、単一のチケットリクエスト交換に続いて、いくつかのチケット転送交換が行われる場合があります。
This exchange is used by the Initiator to request keys and a ticket from a trusted KMS with which the Initiator has pre-shared credentials. The request contains information (e.g., participant identities, etc.) describing the session the ticket is intended to protect. A full round trip is required for the Initiator to receive the ticket. The initial message REQUEST_INIT comes in two variants. The first variant corresponds to the pre-shared key (PSK) method of [RFC3830].
この交換は、イニシエーターによって使用され、キーとイニシエーターが事前に共有された資格情報を持っている信頼できるKMSからチケットを要求します。リクエストには、チケットが保護することを目的としたセッションを説明する情報（参加者のアイデンティティなど）が含まれています。イニシエーターがチケットを受け取るには、完全な往復が必要です。最初のメッセージrequest_initには2つのバリアントがあります。最初のバリアントは、[RFC3830]の事前共有キー（PSK）メソッドに対応しています。
Initiator KMS
イニシエーターKMS
REQUEST_INIT_PSK = ---->
HDR, T, RANDRi, [IDRi],
[IDRkms], TP, <---- REQUEST_RESP =
[IDRpsk], V HDR, T, [IDRkms],
TICKET, KEMAC, V
The second variant corresponds to the public-key (PK) method of [RFC3830].
2番目のバリアントは、[RFC3830]のパブリックキー（PK）メソッドに対応しています。
Initiator KMS
イニシエーターKMS
REQUEST_INIT_PK = ---->
HDR, T, RANDRi, [IDRi],
{CERTi}, [IDRkms], TP, <---- REQUEST_RESP =
[CHASH], PKE, SIGNi HDR, T, [IDRkms],
TICKET, KEMAC, V
As the REQUEST_INIT message MUST ensure the identity of the Initiator to the KMS, it SHALL be integrity protected by a MAC based on a pre-shared key or by a signature. The response message REQUEST_RESP is the same for the two variants and SHALL be protected using the pre-shared/envelope key indicated in the REQUEST_INIT message.
request_initメッセージは、イニシエーターのKMSへのIDを保証する必要があるため、株式の事前キーまたは署名に基づいてMACによって保護されます。応答メッセージrequest_respは2つのバリアントで同じであり、request_initメッセージに示されている事前共有/エンベロープキーを使用して保護されます。
In addition to the ticket, the Initiator receives keys, which it does not already know. The ticket contains both session information and information needed to resolve the ticket later, see Section 6.10.
チケットに加えて、イニシエーターにはまだ知られていないキーが受信されます。チケットには、後でチケットを解決するために必要なセッション情報と情報の両方が含まれています。セクション6.10を参照してください。
The REQUEST_INIT message MUST always include the Header (HDR), Timestamp (T), and RANDRi payloads.
request_initメッセージには、常にヘッダー（HDR）、タイムスタンプ（t）、およびrandriペイロードを含める必要があります。
In HDR, the CSB ID (Crypto Session Bundle ID) SHALL be assigned as in [RFC3830]. The V flag MUST be set to '1' but SHALL be ignored by the KMS as a response is MANDATORY. As Crypto Sessions (CSs) SHALL NOT be handled, the #CS MUST be set to '0' and the CS ID map type SHALL be the "Empty map" as defined in [RFC4563].
HDRでは、[RFC3830]のように、CSB ID（Crypto Session Bundle ID）が割り当てられます。Vフラグは「1」に設定する必要がありますが、応答が必須であるため、KMSによって無視されます。暗号セッション（CSS）は処理されないため、＃CSは「0」に設定する必要があり、CS IDマップタイプは[RFC4563]で定義されている「空のマップ」としなければなりません。
IDRi contains the identity of the Initiator. This identity SHOULD be included in the granted Ticket Policy.
IDRIには、イニシエーターの身元が含まれています。この身元は、付与されたチケットポリシーに含める必要があります。
IDRkms contains the identity of the KMS. It SHOULD be included, but it MAY be left out when it can be expected that the KMS has a single identity.
IDRKMSにはKMSのアイデンティティが含まれています。含める必要がありますが、KMSに単一のアイデンティティがあることが予想される場合に除外される場合があります。
The Ticket Policy payload (TP) contains the desired Ticket Policy. It includes for instance, the ticket's validity period, the number of requested keys, and the identities of authorized responders (see Section 6.10).
チケットポリシーペイロード（TP）には、目的のチケットポリシーが含まれています。たとえば、チケットの有効期間、要求されたキーの数、認定されたレスポンダーのアイデンティティが含まれます（セクション6.10を参照）。
The IDRi payload SHOULD be included but MAY be left out when it can be expected that the KMS can identify the Initiator by other means.
IDRIペイロードは含める必要がありますが、KMSが他の手段でイニシエーターを識別できることが予想される場合に除外される場合があります。
The IDRpsk payload is used to indicate the pre-shared key used. It MAY be omitted if the KMS can find the pre-shared key by other means.
IDRPSKペイロードは、使用される事前に共有キーを示すために使用されます。KMSが他の手段で事前共有キーを見つけることができる場合、省略される場合があります。
The last payload SHALL be a Verification payload (V) where the authentication key (auth_key) is derived from the pre-shared key shared by the Initiator and the KMS (see Section 5.1.2 for key derivation specification). The MAC SHALL cover the entire REQUEST_INIT_PSK message as well as the identities of the involved parties (see Section 5.5 for the exact definition).
最後のペイロードは、認証キー（auth_key）が、イニシエーターとKMSによって共有される事前共有キーから導出される検証ペイロード（v）でなければなりません（キー派生仕様についてはセクション5.1.2を参照）。Macは、関係者のrequest_init_pskメッセージ全体と、関係者の識別をカバーするものとします（正確な定義については、セクション5.5を参照）。
The identity IDRi and certificate CERTi SHOULD be included, but they MAY be left out when it can be expected that the KMS can obtain the certificate in some other manner. If a certificate chain is to be provided, each certificate in the chain SHOULD be included in a separate CERT payload. The Initiator's certificate MUST come first. Each following certificate MUST directly certify the one preceding it.
IDRIと証明書証明書を含める必要がありますが、KMSが他の方法で証明書を取得できることが予想される場合は、除外される場合があります。証明書チェーンを提供する場合、チェーン内の各証明書は別の証明書ペイロードに含める必要があります。イニシエーターの証明書が最初に来なければなりません。次の各証明書は、それ以前の証明書を直接証明する必要があります。
PKE contains the encrypted envelope key: PKE = E(PKkms, env_key). It is encrypted using the KMS's public key (PKkms). If the KMS possesses several public keys, the Initiator can indicate the key used in the CHASH payload.
PKEには、暗号化されたエンベロープキーが含まれています：pke = e（pkkms、env_key）。KMSの公開キー（PKKMS）を使用して暗号化されています。KMSがいくつかのパブリックキーを所有している場合、イニシエーターはチャッシュペイロードで使用されるキーを示すことができます。
SIGNi is a signature covering the entire REQUEST_INIT_PK message, using the Initiator's signature key (see Section 5.5 for the exact definition).
SIGNIは、イニシエーターの署名キーを使用して、request_init_pkメッセージ全体をカバーする署名です（正確な定義についてはセクション5.5を参照）。
If the KMS can verify the integrity of the received message and the message can be correctly parsed, the KMS MUST check the Initiator's authorization. If the Initiator is authorized to receive the requested ticket, possibly with a modified Ticket Policy, the KMS MUST send a REQUEST_RESP message. Unexpected payloads in the REQUEST_INIT message SHOULD be ignored. Errors are handled as described in Section 5.4.
KMSが受信したメッセージの整合性を確認し、メッセージを正しく解析できる場合、KMSはイニシエーターの承認を確認する必要があります。イニシエーターが、おそらく変更されたチケットポリシーを使用して要求されたチケットを受け取ることを許可されている場合、KMSはrequest_respメッセージを送信する必要があります。request_initメッセージの予期しないペイロードは無視する必要があります。エラーは、セクション5.4で説明されているように処理されます。
The version, PRF func and CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL be identical to the corresponding fields in the REQUEST_INIT message. The V flag has no meaning in this context. It SHALL be set to '0' by the KMS and ignored by the Initiator.
HDRペイロードのバージョン、PRF FUNCおよびCSB ID、＃CS、およびCS IDマップタイプフィールドは、Request_initメッセージの対応するフィールドと同一でなければなりません。Vフラグには、この文脈では意味がありません。KMSによって「0」に設定され、イニシエーターによって無視されます。
If one of the NTP timestamp types is used, the KMS SHALL generate a fresh timestamp value (unlike [RFC3830]), which may be used for clock synchronization. If the COUNTER timestamp type (see Section 6.6 of [RFC3830]) is used, the timestamp value MAY be equal to the one in the REQUEST_INIT message.
NTPタイムスタンプタイプの1つを使用する場合、KMSは、クロック同期に使用される可能性のある新しいタイムスタンプ値（[RFC3830]とは異なり）を生成するものとします。カウンタータイムスタンプタイプ（[RFC3830]のセクション6.6を参照）を使用する場合、タイムスタンプの値は、request_initメッセージの値と等しい場合があります。
The TICKET payload carries the granted Ticket Policy and the Ticket Data (see Section 6.10). As the KMS decides which Ticket Policy to use, this may not be the same Ticket Policy as the Initiator requested. The Ticket Type and the Ticket Data depend on the granted Ticket Policy.
チケットペイロードには、付与されたチケットポリシーとチケットデータが含まれます（セクション6.10を参照）。KMSが使用するチケットポリシーを決定するため、これはイニシエーターが要求したものと同じチケットポリシーではない場合があります。チケットの種類とチケットデータは、付与されたチケットポリシーによって異なります。
The KEMAC payload SHALL use the NULL authentication algorithm, as a MAC is included in the V payload. Depending on the type of REQUEST_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the encr_key (and salt_key). Depending on the encryption algorithm, the salting key may go into the IV (see [RFC3830]). If the TP payload in the REQUEST_INIT message does not contain a KEMAC, it is RECOMMENDED that the KMS's default KEMAC include a single TGK. The KEMAC SHALL include an MPK (MIKEY Protection Key), MPKi, used as a pre-shared key to protect the messages in the Ticket Transfer exchange. If key forking (see Section 5.1.1) is used (determined by the Ticket Policy) a second MPK, MPKr, SHALL be included in the KEMAC. Then, MPKi SHALL be used to protect the TRANSFER_INIT message and MPKr SHALL be used to verify the TRANSFER_RESP message. The KEMAC is hence constructed as follows:
KEMACペイロードは、MacがVペイロードに含まれているため、Null認証アルゴリズムを使用するものとします。request_initメッセージのタイプに応じて、sharedキーまたはエンベロープキーを使用して、encr_key（およびsalt_key）を導出する必要があります。暗号化アルゴリズムに応じて、塩漬けキーはIVに入ることがあります（[RFC3830]を参照）。request_initメッセージのTPペイロードにKEMACが含まれていない場合、KMSのデフォルトKEMACには単一のTGKを含めることをお勧めします。KEMACには、チケット転送交換のメッセージを保護するための事前共有キーとして使用されるMPK（Mikey Protection Key）、MPKIが含まれます。キーフォーキング（セクション5.1.1を参照）を使用する場合（チケットポリシーで決定）、2番目のMPK、MPKRがKEMACに含まれるものとします。次に、MPKIを使用してTransf_initメッセージを保護し、MPKRを使用してTransf_Respメッセージを確認する必要があります。したがって、Kemacは次のように構築されます。
KEMAC = E(encr_key, MPKi || [MPKr] || {TEK|TGK|GTGK})
The last payload SHALL be a Verification payload (V). Depending on the type of REQUEST_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the auth_key. The MAC SHALL cover the entire REQUEST_RESP message as well as the REQUEST_INIT message (see Section 5.5 for the exact definition).
最後のペイロードは、検証ペイロード（v）でなければなりません。request_initメッセージのタイプに応じて、shared pre-sharedキーまたはエンベロープキーのいずれかを使用してauth_keyを導出するものとします。Macは、Request_Respメッセージ全体とRequest_initメッセージをカバーするものとします（正確な定義については、セクション5.5を参照）。
If the Initiator can verify the integrity of the received message and the message can be correctly parsed, the ticket and the associated session information SHALL be stored. Unexpected payloads in the REQUEST_RESP message SHOULD be ignored. Errors are handled as described in Section 5.4.
イニシエーターが受信したメッセージの整合性を確認し、メッセージを正しく解析できる場合、チケットと関連するセッション情報を保存するものとします。request_respメッセージの予期しないペイロードは無視する必要があります。エラーは、セクション5.4で説明されているように処理されます。
Before using the received ticket, the Initiator MUST check that the granted Ticket Policy is acceptable. If not, the Initiator SHALL discard and MAY send a new REQUEST_INIT message suggesting a different Ticket Policy than before.
受信チケットを使用する前に、イニシエーターは、付与されたチケットポリシーが許容できることを確認する必要があります。そうでない場合、イニシエーターは廃棄し、以前とは異なるチケットポリシーを提案する新しいrequest_initメッセージを送信する場合があります。
This exchange is used to transfer a ticket as well as session information from the Initiator to a Responder. The exchange is modeled after the pre-shared key mode [RFC3830], but instead of a pre-shared key, an MPK encoded in the ticket is used. The session keys are also encoded in the TICKET payload, but in some use cases (see Section 8) they need to be sent in a separate KEMAC payload. The session information may be sent from the Initiator to the Responder (similar to [RFC3830]) or from the Responder to the Initiator (similar to [RFC4738]). As the motive for this exchange is to setup a shared secret key between Initiator and Responder, the Responder cannot check the authenticity of the message before the ticket is resolved (by KMS or Responder). A full round trip is required if Responder key confirmation and freshness guarantee are needed.
この交換は、チケットとセッション情報をイニシエーターからレスポンダーに転送するために使用されます。交換は、事前共有キーモード[RFC3830]をモデルにしますが、事前共有キーの代わりに、チケットにエンコードされたMPKが使用されます。セッションキーもチケットのペイロードでエンコードされていますが、一部のユースケース（セクション8を参照）では、別のKemacペイロードで送信する必要があります。セッション情報は、イニシエーターからレスポンダー（[RFC3830]と同様）またはレスポンダーからイニシエーター（[RFC4738]と同様）に送信される場合があります。この交換の動機は、イニシエーターとレスポンダーの間に共有秘密の鍵をセットアップすることであるため、レスポンダーはチケットが解決される前にメッセージの信頼性を確認できません（KMSまたはレスポンダーによって）。レスポンダーの重要な確認と新鮮さの保証が必要な場合は、完全な往復が必要です。
Initiator Responder
イニシエーターレスポンダー
TRANSFER_INIT = ---->
HDR, T, RANDRi, [IDRi],
[IDRr], {SP}, TICKET, < - - TRANSFER_RESP =
[KEMAC], V HDR, T, [RANDRr],
[IDRr], [RANDRkms],
{SP}, [KEMAC], V
The TRANSFER_INIT message MUST always include the Header (HDR), Timestamp (T), and RANDRi payloads.
Transf_initメッセージには、常にヘッダー（HDR）、タイムスタンプ（T）、およびRandriペイロードを含める必要があります。
In HDR, the CSB ID (Crypto Session Bundle ID) SHALL be assigned as in [RFC3830]. The value of the V flag SHALL agree with the F flag in the Ticket Policy and it SHALL be ignored by the Responder.
HDRでは、[RFC3830]のように、CSB ID（Crypto Session Bundle ID）が割り当てられます。Vフラグの値は、チケットポリシーのFフラグに同意するものとし、レスポンダーによって無視されます。
The IDRi and IDRr payloads SHOULD be included, but IDRi MAY be left out if the Responder can identify the Initiator by other means, and IDRr MAY be left out when it can be expected that the Responder has a single identity.
IDRIとIDRRのペイロードを含める必要がありますが、Responderが他の手段でイニシエーターを識別できる場合、IDRIは除外される場合があり、IDRRはResponderに単一のアイデンティティを持っていると予想される場合に除外される場合があります。
Multiple SP payloads MAY be used both to indicate supported security policies for a specific crypto session (similar to [RFC4738]) and to specify security policies for different crypto sessions (similar to [RFC3830]).
複数のSPペイロードを使用して、特定の暗号セッションのサポートされているセキュリティポリシー（[RFC4738]と同様）とさまざまな暗号セッションのセキュリティポリシー（[RFC3830に類似]）を指定するために使用できます。
The ticket payload (see Section 6.10) contains the Ticket Policy (see Section 6.10), Ticket Data (the default ticket type is defined in Appendix A), and Initiator Data. The Ticket Policy contains information intended for all parties involved, whereas the Ticket Data is only intended for the party that resolves the ticket. The Ticket Type provided in the Ticket Data is indicated in the Ticket Policy. The Initiator Data authenticates the Initiator when key forking (I flag) is used.
チケットペイロード（セクション6.10を参照）には、チケットポリシー（セクション6.10を参照）、チケットデータ（デフォルトチケットタイプは付録Aで定義されています）、およびイニシエーターデータが含まれています。チケットポリシーには、関係するすべての関係者向けの情報が含まれていますが、チケットデータはチケットを解決する当事者のみを対象としています。チケットデータに記載されているチケットの種類は、チケットポリシーに示されています。イニシエーターデータは、キーフォーキング（Iフラグ）が使用されるときにイニシエーターを認証します。
The KEMAC payload is handled in the same way as if it were sent in a later CSB update (see Section 5.2), with the only difference that the encr_key is always derived from MPKi and therefore accessible by all responders authorized to resolve the ticket. Initiator-specified keys MAY be used if the Initiator has pre-encrypted content and specific TEKs (Traffic Encryption Keys) need to be used (see Section 8). If indicated by the Ticket Policy (L flag), a KEMAC payload SHALL NOT be included.
KEMACペイロードは、後のCSBアップデートで送信された場合と同じ方法で処理されます（セクション5.2を参照）。ENCR_KEYは常にMPKIから派生しているため、チケットを解決するために許可されたすべてのレスポンダーがアクセスできるという唯一の違いがあります。イニシエーター指定キーを使用すると、イニシエーターが事前に暗号化されたコンテンツがあり、特定のTEK（トラフィック暗号化キー）を使用する必要がある場合が使用できます（セクション8を参照）。チケットポリシー（Lフラグ）で示された場合、Kemacペイロードは含まれません。
The last payload SHALL be a Verification payload (V) where the authentication key (auth_key) is derived from the MPKi (see Section 5.1.2 for key derivation specification). The MAC SHALL cover the entire TRANSFER_INIT message as well as the identities of the involved parties (see Section 5.5 for the exact definition).
最後のペイロードは、認証キー（auth_key）がMPKIから導出される検証ペイロード（v）でなければなりません（キー派生仕様についてはセクション5.1.2を参照）。Macは、Transfer_initメッセージ全体と関係者のIDをカバーするものとします（正確な定義については、セクション5.5を参照）。
As the Initiator and Responder do not have any pre-shared keys, the Responder cannot check the authenticity of the message before the ticket is resolved. The Responder SHALL however check that both the Ticket Policy and the security policies are acceptable. If they are not, the Responder SHALL reject without contacting the KMS. This is an early reject mechanism to avoid unnecessary KMS signaling when the Responder can conclude from the information at hand that it will not accept the connection. After the ticket has been resolved, the parsing of the TRANSFER_INIT message continues. Unexpected payloads in the TRANSFER_INIT message SHOULD be ignored. Errors are handled as described in Section 5.4. If the F flag in the Ticket Policy is set, the Responder MUST send a TRANSFER_RESP message.
イニシエーターとレスポンダーには事前に共有キーがないため、チケットが解決される前に応答者はメッセージの信ity性を確認できません。ただし、レスポンダーは、チケットポリシーとセキュリティポリシーの両方が許容できることを確認するものとします。そうでない場合、レスポンダーはKMSに連絡せずに拒否します。これは、リスコンダーが手元の情報から接続を受け入れないと締めくくることができる場合、不必要なKMSシグナリングを避けるための早期拒否メカニズムです。チケットが解決された後、Transf_initメッセージの解析が続きます。Transf_initメッセージの予期しないペイロードは無視する必要があります。エラーは、セクション5.4で説明されているように処理されます。チケットポリシーのFフラグが設定されている場合、ResponderはTransf_Respメッセージを送信する必要があります。
The version, PRF func and CSB ID fields in the HDR payload SHALL be identical to the corresponding fields in the TRANSFER_INIT message. The V flag has no meaning in this context. It SHALL be set to '0' by the Responder and ignored by the Initiator. The Responder SHALL update the CS ID map info so that each crypto session has exactly one security policy indicated. The Responder MUST provide Session Data (at least for SRTP) and SPI for each crypto session for which the Initiator has not supplied Session Data and SPI. If needed, the Responder MAY update Session Data and SPI provided by the Initiator. If the Responder adds crypto sessions, the #CS SHALL be updated.
HDRペイロード内のバージョン、PRF FUNCおよびCSB IDフィールドは、Transfer_initメッセージの対応するフィールドと同一でなければなりません。Vフラグには、この文脈では意味がありません。それは、応答者によって「0」に設定され、イニシエーターによって無視されます。応答者は、各暗号セッションに正確に1つのセキュリティポリシーが示されるように、CS IDマップ情報を更新するものとします。レスポンダーは、イニシエーターがセッションデータとSPIを提供していない各暗号セッションにセッションデータ（少なくともSRTPの場合）とSPIを提供する必要があります。必要に応じて、レスポンダーはイニシエーターが提供するセッションデータとSPIを更新する場合があります。応答者が暗号セッションを追加する場合、＃CSが更新されます。
If one of the NTP timestamp types is used, the Responder SHALL generate a fresh timestamp value (unlike [RFC3830]). If the COUNTER timestamp type (see Section 6.6 of [RFC3830]) is used, the timestamp value MAY be equal to the one in the TRANSFER_INIT message.
NTPタイムスタンプタイプの1つを使用する場合、レスポンダーは新しいタイムスタンプ値を生成します（[RFC3830]とは異なります）。カウンタータイムスタンプタイプ（[RFC3830]のセクション6.6を参照）を使用する場合、タイムスタンプの値はTransf_initメッセージの値と等しい場合があります。
If indicated by the Ticket Policy (G flag), the Responder SHALL generate a fresh (pseudo-)random byte string RANDRr. RANDRr is used to produce Responder freshness guarantee in key derivations.
チケットポリシー（Gフラグ）で示された場合、レスポンダーは新鮮な（擬似）ランダムバイト文字列randrrを生成するものとします。RANDRRは、主要な導出で応答性の新鮮さの保証を生成するために使用されます。
If the Responder receives an IDRr payload in the RESOLVE_RESP message, the same identity MUST be sent in an IDRr payload in the TRANSFER_RESP message. The identity sent in the IDRr payload in the TRANSFER_RESP message (e.g., user1@example.com) MAY differ from the one sent in the IDRr payload in the TRANSFER_INIT message (e.g., IT-support@example.com).
Resolve_RespメッセージでResponderがIDRRペイロードを受信した場合、Transfer_RespメッセージのIDRRペイロードで同じIDを送信する必要があります。Transfer_Respメッセージ（例：user1@example.com）のIDRRペイロードで送信されたIDは、Transf_initメッセージ（it-support@example.comなど）のidrrペイロードで送信されたものと異なる場合があります。
If the Responder receives a RANDRkms payload in the RESOLVE_RESP message, the same RAND MUST be sent in a RANDRkms payload in the TRANSFER_RESP message.
Resolve_RespメッセージでResponderがRANDRKMSペイロードを受信した場合、Transfer_RespメッセージのRANDRKMSペイロードで同じランドを送信する必要があります。
The Responder MAY provide additional Security Policy payloads. The Responder SHOULD NOT resend SP payloads, which the Initiator supplied.
レスポンダーは、追加のセキュリティポリシーペイロードを提供する場合があります。レスポンダーは、イニシエーターが提供したSPペイロードを再送信してはなりません。
The KEMAC payload SHALL be handled exactly as if it was sent in a later CSB update, see Section 5.2. Responder-specified keys MAY be used if Responder has pre-encrypted content and specific TEKs (Traffic Encryption Keys) need to be used (see Section 8). If indicated by the Ticket Policy (M flag), a KEMAC payload SHALL NOT be included.
KEMACペイロードは、後のCSBアップデートで送信されたかのように正確に処理されます。セクション5.2を参照してください。Responderが事前に暗号化されたコンテンツがあり、特定のTEK（トラフィック暗号化キー）を使用する必要がある場合、レスポンダー指定キーを使用できます（セクション8を参照）。チケットポリシー（Mフラグ）で示されている場合、KEMACペイロードは含まれません。
The last payload SHALL be a Verification payload (V) where the authentication key (auth_key) is derived from MPKi or MPKr' (depending on if key forking is used). The MAC SHALL cover the entire TRANSFER_RESP message as well as the TRANSFER_INIT message (see Section 5.5 for the exact definition).
最後のペイロードは、認証キー（auth_key）がMPKIまたはMPKRに由来する検証ペイロード（v）でなければなりません（キーフォーキングが使用されるかどうかに応じて）。Macは、Transf_Respメッセージ全体とTransf_initメッセージをカバーするものとします（正確な定義については、セクション5.5を参照）。
If the Initiator can verify the integrity of the received message and the message can be correctly parsed, the Initiator MUST check that any Responder-generated security policies are acceptable. If not, the Initiator SHALL discard and MAY send a new TRANSFER_INIT message to indicate supported security policies. Unexpected payloads in the TRANSFER_RESP message SHOULD be ignored. Errors are handled as described in Section 5.4.
イニシエーターが受信したメッセージの整合性を確認し、メッセージを正しく解析できる場合、イニシエーターは、対応するセキュリティポリシーが許容されることを確認する必要があります。そうでない場合、イニシエーターは廃棄し、サポートされているセキュリティポリシーを示すために新しいTransfer_initメッセージを送信する場合があります。transf_respメッセージの予期しないペイロードは無視する必要があります。エラーは、セクション5.4で説明されているように処理されます。
This exchange is used by the Responder to request that the KMS return the keys encoded in a ticket. The KMS does not need to be the same KMS that originally issued the ticket, see Section 10. A full round trip is required for the Responder to receive the keys. The Ticket Resolve exchange is OPTIONAL (depending on the Ticket Policy), and SHOULD only be used when the Responder is unable to resolve the ticket without assistance from the KMS. The initial message RESOLVE_INIT comes in two variants (independent from the used REQUEST_INIT variant). The first variant corresponds to the pre-shared key (PSK) method of [RFC3830].
この交換は、レスポンダーによって使用され、KMSがチケットにエンコードされたキーを返すように要求します。KMSは、元々チケットを発行したのと同じKMSである必要はありません。セクション10を参照してください。レスポンダーがキーを受け取るには、完全な往復が必要です。チケットResolve Exchangeはオプションであり（チケットポリシーによって異なります）、ResponderがKMSの支援なしにチケットを解決できない場合にのみ使用する必要があります。最初のメッセージResolve_initには2つのバリアントがあります（使用済みのrequest_initバリアントから独立しています）。最初のバリアントは、[RFC3830]の事前共有キー（PSK）メソッドに対応しています。
Responder KMS
レスポンダーKMS
RESOLVE_INIT_PSK = ---->
HDR, T, RANDRr, [IDRr],
[IDRkms], TICKET, <---- RESOLVE_RESP
[IDRpsk], V HDR, T, [IDRkms], KEMAC,
[IDRr], [RANDRkms], V
The second variant corresponds to the public-key (PK) method of [RFC3830].
2番目のバリアントは、[RFC3830]のパブリックキー（PK）メソッドに対応しています。
Responder KMS
レスポンダーKMS
RESOLVE_INIT_PK = ---->
HDR, T, RANDRr, [IDRr],
{CERTr}, [IDRkms], TICKET, <---- RESOLVE_RESP
[CHASH], PKE, SIGNr HDR, T, [IDRkms], KEMAC,
[IDRr], [RANDRkms], V
As the RESOLVE_INIT message MUST ensure the identity of the Responder to the KMS, it SHALL be protected by a MAC based on a pre-shared key or by a signature. The response message RESOLVE_RESP is the same for the two variants and SHALL be protected by using the pre-shared/ envelope key indicated in the RESOLVE_INIT message.
Resolve_initメッセージは、KMSへの応答者の身元を保証する必要があるため、事前共有キーまたは署名に基づいてMACによって保護されます。応答メッセージResolve_Respは2つのバリアントで同じであり、Resolve_initメッセージに示されている事前共有/エンベロープキーを使用して保護されます。
Upon receiving the RESOLVE_INIT message, the KMS verifies that the Responder is authorized to resolve the ticket based on ticket and KMS policies. The KMS extracts the session information from the ticket and returns this to the Responder. Since the KMS resolved the ticket, the Responder is assured of the integrity of the Ticket Policy, which contains the identity of the peer that requested or created the ticket. If key forking is used (I flag), the Responder is also assured that the peer that requested or created the ticket also sent the TRANSFER_INIT message. The Responder can complete the session information it got from the Initiator with the additional session information received from the KMS.
Resolve_initメッセージを受信すると、KMSは、チケットとKMSポリシーに基づいてチケットを解決することがレスポンダーが許可されていることを確認します。KMSはチケットからセッション情報を抽出し、これをレスポンダーに返します。KMSがチケットを解決したため、レスポンダーはチケットポリシーの整合性が保証されています。チケットポリシーには、チケットを要求または作成したピアの身元が含まれています。キーフォーキングが使用されている場合（Iフラグ）、レスポンダーは、チケットを要求または作成したピアがTransf_initメッセージを送信したことも保証されます。レスポンダーは、KMSから受信した追加のセッション情報を使用して、イニシエーターから得たセッション情報を完成させることができます。
The RESOLVE_INIT message MUST always include the Header (HDR), Timestamp (T), and RANDRr payloads.
Resolve_initメッセージには、常にヘッダー（HDR）、タイムスタンプ（T）、およびRANDRRペイロードを含める必要があります。
The CSB ID (Crypto Session Bundle ID) SHALL be assigned as in [RFC3830]. The V flag MUST be set to '1' but SHALL be ignored by the KMS as a response is MANDATORY. As crypto sessions SHALL NOT be handled, the #CS MUST be set to '0' and the CS ID map type SHALL be the "Empty map" as defined in [RFC4563].
CSB ID（Crypto Session Bundle ID）は、[RFC3830]のように割り当てられます。Vフラグは「1」に設定する必要がありますが、応答が必須であるため、KMSによって無視されます。暗号セッションは処理されないため、＃CSは「0」に設定する必要があり、CS IDマップタイプは[RFC4563]で定義されている「空のマップ」としなければなりません。
IDRkms SHOULD be included, but it MAY be left out when it can be expected that the KMS has a single identity.
IDRKMSを含める必要がありますが、KMSに単一のアイデンティティがあることが予想される場合に除外される場合があります。
The TICKET payload contains the Ticket Policy and Ticket Data that the Responder wants to have resolved.
チケットペイロードには、レスポンダーが解決したいチケットポリシーとチケットデータが含まれています。
IDRr contains the identity of the Responder. IDRr SHOULD be included, but it MAY be left out when it can be expected that the KMS can identify the Responder in some other manner.
IDRRには、レスポンダーの身元が含まれています。IDRRは含める必要がありますが、KMSが他の方法でレスポンダーを識別できることが予想される場合に除外される場合があります。
The IDRpsk payload is used to indicate the pre-shared key used. It MAY be omitted if the KMS can find the pre-shared key by other means.
IDRPSKペイロードは、使用される事前に共有キーを示すために使用されます。KMSが他の手段で事前共有キーを見つけることができる場合、省略される場合があります。
The last payload SHALL be a Verification payload (V) where the authentication key (auth_key) is derived from the pre-shared key shared by the Responder and the KMS. The MAC SHALL cover the entire RESOLVE_INIT_PSK message as well as the identities of the involved parties (see Section 5.5 for the exact definition).
最後のペイロードは、認証キー（auth_key）がレスポンダーとKMSが共有する事前共有キーから導出される検証ペイロード（v）でなければなりません。Macは、関係者のresolve_init_pskメッセージ全体と、関係者の識別をカバーするものとします（正確な定義については、セクション5.5を参照）。
The identity IDRr and certificate CERTr SHOULD be included, but they MAY be left out when it can be expected that the KMS can obtain the certificate in some other manner. If a certificate chain is to be provided, each certificate in the chain SHOULD be included in a separate CERT payload. The Responder's certificate MUST come first. Each following certificate MUST directly certify the one preceding it.
IDRRと証明書CERTRを含める必要がありますが、KMSが他の方法で証明書を取得できることが予想される場合は、除外される場合があります。証明書チェーンを提供する場合、チェーン内の各証明書は別の証明書ペイロードに含める必要があります。応答者の証明書が最初に来なければなりません。次の各証明書は、それ以前の証明書を直接証明する必要があります。
PKE contains the encrypted envelope key: PKE = E(PKkms, env_key). It is encrypted using PKkms. If the KMS possesses several public keys, the Responder can indicate the key used in the CHASH payload.
PKEには、暗号化されたエンベロープキーが含まれています：pke = e（pkkms、env_key）。PKKMSを使用して暗号化されています。KMSがいくつかのパブリックキーを所有している場合、レスポンダーはチャッシュペイロードで使用されるキーを示すことができます。
SIGNr is a signature covering the entire RESOLVE_INIT_PK message, using the Responder's signature key (see Section 5.5 for the exact definition).
SignRは、Responderの署名キーを使用して、Resolve_Init_PKメッセージ全体をカバーする署名です（正確な定義についてはセクション5.5を参照）。
If the KMS can verify the integrity of the received message, the message can be correctly parsed, and the Responder is authorized to resolve the ticket, the KMS MUST send a RESOLVE_RESP message. If key forking is used (I flag), the KMS SHALL also verify the integrity of the Initiator Data field in the TICKET payload. Unexpected payloads in the RESOLVE_INIT message SHOULD be ignored. Errors are handled as described in Section 5.4.
KMSが受信したメッセージの整合性を確認できる場合、メッセージを正しく解析でき、レスポンダーがチケットを解決することを許可されます。KMSはResolve_Respメッセージを送信する必要があります。キーフォーキングが使用されている場合（Iフラグ）、KMSはチケットペイロード内のイニシエーターデータフィールドの整合性も検証するものとします。Resolve_initメッセージの予期しないペイロードは無視する必要があります。エラーは、セクション5.4で説明されているように処理されます。
The version, PRF func and CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL be identical to the corresponding fields in the RESOLVE_INIT message. The V flag has no meaning in this context. It SHALL be set to '0' by the KMS and ignored by the Responder.
HDRペイロードのバージョン、PRF FUNCおよびCSB ID、＃CS、およびCS IDマップタイプフィールドは、Resolve_initメッセージの対応するフィールドと同一でなければなりません。Vフラグには、この文脈では意味がありません。KMSによって「0」に設定され、レスポンダーによって無視されます。
If one of the NTP timestamp types is used, the KMS SHALL generate a fresh timestamp value (unlike [RFC3830]), which may be used for clock synchronization. If the COUNTER timestamp type (see Section 6.6 of [RFC3830]) is used, the timestamp value MAY be equal to the one in the RESOLVE_INIT message.
NTPタイムスタンプタイプの1つを使用する場合、KMSは、クロック同期に使用される可能性のある新しいタイムスタンプ値（[RFC3830]とは異なり）を生成するものとします。カウンタータイムスタンプタイプ（[RFC3830]のセクション6.6を参照）を使用する場合、タイムスタンプの値はResolve_initメッセージの値と等しい場合があります。
The KEMAC payload SHALL use the NULL authentication algorithm, as a MAC is included in the V payload. Depending on the type of RESOLVE_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the encr_key (and salt_key). Depending on the encryption algorithm, the salting key may go into the IV (see [RFC3830]). The KEMAC SHALL include an MPK (MPKi), used as a pre-shared key to protect the messages in the Ticket Transfer exchange. The KEMAC is hence constructed as follows:
KEMACペイロードは、MacがVペイロードに含まれているため、Null認証アルゴリズムを使用するものとします。Resolve_initメッセージのタイプに応じて、sharedキーまたはエンベロープキーを使用して、encr_key（およびsalt_key）を導出する必要があります。暗号化アルゴリズムに応じて、塩漬けキーはIVに入ることがあります（[RFC3830]を参照）。KEMACには、チケット転送交換のメッセージを保護するための事前共有キーとして使用されるMPK（MPKI）を含めるものとします。したがって、Kemacは次のように構築されます。
KEMAC = E(encr_key, MPKi || [MPKr'] || {TEK|TGK|GTGK})
If key forking (see Section 5.1.1) is used (determined by the I flag in the Ticket Policy), a second MPK (MPKr') SHALL be included in the KEMAC. Then, MPKi SHALL be used to verify the TRANSFER_INIT message and MPKr' SHALL be used to protect the TRANSFER_RESP message. The KMS SHALL also fork the MPKr and the TGKs. The modifier used to derive the forked keys SHALL be included in the IDRr and RANDRkms payloads, where IDRr is the identity of the endpoint that answered and RANDRkms is a fresh (pseudo-)random byte string generated by the KMS. The reason that the KMS MAY adjust the Responder's identity is so that it matches an identity encoded in the ticket.
キーフォーキング（セクション5.1.1を参照）を使用する場合（チケットポリシーのIフラグによって決定）、2番目のMPK（MPKR '）をKEMACに含めます。次に、MPKIを使用してTransf_initメッセージを確認し、MPKR 'を使用してTransf_Respメッセージを保護します。KMSは、MPKRとTGKをフォークするものとします。フォークキーを導出するために使用される修飾子は、IDRRおよびrandRKMSペイロードに含まれます。ここでは、IDRRは回答したエンドポイントのアイデンティティであり、randRKMSはKMSによって生成された新鮮な（擬似）ランダムなバイト文字列です。KMSがレスポンダーの身元を調整できる理由は、チケットにエンコードされたアイデンティティと一致するようにするためです。
The last payload SHALL be a Verification payload (V). Depending on the type of RESOLVE_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the auth_key. The MAC SHALL cover the entire RESOLVE_RESP message as well as the RESOLVE_INIT message (see Section 5.5 for the exact definition).
最後のペイロードは、検証ペイロード（v）でなければなりません。Resolve_Initメッセージのタイプに応じて、shared pre-sharedキーまたはエンベロープキーのいずれかを使用してauth_keyを導出するものとします。Macは、Resolve_Respメッセージ全体とResolve_initメッセージをカバーするものとします（正確な定義については、セクション5.5を参照）。
If the Responder can verify the integrity of the received message and the message can be correctly parsed, the Responder MUST verify the TRANSFER_INIT message with the MPKi received from the KMS. If key forking is used, the Responder SHALL also verify that the MAC field in the V payload in the TRANSFER_INIT message is identical to the MAC field in the Vi payload in the Initiator Data field in the TICKET payload. Unexpected payloads in the RESOLVE_RESP message SHOULD be ignored. Errors are handled as described in Section 5.4.
対応者が受信したメッセージの整合性を確認し、メッセージを正しく解析できる場合、ResponderはKMSから受信したMPKIを使用してTransf_initメッセージを確認する必要があります。キーフォーキングが使用されている場合、Responderは、Transfer_initメッセージのVペイロード内のMACフィールドが、チケットペイロードのイニシエーターデータフィールドのVIペイロードのMACフィールドと同一であることを確認するものとします。Resolve_Respメッセージの予期しないペイロードは無視する必要があります。エラーは、セクション5.4で説明されているように処理されます。
For all messages in the Ticket Request and Ticket Resolve exchanges, the keys used to protect the MIKEY messages are derived from a pre-shared key or an envelope key. As crypto sessions SHALL NOT be handled, further keying material (i.e., TEKs) does not have to be derived.
チケットリクエストとチケットの解決交換のすべてのメッセージについて、マイキーメッセージを保護するために使用されるキーは、事前に共有キーまたはエンベロープキーから派生します。暗号セッションは処理されないため、さらなるキーイング素材（つまり、TEK）を導き出す必要はありません。
In the Ticket Transfer exchange, the keys used to protect the MIKEY messages are derived from an MPK. If key forking is used, the KMS and the Initiator SHALL fork the MPKr and the TGKs (encoded in the ticket) based on a modifier, and different MPKs (MPKi and MPKr') SHALL be used to protect the TRANSFER_INIT and TRANSFER_RESP messages. In addition, the Responder MAY generate a RAND used to give Responder key freshness guarantee.
チケット転送交換では、マイキーメッセージを保護するために使用されるキーはMPKから派生しています。キーフォーキングが使用されている場合、KMSとイニシエーターは、修飾子に基づいてMPKRとTGK（チケットにエンコード）をフォークし、異なるMPK（MPKIおよびMPKR '）を使用してTransf_InitおよびTransfer_Respメッセージを保護するものとします。さらに、レスポンダーは、レスポンダーのキーフレッシュ性保証を提供するために使用されるランドを生成する場合があります。
The key hierarchy and its dependencies on TRANSFER_INIT message contents for the case without key forking and RANDRr are illustrated in Figure 4. The KEMAC shown is the KEMAC sent from the KMS to the Initiator and the Responder. The illustrated key derivations are done by the Initiator and the Responder.
キーフォーキングとRANDRRのないケースのTransfer_initメッセージコンテンツへの主要な階層とその依存関係を図4に示します。図解されたキー導入は、イニシエーターとレスポンダーによって行われます。
+------+------------------+-----+------+
KEMAC | MPKi |..................| TGK | SALT |
+--+---+------------------+--+--+--+---+
| MPKi | |
v | |
CSB ID ----- auth_key ------ | |
+---------->| PRF |------------>| AUTH | | |
| ----- ------ | |
| ^ MAC | | |
| | RAND v | |
+--+--+------+----+---+--+--------+--+---+ | |
TRANSFER_INIT | HDR |......| RANDRi |..| TICKET |..| V | | |
+--+--+------+----+---+--+--------+--+---+ | |
| | RAND | |
| v | |
| CS ID ----- TGK | |
+---------->| PRF |<---------------------+ |
----- |
| TEK SALT |
v v
---------------------------------------
| Security Protocol, e.g., SRTP |
---------------------------------------
Figure 4: Key hierarchy without key forking and RANDRr
図4：キーフォーキングとrandRRのないキー階層
The key hierarchy and its dependencies on TRANSFER_RESP message contents for the case with key forking and RANDRr are illustrated in Figure 5. The KEMAC shown is the KEMAC sent from the KMS to the Initiator. MOD is the modifier (IDRr, RANDRkms). The two key derivations that produce forked keys are done by the Initiator and the KMS, and the remaining two key derivations are done by the Initiator and the Responder. The random value RANDRi from the TRANSFER_INIT message is used as input to the derivation of the auth_key and may be used as input to the derivation of the TEK, but this is omitted from the figure. The protection of the TRANSFER_INIT message is done as in Figure 4.
キーフォーキングとRANDRRを使用したケースのTransf_Respメッセージコンテンツの主要な階層とその依存関係を図5に示します。modは修飾子（IDRR、randRKMS）です。フォークキーを生成する2つのキー派生物は、イニシエーターとKMSによって行われ、残りの2つのキー派生はイニシエーターとレスポンダーによって行われます。Transfer_initメッセージからのランダム値Randriは、auth_keyの導出への入力として使用され、Tekの導出への入力として使用できますが、これは図から省略されています。Transf_initメッセージの保護は、図4のように行われます。
+------+--------------------------+-----+------+
KEMAC | MPKr |..........................| TGK | SALT |
+--+---+--------------------------+--+--+--+---+
| MPKr | |
v | |
----- MPKr' | |
| PRF |-------+ TGK | |
----- | | |
^ v | |
CSB ID | ----- auth_key ------ | |
+---------)------>| PRF |--------->| AUTH | | |
| | ----- ------ | |
| | ID Data ^ MAC | | |
| | RAND | RAND v | |
+--+--+---+--+--+---+---+----+----------+---+ | |
TRANSFER_RESP | HDR |...| MOD |...| RANDRr |..........| V | | |
+--+--+---+--+--+---+---+----+----------+---+ | |
| | | RAND v |
| | | ID Data ----- |
| +----------)------------------>| PRF | |
| | RAND ----- |
| v | |
| CS ID ----- TGK' | |
+---------------->| PRF |<------------------+ |
----- |
| TEK SALT |
v v
---------------------------------------
| Security Protocol, e.g., SRTP |
---------------------------------------
Figure 5: Key hierarchy with key forking and RANDRr
図5：キーフォーキングとrandRRを備えたキー階層
The labels in the key derivations SHALL NOT include entire RANDR payloads, only the fields RAND length and RAND from the corresponding payload.
キー派生のラベルには、RANDRペイロード全体を含めるものではなく、対応するペイロードからのFields RANDの長さとRANDのみが含まれます。
When key forking is used (determined by the I flag in the Ticket Policy), the MPKr and TGKs (encoded in the ticket) SHALL be forked. The TEKs and GTGKs (Group TGKs), however, SHALL NOT be forked. This key forking is done by the KMS and the Initiator using the PRF (Pseudorandom Function) indicated in the Ticket Policy. The parameters for the PRF are: inkey: : MPKr or TGK inkey_len : bit length of the inkey label : constant || 0xFF || 0xFFFFFFFF || 0x00 || length ID Data || ID Data || length RANDRkms || RANDRkms outkey_len : desired bit length of the outkey (MPKr', TGK') SHALL be equal to inkey_len
キーフォーキングが使用される場合（チケットポリシーのIフラグによって決定）、MPKRとTGK（チケットにエンコード）されます。ただし、TEKSとGTGKS（グループTGKS）は、フォークされてはなりません。このキーフォークは、KMSによって行われ、チケットポリシーに示されているPRF（擬似ランダム関数）を使用してイニシエーターが行われます。PRFのパラメーターは次のとおりです。INKEY：： MPKRまたはTGK inkey_len：inkeyラベルのビット長：定数||0xff ||0xffffffff ||0x00 ||長さのIDデータ||IDデータ||長さのrandrkms ||randrkms outkey_len：outkeyの希望ビット長（mpkr '、tgk'）はinkey_lenに等しくなります
where the ID Data field is taken from the IDRr payload sent in the RESOLVE_RESP and TRANSFER_RESP messages. Length ID Data is the length of the ID Data field in bytes as a 16-bit unsigned integer. Length RANDRkms is the length of RANDRkms in bytes as an 8-bit unsigned integer. The constant depends on the derived key type as summarized below.
IDデータフィールドがResolve_RespおよびTransfer_Respメッセージで送信されたIDRRペイロードから取得されます。長さのIDデータは、16ビットの署名整数としてバイト内のIDデータフィールドの長さです。長さのrandrkmsは、8ビットの符号なし整数としてバイト中のrandrkmsの長さです。定数は、以下に要約されているように、導出されたキータイプに依存します。
Derived key | Constant
------------+-----------
MPKr' | 0x2B288856
TGK' | 0x1512B54A
Table 5.1: Constants for forking key derivation
表5.1：キー派生のフォーキングの定数
The constants are taken from the decimal digits of e as described in [RFC3830].
定数は、[RFC3830]に記載されているように、Eの小数桁から取得されます。
This derivation is used to form the keys used to protect the MIKEY messages. For the Ticket Request and Ticket Resolve exchanges, the keys used to protect the MIKEY messages are derived from a pre-shared key or an envelope key. For the Ticket Transfer exchange, the keys are derived from an MPK. If key forking is used, different MPKs (MPKi and MPKr') SHALL be used to protect the TRANSFER_INIT and TRANSFER_RESP messages. The initial messages SHALL be protected with keys derived using the following parameters:
この派生は、マイキーメッセージを保護するために使用されるキーを形成するために使用されます。チケットリクエストとチケットの解決交換の場合、マイキーメッセージの保護に使用されるキーは、事前に共有キーまたはエンベロープキーから派生します。チケット転送交換の場合、キーはMPKから派生します。キーフォーキングを使用する場合、Transf_initおよびTransfer_Respメッセージを保護するために、異なるMPK（MPKIおよびMPKR '）を使用するものとします。最初のメッセージは、次のパラメーターを使用して導出されたキーで保護されなければなりません。
inkey: : pre-shared key, envelope key, or MPKi inkey_len : bit length of the inkey label : constant || 0xFF || CSB ID || 0x01 || length RANDRi || [RANDRi] || length RANDRr || [RANDRr] outkey_len : desired bit length of the outkey (encr_key, auth_key, salt_key)
inkey ：： shared key、envelope key、またはmpki inkey_len：inkeyラベルのビット長：定数||0xff ||CSB ID ||0x01 ||長さのrandri ||[randri] ||長さrandrr ||[randrr] outkey_len：outkeyの希望ビット長さ（encr_key、auth_key、salt_key）
The response messages SHALL be protected with keys derived using the following parameters: inkey: : pre-shared key, envelope key, MPKi, or MPKr' inkey_len : bit length of the inkey label : constant || 0xFF || CSB ID || 0x02 || length RANDRi || [RANDRi] || length RANDRr || [RANDRr] outkey_len : desired bit length of the outkey (encr_key, auth_key, salt_key)
応答メッセージは、次のパラメーターを使用して導出されたキーで保護されなければなりません。InKey：：事前共有キー、エンベロープキー、MPKI、またはMPKR 'inkey_len：inkeyラベルのビット長：定数||0xff ||CSB ID ||0x02 ||長さのrandri ||[randri] ||長さrandrr ||[randrr] outkey_len：outkeyの希望ビット長さ（encr_key、auth_key、salt_key）
The constant depends on the derived key type as defined in Section 4.1.4 of [RFC3830]. The 32-bit CSB ID field is taken from the HDR payload. RANDRi SHALL be included in the derivation of keys used to protect the Ticket Request and Ticket Transfer exchanges. RANDRr SHALL be included in the derivation of keys used to protect the Ticket Resolve exchange and in the derivation of keys used to protect TRANSFER_RESP if the Ticket Policy determines that it shall be present in the TRANSFER_RESP message (G flag). Length RANDRi is the length of RANDRi in bytes as an 8-bit unsigned integer, and Length RANDRr is the length of RANDRr in bytes as an 8-bit unsigned integer. If RANDRi is omitted, length RANDRi SHALL be 0 and if RANDRr is omitted, length RANDRr SHALL be 0. Note that at least one of RANDRi and RANDRr is always used.
定数は、[RFC3830]のセクション4.1.4で定義されている派生キータイプに依存します。32ビットCSB IDフィールドは、HDRペイロードから取得されます。RANDRIは、チケットのリクエストとチケットの転送交換を保護するために使用されるキーの派生に含まれるものとします。RANDRRは、チケットResolve Exchangeを保護するために使用されるキーの派生と、Transfer_RespがTransf_Respメッセージ（G Flag）に存在することを決定した場合、Transfer_Respを保護するために使用されるキーの導出に含まれます。長さのrandriは、8ビットの符号なし整数としてバイトのRandriの長さであり、長さのRandrrは8ビットの符号なし整数としてRandRRの長さです。randriが省略されている場合、長さのrandriは0であり、randrrが省略されている場合、長さのrandrrは0になります。
This only affects the Ticket Transfer exchange. In the following, we describe how keying material is derived from a TGK/GTGK. If key forking is used, any TGK encoded in the ticket SHALL be forked, and the forked key TGK' SHALL be used. The key derivation method SHALL be executed using the PRF indicated in the HDR payload. The parameters for the PRF are:
これは、チケット移籍の交換にのみ影響します。以下では、キーイング素材がTGK/GTGKに由来する方法について説明します。キーフォーキングが使用される場合、チケットにエンコードされたTGKはフォークされ、フォークキーTGK 'を使用するものとします。主要な派生法は、HDRペイロードに示されているPRFを使用して実行されるものとします。PRFのパラメーターは次のとおりです。
inkey: : TGK, TGK', or GTGK inkey_len : bit length of the inkey label : constant || CS ID || 0xFFFFFFFF || 0x03 || length RANDRi || [RANDRi] || length RANDRr || [RANDRr] outkey_len : desired bit length of the outkey (TEK, encr_key, auth_key, salt_key)
inkey ：： tgk、tgk '、またはgtgk inkey_len：inkeyラベルのビット長：定数||CS ID ||0xffffffff ||0x03 ||長さのrandri ||[randri] ||長さrandrr ||[Randrr] Outkey_len：Outkeyの希望のビット長（Tek、Encr_key、Auth_key、Salt_key）
The constant depends on the derived key type as defined in Section 4.1.3 of [RFC3830]. If a salting key is present in the key data sub-payload, a security protocol in need of a salting key SHALL use this salting key and a new salting key SHALL NOT be derived. The 8-bit CS ID field is given by the CS ID map info field in the HDR payload. RANDRi SHALL be included if the Ticket Policy determines that it shall be used (H flag). RANDRr SHALL be included if the Ticket Policy determines that it shall be present in the TRANSFER_RESP message (G flag). Length RANDRi is the length of RANDRi in bytes as an 8-bit unsigned integer, and Length RANDRr is the length of RANDRr in bytes as an 8-bit unsigned integer. If RANDRi or RANDRr is omitted the corresponding length SHALL be 0. Note that at least one of RANDRi and RANDRr MUST be used.
定数は、[RFC3830]のセクション4.1.3で定義されている派生キータイプに依存します。キーデータサブペイロードに塩漬けキーが存在する場合、塩漬けキーを必要とするセキュリティプロトコルはこの塩漬けキーを使用し、新しい塩漬けキーを導き出さないものとします。8ビットCS IDフィールドは、HDRペイロードのCS IDマップ情報フィールドによって与えられます。チケットポリシーがそれを使用することを決定した場合、Randriは含まれます（Hフラグ）。チケットポリシーがTransfer_Respメッセージ（Gフラグ）に存在することを決定した場合、RANDRRは含まれます。長さのrandriは、8ビットの符号なし整数としてバイトのRandriの長さであり、長さのRandrrは8ビットの符号なし整数としてRandRRの長さです。RANDRIまたはRANDRRが省略されている場合、対応する長さは0でなければなりません。RANDRIとRANDRRの少なくとも1つを使用する必要があることに注意してください。
Similar to [RFC3830], MIKEY-TICKET provides a means of updating the CSB (Crypto Session Bundle), e.g., transporting a new TEK/TGK/GTGK or adding new crypto sessions. The CSB updating is done by executing the Ticket Transfer exchange again, e.g., before a TEK expires or when a new crypto session is needed. The CSB updating can be started by the Initiator:
[RFC3830]と同様に、Mikey-Ticketは、CSB（Crypto Session Bundle）を更新する手段を提供します。たとえば、新しいTEK/TGK/GTGKの輸送や新しい暗号セッションの追加。CSBの更新は、たとえばTEKが有効期限を切る前、または新しい暗号セッションが必要なときに、チケット転送交換を再度実行することによって行われます。CSBの更新は、イニシエーターによって開始できます。
Initiator Responder
イニシエーターレスポンダー
TRANSFER_INIT = ---->
HDR, T, [IDRi], [IDRr],
{SP}, [KEMAC], V < - - TRANSFER_RESP =
HDR, T, [IDRr],
{SP}, [KEMAC], V
The CSB updating can also be started by the Responder:
CSBの更新は、応答者によって開始することもできます。
Responder Initiator
レスポンダーイニシエーター
TRANSFER_INIT = ---->
HDR, T, [IDRr], [IDRi],
{SP}, [KEMAC], V < - - TRANSFER_RESP =
HDR, T, [IDRi],
{SP}, [KEMAC], V
The new message exchange MUST use the same CSB ID as the initial exchange but MUST use new timestamps. The crypto sessions negotiation (#CS field, CS ID map info field, and SP payloads) are handled as in the initial exchange. In the TRANSFER_INIT message the V flag SHALL be used to indicate whether or not a response message is expected. Static payloads such as RANDRi, RANDRr, RANDRkms, and TICKET that were provided in the initial exchange SHOULD NOT be included unless they are needed by a specific use case. New RANDs or TICKETs MUST NOT be included. The reason that new RANDs SHALL NOT be used is that if several TGKs are used, the peers would need to keep track of which RANDs to use for each TGK. This adds unnecessary complexity. Both messages SHALL be protected with the same keys (derived from MPKi or MPKr') that protected the last message (TRANSFER_INIT or TRANSFER_RESP) in the initial exchange.
新しいメッセージ交換は、最初の交換と同じCSB IDを使用する必要がありますが、新しいタイムスタンプを使用する必要があります。暗号セッションの交渉（#CSフィールド、CS IDマップ情報フィールド、およびSPペイロード）は、最初の交換のように処理されます。transf_initメッセージでは、Vフラグを使用して、応答メッセージが予想されるかどうかを示すものとします。Randri、Randrr、Randrkms、および最初の交換で提供されたチケットなどの静的ペイロードは、特定のユースケースで必要でない限り含まれてはなりません。新しいランドやチケットを含めてはなりません。新しいランドを使用しない理由は、いくつかのTGKを使用する場合、ピアは各TGKに使用するランドを追跡する必要があるためです。これにより、不必要な複雑さが追加されます。両方のメッセージは、最初の交換で最後のメッセージ（Transfer_initまたはTransfer_resp）を保護する同じキー（MPKIまたはMPKR 'から派生）で保護されなければなりません。
New keying material MAY be sent in a KEMAC payload. If indicated by the Ticket Policy (L and M flags), KEMAC payloads SHALL NOT be included. In the TRANSFER_RESP message, a session key MUST be provided for each crypto session. The KEMAC SHALL use the NULL authentication algorithm, as a MAC is included in the V payload. The encr_key (and salt_key) SHALL be derived from the MPK (MPKi or MPKr'). Depending on the encryption algorithm, the salting key may go into the IV (see [RFC3830]). If a new TGK is exchanged, it SHALL NOT be forked. The KEMAC is hence constructed as follows:
新しいキーイング資料は、Kemacペイロードで送信される場合があります。チケットポリシー（LおよびMフラグ）で示された場合、Kemacペイロードは含まれません。transf_respメッセージでは、各暗号セッションにセッションキーを提供する必要があります。KEMACは、MACがVペイロードに含まれているため、Null認証アルゴリズムを使用するものとします。ENCR_KEY（およびSALT_KEY）は、MPK（MPKIまたはMPKR '）から派生するものとします。暗号化アルゴリズムに応じて、塩漬けキーはIVに入ることがあります（[RFC3830]を参照）。新しいTGKが交換された場合、フォークされてはなりません。したがって、Kemacは次のように構築されます。
KEMAC = E(encr_key, (TEK|TGK|GTGK))
kemac = e（encr_key、（tek | tgk | gtgk））
MIKEY-TICKET includes features aiming to offload the KMS from receiving ticket requests. One such feature is that tickets may be reused. This means that a user may request a ticket for media sessions with another user and then under the ticket's validity period use this ticket to protect several media sessions with that user.
Mikey-Ticketには、チケットリクエストの受信からKMSをオフロードすることを目的とした機能が含まれています。そのような機能の1つは、チケットが再利用される可能性があることです。これは、ユーザーが別のユーザーとのメディアセッションのチケットをリクエストし、チケットの有効期間の下でこのチケットを使用して、そのユーザーとの複数のメディアセッションを保護することができることを意味します。
When reusing a ticket that has been used in a previous Ticket Transfer exchange, a new Ticket Transfer exchange is executed. The new exchange MUST use a new CSB ID, a new timestamp, and new RANDs (RANDRi, RANDRr). If the Responder has resolved the ticket before, the Responder does not need to resolve the ticket again. In that case, the same modifier (IDRr, RANDRkms) SHALL be used. If the Ticket Policy forbids reuse (J flag), the ticket MUST NOT be reused. Note that such reuse cannot be detected by a stateless KMS. When group keys are used, ticket reuse leaves the Initiator responsible to ensure that group membership has not changed since the ticket was last used. (Otherwise, unauthorized responders may gain access to the group communication.) Thus, if group dynamics are difficult to verify, the Initiator SHOULD NOT initiate ticket reuse.
以前のチケット譲渡交換で使用されていたチケットを再利用すると、新しいチケット譲渡交換が実行されます。新しいExchangeは、新しいCSB ID、新しいタイムスタンプ、および新しいRANDS（RANDRI、RANDRR）を使用する必要があります。レスポンダーが以前にチケットを解決した場合、レスポンダーはチケットを再度解決する必要はありません。その場合、同じ修飾子（IDRR、RANDRKMS）を使用するものとします。チケットポリシーが再利用（Jフラグ）を禁止する場合、チケットを再利用してはなりません。そのような再利用は、ステートレスKMSによって検出できないことに注意してください。グループキーを使用すると、チケットの再利用は、チケットが最後に使用されてからグループメンバーシップが変更されていないことを確認するために、イニシエーターを担当します。（それ以外の場合、不正な応答者はグループ通信にアクセスできる場合があります。）したがって、グループのダイナミクスを検証が困難な場合、イニシエーターはチケットの再利用を開始すべきではありません。
When key forking is used, only the user that requested the ticket has access to the encoded master keys (MPKr, TGKs). Because of this, no one else can initiate a Ticket Transfer exchange using the ticket.
キーフォークを使用すると、チケットに要求したユーザーのみがエンコードされたマスターキー（MPKR、TGK）にアクセスできます。このため、チケットを使用してチケット移籍の交換を開始することはできません。
If a fatal error occurs during the parsing of a message, the message SHOULD be discarded, and an Error message SHOULD be sent to the other party (Initiator, Responder, KMS). If a failure is due to the inability to authenticate the peer, the message SHALL be discarded, the Error message is OPTIONAL, and the caveats in Section 5.1.2 of [RFC3830] apply. Error messages may be used to report errors in both initial and response messages, but not in Error messages.
メッセージの解析中に致命的なエラーが発生した場合、メッセージを破棄し、エラーメッセージを相手に送信する必要があります（イニシエーター、レスポンダー、KMS）。障害がピアを認証できないことが原因である場合、メッセージは破棄され、エラーメッセージはオプションであり、[RFC3830]のセクション5.1.2の警告が適用されます。エラーメッセージは、初期メッセージと応答メッセージの両方のエラーを報告するために使用できますが、エラーメッセージではありません。
In the Ticket Request and Ticket Resolve exchanges, the Error message MAY be authenticated with a MAC or a signature. The Error message is hence constructed as follows:
チケットリクエストとチケットの解決交換では、エラーメッセージがMacまたは署名で認証される場合があります。したがって、エラーメッセージは次のように作成されます。
Error message = HDR, T, (ERR), [V|SIGNx]
エラーメッセージ= hdr、t、（err）、[v | signx]
where x is in the set {i, r, kms} (Initiator, Responder, KMS). Unexpected payloads in the Error message SHOULD be ignored.
ここで、xはセット{i、r、kms}（initiatator、responder、kms）にあります。エラーメッセージの予期しないペイロードは無視する必要があります。
In the Ticket Transfer exchange, the Error message MAY be authenticated with a MAC. If the suggested security policies are not supported, the Error message SHOULD include the supported parameters. The Error message is hence constructed as follows:
チケット転送交換では、エラーメッセージがMACで認証される場合があります。提案されたセキュリティポリシーがサポートされていない場合、エラーメッセージにはサポートされているパラメーターを含める必要があります。したがって、エラーメッセージは次のように作成されます。
Error message = HDR, T, (ERR), {SP}, [V]
In Error messages, the version, PRF func, and CSB ID fields in the HDR payload SHALL be identical to the corresponding fields in the message where the error occurred. The V field SHALL be set to '0' and be ignored.
エラーメッセージでは、HDRペイロードのバージョン、PRF FUNC、およびCSB IDフィールドは、エラーが発生したメッセージの対応するフィールドと同一でなければなりません。Vフィールドは「0」に設定され、無視されます。
If one of the NTP timestamp types is used, a fresh timestamp value SHALL be used. If the COUNTER timestamp type (see Section 6.6 of [RFC3830]) is used, the timestamp value MAY be equal to the one in the message where the error occurred.
NTPタイムスタンプタイプの1つを使用する場合、新しいタイムスタンプ値を使用するものとします。カウンタータイムスタンプタイプ（[RFC3830]のセクション6.6を参照）を使用する場合、タイムスタンプの値は、エラーが発生したメッセージの値と等しい場合があります。
The MAC/Signature in the V/SIGN payloads covers the entire Error message, except the MAC/Signature field itself. The auth_key SHALL be the same as in the message where the error occurred.
V/signペイロードのMac/署名は、Mac/署名フィールド自体を除き、エラーメッセージ全体をカバーします。auth_keyは、エラーが発生したメッセージと同じでなければなりません。
The MAC/Signature in the V/SIGN payloads covers the entire MIKEY message, except the MAC/Signature field itself. For initial messages, the identities (not whole payloads) of the parties involved MUST directly follow the MIKEY message in the Verification MAC/ Signature calculation. In the TRANSFER_INIT message, the MAC SHALL NOT cover the Initiator Data length and Initiator Data fields in the TICKET payload. Note that in the Transfer Exchange, Identity_r in TRANSFER_RESP (e.g., user1@example.com) MAY differ from that appearing in TRANSFER_INIT (e.g., IT-support@example.com). For response messages, the entire initial message (including the MAC/ Signature field) MUST directly follow the MIKEY message in the Verification MAC/Signature calculation (the identities are implicitly covered as they are covered by the initial message's MAC/Signature).
V/signペイロードのMac/署名は、Mac/署名フィールド自体を除き、Mikeyメッセージ全体をカバーしています。最初のメッセージの場合、関係者のID（ペイロード全体ではなく）は、検証MAC/署名計算のMikeyメッセージに直接従う必要があります。Transf_initメッセージでは、Macはチケットペイロード内のイニシエーターデータの長さとイニシエーターデータフィールドをカバーしてはなりません。転送交換では、Transfer_respのIdentity_r（例：user1@example.com）は、Transf_init（例：it-support@example.com）に表示されるものとは異なる場合があることに注意してください。応答メッセージの場合、最初のメッセージ全体（MAC/署名フィールドを含む）は、検証MAC/署名計算のMikeyメッセージに直接従う必要があります（IDは、最初のメッセージのMAC/署名でカバーされているため、暗黙的にカバーされます）。
Message type | MAC/Signature coverage
--------------+--------------------------------------------
REQUEST_INIT | REQUEST_INIT || Identity_i || Identity_kms
REQUEST_RESP | REQUEST_RESP || REQUEST_INIT
TRANSFER_INIT | TRANSFER_INIT || Identity_i || Identity_r
TRANSFER_RESP | TRANSFER_RESP || TRANSFER_INIT
RESOLVE_INIT | RESOLVE_INIT || Identity_r || Identity_kms
RESOLVE_RESP | RESOLVE_RESP || RESOLVE_INIT
Error message | Error message
Table 5.2: MAC/Signature coverage
表5.2：Mac/署名カバレッジ
This section does not describe all the payloads that are used in the new message types. It describes in detail the new TR, IDR, RANDR, TP, and TICKET payloads. For the other payloads, only the additions and changes compared to [RFC3830] are described. For a detailed description of the other MIKEY payloads, see [RFC3830]. Note that the fields with variable length are byte aligned and not 32-bit aligned.
このセクションでは、新しいメッセージタイプで使用されるすべてのペイロードについては説明しません。新しいTR、IDR、RANDR、TP、およびチケットペイロードを詳細に説明しています。他のペイロードについては、[RFC3830]と比較した追加と変更のみが記載されています。他のマイキーペイロードの詳細な説明については、[RFC3830]を参照してください。長さが変数のあるフィールドはバイトアラインが付けられており、32ビットアラインは整列されていないことに注意してください。
For the Common Header Payload, new values are added to the Data Type, Next Payload, PRF func, and CS ID map type name spaces.
一般的なヘッダーペイロードの場合、データ型、次のペイロード、PRF FUNC、およびCS IDマップタイプの名前スペースに新しい値が追加されます。
* Data Type (8 bits): describes the type of message.
* データタイプ（8ビット）：メッセージのタイプを説明します。
Data Type | Value | Comment
-----------------+-------+-------------------------------------
REQUEST_INIT_PSK | 11 | Ticket request initial message (PSK)
REQUEST_INIT_PK | 12 | Ticket request initial message (PK)
REQUEST_RESP | 13 | Ticket request response message
| |
TRANSFER_INIT | 14 | Ticket transfer initial message
TRANSFER_RESP | 15 | Ticket transfer response message
| |
RESOLVE_INIT_PSK | 16 | Ticket resolve initial message (PSK)
RESOLVE_INIT_PK | 17 | Ticket resolve initial message (PK)
RESOLVE_RESP | 18 | Ticket resolve response message
Table 6.1: Data Type (Additions)
表6.1：データ型（追加）
* Next Payload (8 bits): identifies the payload that is added after this payload.
* 次のペイロード（8ビット）：このペイロード後に追加されたペイロードを識別します。
Next Payload | Value | Section
-------------+-------+--------
TR | 13 | 6.4
IDR | 14 | 6.6
RANDR | 15 | 6.8
TP | 16 | 6.10
TICKET | 17 | 6.10
Table 6.2: Next Payload (Additions)
表6.2：次のペイロード（追加）
* V (1 bit): flag to indicate whether a response message is expected ('1') or not ('0'). It MUST be set to '0' and ignored in all messages except TRANSFER_INIT messages used for CSB updating (see Section 5.2).
* V（1ビット）：応答メッセージが予想されるかどうかを示すフラグ（ '1'）かどうか（ '0'）。「0」に設定し、CSBの更新に使用されるTransf_initメッセージを除くすべてのメッセージで無視する必要があります（セクション5.2を参照）。
* PRF func (7 bits): indicates the PRF function that has been/will be used for key derivation. Besides the PRFs already defined in [RFC3830] the following additional PRF may be used.
* PRF FUNC（7ビット）：キー導入に使用された/使用されたPRF関数を示します。[RFC3830]ですでに定義されているPRFに加えて、次の追加のPRFを使用できます。
PRF func | Value
-----------------+------
PRF-HMAC-SHA-256 | 1
Table 6.3: PRF func (Additions)
表6.3：PRF FUNC（追加）
The new PRF SHALL be constructed as described in Section 4.1.2 of [RFC3830] with the differences that HMAC-SHA-256 (see Section 6.2) SHALL be used instead of HMAC-SHA-1 and the value 256 SHALL be used instead of 160. This corresponds to the full output length of SHA-256.
[RFC3830]のセクション4.1.2で説明されているように、新しいPRFは、HMAC-SHA-256（セクション6.2を参照）をHMAC-SHA-1の代わりに使用し、値256の代わりに使用する違いがある場合、新しいPRFを構築するものとします。160.これは、SHA-256の完全な出力長に対応します。
* #CS (8 bits): indicates the number of crypto sessions in the CS ID map info.
* #CS（8ビット）：CS IDマップ情報の暗号セッションの数を示します。
* CS ID map type (8 bits): specifies the method of uniquely mapping crypto sessions to the security protocol sessions. In the Ticket Transfer exchange the new GENERIC-ID map type, which is intended to eliminate the limitations with the existing SRTP-ID map type, SHOULD be used. The map type SRTP-ID SHALL NOT be used.
* CS IDマップタイプ（8ビット）：セキュリティプロトコルセッションに暗号セッションを一意にマッピングする方法を指定します。チケット転送交換では、既存のSRTP-IDマップタイプで制限を排除することを目的とした新しいGeneric-IDマップタイプを使用する必要があります。マップタイプのsrtp-idは使用してはなりません。
CS ID map type | Value
----------------------
GENERIC-ID | 2
Table 6.4: CS ID map type (Additions)
表6.4：CS IDマップタイプ（追加）
* CS ID map info (variable length): identifies and maps the crypto sessions to the security protocol sessions for which security associations should be created.
* CS IDマップ情報（変数長）：セキュリティ関連を作成するセキュリティプロトコルセッションに暗号セッションを識別およびマップします。
For the GENERIC-ID map type, the CS ID map info consists of #CS number of blocks, each mapping policies, session data (e.g., SSRC), and key to a specific crypto session.
Generic-IDマップタイプの場合、CS IDマップ情報は、＃CS数のブロック数、各マッピングポリシー、セッションデータ（SSRCなど）、および特定の暗号セッションのキーで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CS ID ! Prot type !S! #P ! Ps (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Session Data Length ! Session Data (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI Length ! SPI (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* CS ID (8 bits): defines the CS ID to be used for the crypto session.
* CS ID（8ビット）：暗号セッションに使用されるCS IDを定義します。
* Prot type (8 bits): defines the security protocol to be used for the crypto session. Allowed values are the ones defined for the Prot type field in the SP payload (see Section 6.10 of [RFC3830]).
* PROTタイプ（8ビット）：暗号セッションに使用されるセキュリティプロトコルを定義します。許可された値は、SPペイロードのPROTタイプフィールドに対して定義された値です（[RFC3830]のセクション6.10を参照）。
* S (1 bit): flag that MAY be used by the Session Data.
* S（1ビット）：セッションデータで使用できるフラグ。
* #P (7 bits): indicates the number of security policies provided for the crypto session. In response messages, #P SHALL always be exactly 1. So if #P = 0 in an initial message, a security profile MUST be provided in the response message. If #P > 0, one of the suggested policies SHOULD be chosen in the response message. If needed (e.g., in group communication, see Section 9), the suggested policies MAY be changed.
* #P（7ビット）：暗号セッションに提供されるセキュリティポリシーの数を示します。応答メッセージでは、#Pは常に正確に1でなければなりません。したがって、最初のメッセージで#P = 0の場合、応答メッセージにセキュリティプロファイルを提供する必要があります。#P> 0の場合、提案されたポリシーの1つを応答メッセージに選択する必要があります。必要に応じて（たとえば、グループ通信、セクション9を参照）、提案されたポリシーが変更される場合があります。
* Ps (variable length): lists the policies for the crypto session. It SHALL contain exactly #P policies, each having the specified Prot type.
* PS（変数長）：暗号セッションのポリシーをリストします。それぞれが指定されたPROTタイプを持っている正確な＃Pポリシーを含めるものとします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_1 ! Policy_no_2 ! ... ! Policy_no_#P !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Policy_no_i (8 bits): a policy_no that corresponds to the policy_no of a SP payload. In response messages, the policy_no may refer to a SP payload in the initial message.
* policy_no_i（8ビット）：SPペイロードのpolicy_noに対応するpolicy_no。応答メッセージでは、policy_noは最初のメッセージのSPペイロードを参照する場合があります。
* Session Data Length (16 bits): the length of Session Data (in bytes). For the Prot type SRTP, Session Data MAY be omitted in the initial message (length = 0), but it MUST be provided in the response message.
* セッションデータの長さ（16ビット）：セッションデータの長さ（バイト単位）。PROTタイプのSRTPの場合、セッションデータは最初のメッセージ（長さ= 0）で省略される場合がありますが、応答メッセージで提供する必要があります。
* Session Data (variable length): contains session data for the crypto session. The type of Session Data depends on the specified Prot type. The Session Data for the Prot type SRTP is defined below. The S flag is used to indicate whether the ROC and SEQ fields are provided ('1') or if they are omitted ('0').
* セッションデータ（変数長）：暗号セッションのセッションデータが含まれています。セッションデータのタイプは、指定されたPROTタイプに依存します。PROTタイプSRTPのセッションデータを以下に定義します。Sフラグは、ROCフィールドと配列フィールドが提供されている（ '1'）か省略されているか（ '0'）かを示すために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC (OPTIONAL) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SEQ (OPTIONAL) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* SSRC (32 bits): specifies the SSRC that MUST be used for the crypto session. Note that unlike [RFC3830], an SSRC field set to '0' has no special meaning.
* SSRC（32ビット）：暗号セッションに使用する必要があるSSRCを指定します。[RFC3830]とは異なり、「0」に設定されたSSRCフィールドには特別な意味がないことに注意してください。
* ROC (32 bits): current/initial rollover counter. If the session has not started, this field is set to '0'.
* ROC（32ビット）：現在/初期ロールオーバーカウンター。セッションが開始されていない場合、このフィールドは「0」に設定されています。
* SEQ (16 bits): current/initial sequence number.
* seq（16ビット）：電流/初期シーケンス番号。
* SPI Length (8 bits): the length of SPI (in bytes). SPI MAY be omitted in the initial message (length = 0), but it MUST be provided in the response message.
* SPIの長さ（8ビット）：SPIの長さ（バイト単位）。SPIは最初のメッセージ（長さ= 0）で省略される場合がありますが、応答メッセージで提供する必要があります。
* SPI (variable length): the SPI (or MKI) corresponding to the session key to (initially) be used for the crypto session. This does not exclude other keys to be used. All keys MUST belong to the crypto session bundle.
* SPI（変数長）：セッションキーに対応するSPI（またはMKI）は、（最初は）暗号セッションに使用されます。これは、使用する他のキーを除外しません。すべてのキーは、暗号セッションバンドルに属している必要があります。
For the KEMAC payload, new encryption and authentication algorithms are defined.
KEMACペイロードの場合、新しい暗号化と認証アルゴリズムが定義されています。
* Encr alg (8 bits): the encryption algorithm used to encrypt the Encr data field. Besides the algorithms already defined in [RFC3830], the following additional encryption algorithm may be used.
* ENCR ALG（8ビット）：ENCRデータフィールドを暗号化するために使用される暗号化アルゴリズム。[RFC3830]ですでに定義されているアルゴリズムに加えて、次の追加暗号化アルゴリズムを使用することができます。
Encr alg | Value | Comment
-----------+-------+---------------------------
AES-CM-256 | 3 | AES-CM using a 256-bit key
Table 6.5: Encr alg (Additions)
表6.5：ENCRアルグ（追加）
The new encryption algorithm is defined as described in Section 4.2.3 of [RFC3830] with the only difference being that a 256-bit key SHALL be used.
新しい暗号化アルゴリズムは、[RFC3830]のセクション4.2.3で説明されているように定義されており、唯一の違いは256ビットキーを使用することです。
* MAC alg (8 bits): specifies the authentication algorithm used. Besides the algorithms already defined in [RFC3830], the following additional authentication algorithm may be used.
* Mac Alg（8ビット）：使用される認証アルゴリズムを指定します。[RFC3830]ですでに定義されているアルゴリズムに加えて、以下の追加認証アルゴリズムを使用することができます。
MAC alg | Value | Length
-----------------+-------+---------
HMAC-SHA-256-256 | 2 | 256 bits
Table 6.6: MAC alg (Additions)
表6.6：Mac Alg（追加）
The new authentication algorithm is Hash-based Message Authentication Code (HMAC) [RFC2104] in conjunction with SHA-256 [FIPS.180-3]. It SHALL be used with a 256-bit authentication key.
新しい認証アルゴリズムは、SHA-256 [FIPS.180-3]と組み合わせて、ハッシュベースのメッセージ認証コード（HMAC）[RFC2104]です。256ビット認証キーで使用するものとします。
For the key data sub-payload, new types of keys are defined. The Group TGK (GTGK) is used as a regular TGK, with the difference that it SHALL NOT be forked. It is intended to enable the establishment of a group TGK when key forking is used. The MIKEY Protection Key (MPK) is used to protect the MIKEY messages in the Ticket Transfer exchange. The MPK is used as the pre-shared key in the pre-shared key method of [RFC3830]; however, it is not known by the Responder before the ticket has been resolved.
キーデータサブペイロードの場合、新しいタイプのキーが定義されています。グループTGK（GTGK）は通常のTGKとして使用され、フォークされないという違いがあります。キーフォーキングが使用されたときに、グループTGKの確立を可能にすることを目的としています。Mikey Protection Key（MPK）は、チケット転送交換でMikeyメッセージを保護するために使用されます。MPKは、[RFC3830]の事前共有キーメソッドの事前共有キーとして使用されます。ただし、チケットが解決される前に、レスポンダーにはわかりません。
An SPI (or MKI) MUST be specified for each key (see Section 6.13 of [RFC3830]).
各キーに対してSPI（またはMKI）を指定する必要があります（[RFC3830]のセクション6.13を参照）。
* Type (4 bits): indicates the type of key included in the payload.
* タイプ（4ビット）：ペイロードに含まれるキーのタイプを示します。
Type | Value | Comments
----------+-------+---------------------
GTGK | 4 | Group TGK
GTGK+SALT | 5 | Group TGK + SALT
MPK | 6 | MIKEY Protection Key
Table 6.7: Key Data Type (Additions)
表6.7：キーデータ型（追加）
For the timestamp payload, a new type of timestamp is defined. The new type is intended to be used when defining validity periods, where fractions of seconds seldom matter. The NTP-UTC-32 string contains four bytes, in the same format as the first four bytes in the NTP timestamp format, defined in [RFC4330]. This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 7 February 2036, the time value will overflow. [RFC4330] describes a procedure to extend the time to 2104 and this procedure is MANDATORY to support.
タイムスタンプペイロードの場合、新しいタイプのタイムスタンプが定義されています。新しいタイプは、有効期間を定義するときに使用することを目的としています。NTP-UTC-32文字列には、[RFC4330]で定義されているNTPタイムスタンプ形式の最初の4バイトと同じ形式の4つのバイトが含まれています。これは、調整されたユニバーサル時間（UTC）に関して、1900年1月1日の0H以降の秒数を表しています。2036年2月7日、時間値がオーバーフローします。[RFC4330]は、時間を2104に延長する手順を説明しており、この手順はサポートする必要があります。
* TS Type (8 bits): specifies the timestamp type used.
* TSタイプ（8ビット）：使用されるタイムスタンプタイプを指定します。
TS Type | Value | Length
-----------+-------+--------
NTP-UTC-32 | 3 | 32 bits
Table 6.8: TS Type (Additions)
表6.8：TSタイプ（追加）
NTP-UTC-32 SHALL be padded to a 64-bit NTP-UTC timestamp (with zeroes in the fractional second part) when a 64-bit timestamp is required (e.g. IV creation in AES-CM-128 and AES-CM-256).
NTP-UTC-32は、64ビットタイムスタンプが必要な場合（AES-CM-128およびAES-CM-256でのIV作成が必要な場合、64ビットNTP-UTCタイムスタンプ（分数第2部にゼロを含む）にパディングされます。）。
The TR payload uses all the fields from the standard timestamp payload (T) but expands it with a new field describing the role of the timestamp. Whereas the TS Type describes the type of the TS Value, the TS Role describes the meaning of the timestamp itself. The TR payload is intended to eliminate ambiguity when a MIKEY message contains several timestamp payloads (e.g., in the Ticket Policy).
TRペイロードは、標準のタイムスタンプペイロード（T）のすべてのフィールドを使用しますが、タイムスタンプの役割を説明する新しいフィールドで拡張します。TSタイプはTS値のタイプを記述しますが、TSの役割はタイムスタンプ自体の意味を記述します。TRペイロードは、Mikeyメッセージにいくつかのタイムスタンプペイロードが含まれている場合（たとえば、チケットポリシーに）曖昧さを排除することを目的としています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! TS Role ! TS Type ! TS Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* TS Role (8 bits): specifies the sort of timestamp.
* TSロール（8ビット）：タイムスタンプの種類を指定します。
TS Role | Value
-------------------------------+------
Time of issue (TRi) | 1
Start of validity period (TRs) | 2
End of validity period (TRe) | 3
Rekeying interval (TRr) | 4
Table 6.9: TS Role
表6.9：TSロール
For the ID payload, a new ID Type byte string is defined. The byte string type is intended to be used when the ID payload is used to identify a pre-shared key. Contrary to the previously defined ID Types (URI, Network Access Identifier), the byte string does not have any encoding rules.
IDペイロードの場合、新しいIDタイプのバイト文字列が定義されています。バイト文字列タイプは、IDペイロードを使用して事前共有キーを識別する場合に使用することを目的としています。以前に定義されたIDタイプ（URI、ネットワークアクセス識別子）とは反対に、バイト文字列にはエンコードルールがありません。
* ID Type (8 bits): specifies the identifier type used.
* IDタイプ（8ビット）：使用される識別子タイプを指定します。
ID Type | Value
------------+------
Byte string | 2
Table 6.10: ID Type (Additions)
表6.10：IDタイプ（追加）
The IDR payload uses all the fields from the standard identity payload (ID) but expands it with a new field describing the role of the ID payload. Whereas the ID Type describes the type of the ID Data, the ID Role describes the meaning of the identity itself. The IDR payload is intended to eliminate ambiguity when a MIKEY message contains several identity payloads. The IDR payload MUST be used instead of the ID payload in all MIKEY-TICKET messages.
IDRペイロードは、標準のIDペイロード（ID）のすべてのフィールドを使用しますが、IDペイロードの役割を説明する新しいフィールドで展開します。IDタイプはIDデータのタイプを記述しますが、IDロールはID自体の意味を説明します。IDRペイロードは、MikeyメッセージにいくつかのIDペイロードが含まれている場合、あいまいさを排除することを目的としています。IDRペイロードは、すべてのMikey-TicketメッセージでIDペイロードの代わりに使用する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! ID Role ! ID Type ! ID len
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID len (cont) ! ID Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* ID Role (8 bits): specifies the sort of identity.
* IDロール（8ビット）：種類のアイデンティティを指定します。
ID Role | Value
------------------------+------
Initiator (IDRi) | 1
Responder (IDRr) | 2
KMS (IDRkms) | 3
Pre-Shared Key (IDRpsk) | 4
Application (IDRapp) | 5
Table 6.11: ID Role
表6.11：IDロール
IDRapp is intended to specify the authorized Application IDs (see Sections 5.1.3 and 6.10)
IDRAPPは、承認されたアプリケーションIDを指定することを目的としています（セクション5.1.3および6.10を参照）
* Hash func (8 bits): indicates the hash function that is used. Besides the hash functions already defined in [RFC3830], the following hash function may be used.
* ハッシュファンク（8ビット）：使用されるハッシュ関数を示します。[RFC3830]ですでに定義されているハッシュ関数に加えて、次のハッシュ関数を使用できます。
Hash func | Value | Hash Length
----------+-------+------------
SHA-256 | 2 | 256 bits
Table 6.12: Hash func (Additions)
表6.12：ハッシュファンク（追加）
The SHA-256 hash function is defined in [FIPS.180-3].
SHA-256ハッシュ関数は[FIPS.180-3]で定義されています。
The RANDR payload uses all the fields from the standard RAND payload (RAND) but expands it with a new field describing the role (the generating entity) of the RAND. The RANDR payload is intended to eliminate ambiguity when a MIKEY message contains several RAND payloads.
RANDRペイロードは、標準のRANDペイロード（RAND）のすべてのフィールドを使用しますが、RANDの役割（生成エンティティ）を説明する新しいフィールドで拡張します。RANDRペイロードは、マイキーメッセージにいくつかのRANDペイロードが含まれている場合、あいまいさを排除することを目的としています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RAND Role ! RAND length ! RAND ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* RAND Role (8 bits): specifies the entity that generated the RAND.
* RANDロール（8ビット）：RANDを生成したエンティティを指定します。
RAND Role | Value
-------------------+------
Initiator (RANDRi) | 1
Responder (RANDRr) | 2
KMS (RANDRkms) | 3
Table 6.13: RAND Role
表6.13：ランドロール
For the key data sub-payload, new types of errors are defined.
主要なデータサブペイロードの場合、新しいタイプのエラーが定義されています。
* Error no (8 bits): indicates the type of error that was encountered.
* エラー番号（8ビット）：遭遇したエラーのタイプを示します。
Error no | Value | Comments
---------------+-------+----------------------------
Invalid TICKET | 14 | Ticket Type not supported
Invalid TPpar | 15 | TP parameters not supported
Table 6.14: Error no (Additions)
表6.14：エラー番号（追加）
Note that the Ticket Policy payload (TP) and the Ticket Payload (TICKET) are two different payloads (having different payload identifiers). However, as they share much of the payload structure, they are described in the same section.
チケットポリシーペイロード（TP）とチケットペイロード（チケット）は2つの異なるペイロード（異なるペイロード識別子を持つ）であることに注意してください。ただし、ペイロード構造の多くを共有すると、同じセクションで説明されています。
The Ticket Policy payload contains a desired Ticket Policy and does not include the Ticket Data length, Ticket Data, Initiator Data length, or Initiator Data fields. The ticket payload contains the granted Ticket Policy as well as Ticket Data (the default ticket type is defined in Appendix A). The Ticket Policy contains information intended for all parties involved whereas the Ticket Data is only intended for the party that resolves the ticket. The Ticket Type provided in the Ticket Data is indicated in the Ticket Policy. When key forking is used (I flag), the Initiator Data authenticates the Initiator.
チケットポリシーのペイロードには、目的のチケットポリシーが含まれており、チケットデータの長さ、チケットデータ、イニシエーターデータの長さ、またはイニシエーターデータフィールドは含まれていません。チケットペイロードには、付与されたチケットポリシーとチケットデータが含まれています（デフォルトのチケットタイプは付録Aで定義されています）。チケットポリシーには、関係するすべての関係者向けの情報が含まれていますが、チケットデータはチケットを解決する当事者のみを対象としています。チケットデータに記載されているチケットの種類は、チケットポリシーに示されています。キーフォークを使用すると（Iフラグ）、イニシエーターデータがイニシエーターを認証します。
Note that the flags are not independent: NOT D implies L, G implies F, NOT G implies H, NOT H implies G, I implies E, K implies D, and M implies F. The F flag SHALL be set to '1' when the I flag (key forking) is set to '1' and a TGK is encoded in the ticket.
フラグは独立していないことに注意してください：dはl、gはfを暗示し、gはgを意味し、gはhを意味します。Iフラグ（キーフォーキング）が「1」に設定され、TGKがチケットにエンコードされると。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Ticket Type ! Subtype !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Version ! PRF Func !D!E!F!G!H!I!J!K!L!M!N!O! Res !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! TP Data length ! TP Data ~
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
! Ticket Data length ! Ticket Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initiator Data length ! Initiator Data (OPTIONAL) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Payload (8 bits): identifies the payload that is added after this payload.
* 次のペイロード（8ビット）：このペイロード後に追加されたペイロードを識別します。
* Ticket Type (16 bits): specifies the Ticket Type used.
* チケットタイプ（16ビット）：使用するチケットタイプを指定します。
Ticket Type | Value | Comments
------------------+-------+---------------------------
MIKEY Base Ticket | 1 | Defined in Appendix A
3GPP Base Ticket | 2 | Used and specified by 3GPP
Table 6.15: Ticket Type
表6.15：チケットの種類
Subtype = 0x01 and Version = 0x01 refers to MIKEY Base Ticket as defined in this document.
subtype = 0x01およびversion = 0x01は、このドキュメントで定義されているMikey Baseチケットを指します。
* Subtype (8 bits): specifies the ticket subtype used.
* サブタイプ（8ビット）：使用するチケットサブタイプを指定します。
* Version (8 bits): specifies the ticket subtype version used.
* バージョン（8ビット）：使用されるチケットサブタイプバージョンを指定します。
* PRF Func (7 bits): specifies the PRF that SHALL be used for key forking.
* PRF FUNC（7ビット）：キーフォークに使用するPRFを指定します。
* D (1 bit): flag to indicate whether the ticket was generated by the KMS ('1') or by the Initiator ('0').
* D（1ビット）：チケットがKMS（ '1'）またはイニシエーター（ '0'）によって生成されたかどうかを示すフラグ。
* E (1 bit): flag to indicate whether the Ticket Resolve exchange is MANDATORY ('1') or if the Responder MAY resolve the ticket ('0').
* e（1ビット）：チケット解決交換が必須である（ '1'）か、レスポンダーがチケットを解決できるか（ '0'）かを示すフラグ。
* F (1 bit): flag to indicate whether the TRANSFER_RESP message SHALL be sent ('1') or if it SHALL NOT be sent ('0').
* f（1ビット）：transf_respメッセージを送信（ '1'）または送信しない（ '0'）かどうかを示すフラグ。
* G (1 bit): flag to indicate whether the Responder SHALL generate RANDRr ('1') or if the Responder SHALL NOT generate RANDRr ('0').
* g（1ビット）：応答者がRandRR（ '1'）を生成するかどうかを示すフラグまたは応答者がRANDRR（ '0'）を生成してはならないかどうかを示します。
* H (1 bit): flag to indicate whether RANDRi SHALL be used when deriving keys from a TGK/GTGK ('1') or if RANDRi SHALL NOT be used ('0').
* H（1ビット）：TGK/GTGK（ '1'）からキーを導出するときにRandriを使用するかどうかを示すフラグまたはRandriを使用しない場合（ '0'）。
* I (1 bit): flag to indicate whether key forking SHALL be used ('1') or if key forking SHALL NOT be used ('0').
* I（1ビット）：キーフォーキングを使用するか（ '1'）かどうかを示すフラグまたはキーフォーキングが使用されない（ '0'）。
* J (1 bit): flag to indicate whether the ticket MAY be reused ('1') and therefore MAY be cached or if it SHALL NOT be reused ('0').
* J（1ビット）：チケットが再利用される可能性があるため、キャッシュされているか、再利用しないか（ '0'）かどうかを示すフラグ。
* K (1 bit): flag to indicate whether the KMS changed the desired Ticket Policy or the desired KEMAC ('1') or if it did not ('0'). In the TP payload, it SHALL be set to '0' by the Initiator and ignored by the KMS.
* k（1ビット）：KMSが目的のチケットポリシーを変更したのか、それとも目的のKemac（ '1'）を変更したのか、それとも（ '0'）がなかったのかを示すフラグ。TPペイロードでは、イニシエーターによって「0」に設定され、KMSによって無視されます。
* L (1 bit): flag to indicate whether the Initiator MAY supply session keys ('1') or if the Initiator SHALL NOT supply session keys ('0').
* L（1ビット）：イニシエーターがセッションキー（ '1'）を供給できるかどうかを示すフラグまたは開始者がセッションキー（ '0'）を供給してはならないかどうかを示します。
* M (1 bit): flag to indicate whether the Responder MAY supply session keys ('1') or if the Responder SHALL NOT supply session keys ('0').
* M（1ビット）：応答者がセッションキー（ '1'）を供給できるかどうかを示すフラグですか、それともレスポンダーがセッションキー（ '0'）を供給しないかどうかを示します。
* N (1 bit): flag to indicate whether an Initiator following this specification can initiate a TRANSFER_INIT message using the ticket ('1') or if additional processing is required ('0'). If the flag is set to '0', the Initiator SHOULD follow the processing in the specification of the received Ticket Type.
* n（1ビット）：この仕様に従ってイニシエーターが、チケット（ '1'）を使用してtransf_initメッセージを開始できるか、追加の処理が必要か（ '0'）かどうかを示すフラグ。フラグが「0」に設定されている場合、イニシエーターは受信したチケットタイプの仕様の処理に従う必要があります。
* O (1 bit): flag to indicate whether a Responder following this specification can process a TRANSFER_INIT message containing the ticket ('1') or if additional processing is required ('0'). If the flag is set to '0', the Responder SHOULD follow the processing in the specification of the received Ticket Type.
* o（1ビット）：この仕様に従ってレスポンダーがチケット（ '1'）を含むtransf_initメッセージを処理できるか、追加の処理が必要か（ '0'）かどうかを示すフラグ。フラグが「0」に設定されている場合、レスポンダーは受信したチケットタイプの仕様の処理に従う必要があります。
* Res (5 bits): reserved for future use.
* res（5ビット）：将来の使用のために予約されています。
* TP Data length (16 bits): length of TP Data (in bytes).
* TPデータ長（16ビット）：TPデータの長さ（バイト単位）。
* TP Data (variable length): The first 8 bits identify the first payload. The rest of TP Data SHALL be constructed of MIKEY payloads. Unexpected payloads in the TP Data SHOULD be ignored.
* TPデータ（変数長）：最初の8ビットは最初のペイロードを識別します。TPデータの残りの部分は、マイキーペイロードで構築されなければなりません。TPデータの予期しないペイロードは無視する必要があります。
TP Data = First Payload, [IDRkms], [IDRi], [TRs], [TRe], [TRr], [KEMAC], {IDRapp}, (IDRr)
TP data = firstペイロード、[idrkms]、[idri]、[trs]、[tre]、[trr]、[kemac]、{idrapp}、（idrr）
IDRkms contains the identity of a KMS that can resolve the ticket.
IDRKMSには、チケットを解決できるKMSの身元が含まれています。
IDRi contains the identity of the peer that requested or created the ticket.
Idriには、チケットを要求または作成したピアの身元が含まれています。
TRs is the start of the validity period. TRs SHALL be interpreted as being in the range 1968-2104 as described in [RFC4330]. An omitted TRs means that the validity period has no defined beginning.
TRSは有効期間の開始です。TRSは、[RFC4330]に記載されているように、1968-2104の範囲にあると解釈されます。省略されたTRSは、有効期間に定義された開始がないことを意味します。
TRe is the end of the validity period. TRe SHALL be interpreted as being in the range 1968-2104 as described in [RFC4330]. An omitted TRe means that the validity period has no defined end.
TREは有効期間の終わりです。TREは、[RFC4330]に記載されているように、1968-2104の範囲にあると解釈されるものとします。省略されたTREは、有効期間に定義された終わりがないことを意味します。
TRr indicates how often rekeying MUST be done. TS Type SHALL be NTP-UTC-32 and the time between two rekeyings SHALL NOT be longer than the number of seconds in the integer part of the timestamp. How the rekeying is done is implementation specific.
TRRは、再キーイングを行う必要がある頻度を示します。TSタイプはNTP-UTC-32でなければならず、2つの再キーイングの間の時間は、タイムスタンプの整数部分の秒数よりも長くはありません。再キーイングの完了方法は実装固有です。
The KEMAC payload may be used to indicate the number of requested keys and specify other key information (key type, key length, and KV (key validity) data). The KEMAC payload SHALL use the NULL encryption algorithm and the NULL authentication algorithm, as a MAC is included in the V payload. The KEMAC is hence constructed as follows:
KEMACペイロードを使用して、要求されたキーの数を示し、他のキー情報（キータイプ、キー長、およびKV（キー有効性）データ）を指定できます。KEMACペイロードは、MACがVペイロードに含まれているため、Null暗号化アルゴリズムとNull認証アルゴリズムを使用するものとします。したがって、Kemacは次のように構築されます。
KEMAC = {TEK|TGK|GTGK}
The Key Data fields SHALL be set to '0' by the Initiator and ignored by the KMS. The KEMAC SHALL NOT be present in the granted Ticket Policy.
キーデータフィールドは、イニシエーターによって「0」に設定され、KMSによって無視されます。KEMACは、付与されたチケットポリシーに存在してはなりません。
IDRapp is an identifier for an authorized application ID. The application IDs are implementation specific. If no IDRapp payloads are supplied, all application IDs are authorized.
idrappは、承認されたアプリケーションIDの識別子です。アプリケーションIDは実装固有です。IDRAPPペイロードが提供されていない場合、すべてのアプリケーションIDが承認されます。
IDRr is the identity of a responder or a group of responders that are authorized to resolve the ticket. If there is more than one responder identity, each responder identity SHALL be included in a separate IDR payload.
IDRRは、チケットの解決を許可されているレスポンダーまたはレスポンダーのグループの身元です。複数のレスポンダーIDがある場合、各レスポンダーIDは別のIDRペイロードに含まれます。
* Ticket Data length (16 bits): the length of the Ticket Data field (in bytes). Not present in the TP payload.
* チケットデータの長さ（16ビット）：チケットデータフィールドの長さ（バイト単位）。TPペイロードには存在しません。
* Ticket Data (variable length): contains the Ticket Data. Not present in the TP payload.
* チケットデータ（変動長）：チケットデータが含まれています。TPペイロードには存在しません。
* Initiator Data length (16 bits): the length of the Initiator Data field (in bytes). Not present in the TP payload.
* イニシエーターデータの長さ（16ビット）：イニシエーターデータフィールドの長さ（バイト単位）。TPペイロードには存在しません。
* Initiator Data (variable length): Not present in the TP payload. SHALL be inserted by the Initiator if and only if key forking is used (I flag). The first 8 bits identifies the first payload. The rest of Initiator Data SHALL be constructed of MIKEY payloads. Unexpected payloads in the Initiator Data SHOULD be ignored.
* イニシエーターデータ（変数長）：TPペイロードには存在しません。キーフォーキングが使用されている場合にのみ、イニシエーターによって挿入されます（Iフラグ）。最初の8ビットは、最初のペイロードを識別します。残りのイニシエーターデータは、マイキーペイロードで構成されているものとします。イニシエーターデータの予期しないペイロードは無視する必要があります。
Initiator Data = First Payload, Vi, Vr
イニシエーターデータ=ファーストペイロード、VI、VR
The Vi payload SHALL be identical to the V payload in the TRANSFER_INIT message.
VIペイロードは、Transfer_initメッセージのVペイロードと同一でなければなりません。
The last payload (Vr) SHALL be a Verification payload where the MAC SHALL cover the entire Initiator Data field except the MAC field itself. The authentication algorithm SHALL be the same as used for the Vi payload. The authentication key (auth_key) SHALL be derived from MPKr (not forked) using the following parameters:
最後のペイロード（VR）は、MACフィールド自体を除くMACがイニシエーターデータフィールド全体をカバーする検証ペイロードでなければなりません。認証アルゴリズムは、VIペイロードに使用されるものと同じでなければなりません。認証キー（auth_key）は、次のパラメーターを使用してMPKR（フォークされていない）から派生します。
inkey: : MPKr inkey_len : bit length of the inkey label : constant || 0xFF || 0xFFFFFFFF || 0x04 outkey_len : desired bit length of the outkey (encr_key, auth_key, salt_key)
inkey ：： mpkr inkey_len：inkeyラベルのビット長：定数||0xff ||0xffffffff ||0x04 outkey_len：outkeyの希望ビット長さ（encr_key、auth_key、salt_key）
The constant depends on the derived key type as defined in Section 4.1.4 of [RFC3830].
定数は、[RFC3830]のセクション4.1.4で定義されている派生キータイプに依存します。
MIKEY messages are not tied to any specific transport protocols. In [RFC4567], extensions for SDP and RTSP to carry MIKEY messages (and therefore MIKEY-TICKET messages) are defined. The messages in the Ticket Transfer exchange (TRANSFER_INIT, TRANSFER_RESP) are preferably included in the session setup signaling (e.g., SIP INVITE and 200 OK). However, it may not be suitable for the MIKEY-TICKET exchanges that do not establish keying material for media sessions (Ticket Request and Ticket Resolve) to be carried in SDP or RTSP. If SDP or RTSP is not used, the transport protocol needs to be defined. In [3GPP.33.328], it is defined how the Ticket Request and Ticket Resolve exchanges are carried over HTTP.
Mikeyメッセージは、特定の輸送プロトコルに関連付けられていません。[RFC4567]では、SDPとRTSPの拡張機能がMikeyメッセージ（したがってMikey-Ticketメッセージ）を運ぶための拡張機能が定義されています。チケット転送交換（Transfer_init、Transfer_resp）のメッセージは、セッションセットアップシグナリング（SIP Inviteや200 OKなど）に含まれることが好ましいです。ただし、SDPまたはRTSPで運ばれるメディアセッション（チケットリクエストとチケットの解決）のキーイング資料を確立しないマイキーチケット交換には適していない場合があります。SDPまたはRTSPを使用していない場合、輸送プロトコルを定義する必要があります。[3GPP.33.328]では、チケットのリクエストとチケットの解決方法がHTTPにどのように運ばれるかが定義されています。
The default setting is that the KMS supplies the session keys (encoded in the ticket). This is not possible if the content is pre-encrypted (e.g., Video on Demand). In such use cases, the key exchange is typically reversed and MAY be carried out as follows. The Initiator sends a ticket without encoded session keys to the Responder in a TRANSFER_INIT message. The Responder has access to the TEKs used to protect the requested content, but may not be streaming the content. The Responder includes the TEK in the TRANSFER_RESP message, which is sent to the Initiator.
デフォルトの設定は、KMSがセッションキー（チケットにエンコードされている）を提供することです。コンテンツが事前に暗号化されている場合（たとえば、ビデオオンデマンド）これは不可能です。このようなユースケースでは、主要な交換は通常逆になり、次のように実行できます。イニシエーターは、Transf_initメッセージでエンコードされたセッションキーなしでレスポンダーにチケットを送信します。レスポンダーは、要求されたコンテンツを保護するために使用されるTEKにアクセスできますが、コンテンツをストリーミングしていない場合があります。レスポンダーには、Transfer_RespメッセージにTekが含まれており、イニシエーターに送信されます。
+---+ +---+
| I | | R |
+---+ +---+
TRANSFER_INIT
---------------------------------------------------------------->
TRANSFER_RESP {KEMAC}
<----------------------------------------------------------------
Figure 6: Distribution of pre-encrypted content
図6：事前に暗号化されたコンテンツの分布
What has been discussed up to now can also be used for group communication. The MIKEY signaling for multi-party sessions can be centralized as illustrated in Figure 7.
これまで議論されていることは、グループコミュニケーションにも使用できます。マルチパーティセッションのマイキーシグナリングは、図7に示すように集中化できます。
+---+ +---+ +---+
| A | | B | | C |
+---+ +---+ +---+
Ticket Transfer
<-------------------------------> Ticket Transfer
<--------------------------------------------------------------->
Figure 7: Centralized signaling around party A
図7：当事者周辺の集中信号a
or decentralized as illustrated in Figure 8.
または図8に示すように分散化されています。
+---+ +---+ +---+
| A | | B | | C |
+---+ +---+ +---+
Ticket Transfer
<-------------------------------> Ticket Transfer
<------------------------------->
Figure 8: Decentralized signaling
図8：分散化シグナル伝達
In the decentralized scenario, the identities of B and C SHALL be used in the second Ticket Transfer exchange. Independent of the how the MIKEY signaling is done, a group key may be used as session key.
分散型シナリオでは、2番目のチケット転送交換でBとCのアイデンティティを使用するものとします。マイキーシグナリングの完了方法とは無関係に、グループキーはセッションキーとして使用できます。
If a group key is used, the group key and session information may be pushed to all group members (similar to [RFC3830]), or distributed when requested (similar to [RFC4738]). If a TGK/GTGK is used as a group key, the same RANDs MUST be used to derive the session keys in all Ticket Transfer exchanges. Also note caveats with ticket reuse in group communication settings as discussed in Section 5.3.
グループキーを使用すると、グループキーとセッションの情報がすべてのグループメンバー（[RFC3830]と同様）にプッシュされるか、要求されたときに分布する（[RFC4738]と同様）。TGK/GTGKがグループキーとして使用される場合、すべてのチケット転送交換でセッションキーを導出するために同じランドを使用する必要があります。また、セクション5.3で説明したように、グループ通信設定でチケットの再利用を伴う警告に注意してください。
When key forking is used, only the user that requested the ticket can initiate a Ticket Transfer exchange using that ticket, see Section 5.3. So if a group key is to be distributed, the MIKEY signaling MUST be centralized to the party that initially requested the ticket, or different tickets needs to be used in each Ticket Transfer exchange and the group key needs to be sent in a KEMAC.
キーフォーキングが使用される場合、チケットを要求したユーザーのみがそのチケットを使用してチケット転送交換を開始できます。セクション5.3を参照してください。したがって、グループキーを配布する場合、マイキーシグナリングを最初にチケットを要求したパーティーに集中化する必要があります。または、各チケット転送交換で異なるチケットを使用する必要があり、グループキーをKEMACで送信する必要があります。
Another consideration is that different users get different session keys if TGKs (encoded in the ticket) are used.
別の考慮事項は、TGK（チケットでエンコード）が使用されている場合、異なるユーザーが異なるセッションキーを取得することです。
A user can in general only be expected to have a trust relation with a single KMS. Different users might therefore use tickets issued by different KMSs using only locally known keys. Thus, if users with trust relations to different KMSs are to be able to establish a secure session with each other, the KMSs involved have to cooperate and there has to be a trust relation between them. The KMSs SHALL be mutually authenticated and signaling between them SHALL be integrity and confidentiality protected. The technical means for the inter-KMS security is however outside the scope of this specification. Under these assumptions, the following approach MAY be used.
一般に、ユーザーは単一のkmとの信頼関係を持つことが期待されることが期待されます。したがって、異なるユーザーは、地元で既知のキーのみを使用して、異なるKMSによって発行されたチケットを使用する場合があります。したがって、異なるKMSとの信頼関係を持つユーザーが互いに安全なセッションを確立できる場合、関係するKMSは協力する必要があり、それらの間に信頼関係が必要です。KMSは相互に認証され、それらの間のシグナルは完全性と保護されているものとします。ただし、KMS間セキュリティの技術的手段は、この仕様の範囲外です。これらの仮定の下では、次のアプローチを使用できます。
+---+ +---+ +-------+ +-------+
| I | | R | | KMS R | | KMS I |
+---+ +---+ +-------+ +-------+
TRANSFER_INIT
--------------------> RESOLVE_INIT
- - - - - - - - - - -> RESOLVE_INIT
- - - - - - - - - - ->
RESOLVE_RESP
RESOLVE_RESP <- - - - - - - - - - -
TRANSFER_RESP < - - - - - - - - - -
<--------------------
Figure 9: Routing of resolve messages
図9：解決メッセージのルーティング
If the Responder cannot directly resolve a ticket, the ticket SHOULD be included in a RESOLVE_INIT message sent to a KMS. If the Responder does not have a shared credential with the KMS that issued the ticket (KMS I) or if the Responder does not know which KMS issued the ticket, the Responder SHOULD send the RESOLVE_INIT message to one of the Responder's trusted KMSs (KMS R). If KMS R did not issue the ticket, KMS R would normally be unable to directly resolve the ticket and must hence ask another KMS to resolve it (typically the issuing KMS).
応答者がチケットを直接解決できない場合、チケットはkmsに送信されたResolve_initメッセージに含める必要があります。Responderがチケットを発行したKMS（KMS I）と共有資格を持っていない場合、またはResponderがどのKMSがチケットを発行したかわからない場合、ResponderはResolve_InitメッセージをResponderの信頼できるKMS（KMS Rに送信する必要があります。）。KMS Rがチケットを発行しなかった場合、KMS Rは通常、チケットを直接解決することができず、したがって別のKMSにそれを解決するように依頼する必要があります（通常、発行KMS）。
The signaling between different KMSs MAY be done with a Ticket Resolve exchange as illustrated in Figure 9. The IDRr and TICKET payloads from the previous RESOLVE_INIT message SHOULD be reused. Note that IDRr cannot be used to look up the pre-shared key/ certificate.
図9に示すように、異なるKMS間のシグナリングは、チケットResolve Exchangeで行うことができます。以前のResolve_initメッセージのIDRRとチケットペイロードは再利用する必要があります。IDRRを使用して、事前に共有キー/証明書を調べることができないことに注意してください。
The Ticket Data (in the TICKET payload) could be a reference to information (keys, etc.) stored by the key management service, it could contain all the information itself, or it could be a combination of the two alternatives. For systems serving many users, it is not ideal to use the reference-only ticket approach as this would force the key management service to keep state of all issued tickets that are still valid. Tickets may carry many different types of information helping to enforce usage policies. The policies may be group policies or per-user policies.
チケットデータ（チケットペイロード内）は、キー管理サービスによって保存されている情報（キーなど）への参照である可能性があります。すべての情報自体を含めるか、2つの選択肢の組み合わせである可能性があります。多くのユーザーにサービスを提供するシステムの場合、参照のみのチケットアプローチを使用することは理想的ではありません。これにより、主要な管理サービスは、まだ有効なすべての発行されたチケットの状態を維持するように強制するためです。チケットには、使用ポリシーの実施に役立つさまざまな種類の情報が搭載される場合があります。ポリシーは、グループポリシーまたはユーザーごとのポリシーです。
Tickets may either be transparent, meaning they can be resolved without contacting the KMS that generated them, or opaque, meaning that the original KMS must be contacted. The ticket information SHOULD typically be integrity protected and certain fields need confidentiality protection, in particular, the keys if explicitly included. Other types of information may also require confidentiality protection due to privacy reasons. In mode 2 (see Section 4.1.1), it may be preferable to include several encrypted ticket protection keys (similar to Secure/Multipurpose Internet Mail Extensions (S/MIME)) as this may allow multiple peers to resolve the ticket.
チケットは透明性がある場合があります。つまり、生成したKMSに連絡することなく解決できるか、元のKMに連絡する必要があることを意味します。チケット情報は通常、整合性保護されている必要があり、特定のフィールドには機密性保護、特に明示的に含まれる場合はキーが必要です。他の種類の情報も、プライバシーの理由により機密保護が必要になる場合があります。モード2（セクション4.1.1を参照）では、いくつかの暗号化されたチケット保護キーを含めることが望ましい場合があります（安全/多目的インターネットメールエクステンション（S/MIME）に似ています）。
The Ticket Data MUST include information so that the resolving party can retrieve an encoded KEMAC. It MUST also be possible to verify the integrity of the TICKET payload. It is RECOMMENDED that future specifications use the recommended payload order and do not add any additional payloads or processing. New Ticket Types SHOULD NOT change the processing for the Responder. If a new Ticket Type requires additional processing, it MUST be indicated in the Ticket Policy (N and O flags). New specifications MUST specify which modes are supported and if any additional security considerations apply.
チケットデータには、解決党がエンコードされたKEMACを取得できるように情報を含める必要があります。また、チケットペイロードの整合性を検証することも可能である必要があります。将来の仕様は、推奨されるペイロード順序を使用し、追加のペイロードや処理を追加しないことをお勧めします。新しいチケットタイプは、レスポンダーの処理を変更しないでください。新しいチケットタイプに追加の処理が必要な場合は、チケットポリシー（NおよびOフラグ）に示される必要があります。新しい仕様では、どのモードがサポートされているかを指定し、追加のセキュリティ上の考慮事項が適用されるかを指定する必要があります。
Unless otherwise stated, the security considerations in [RFC3830] still apply and contain notes on the security properties of the MIKEY protocol, key derivation functions, and other components. As some security properties depend on the specific Ticket Type, only generic security considerations concerning the MIKEY-TICKET framework are discussed.
特に明記しない限り、[RFC3830]のセキュリティ上の考慮事項は、マイキープロトコル、キー派生関数、およびその他のコンポーネントのセキュリティプロパティに関するメモを適用し、含まれています。一部のセキュリティプロパティは特定のチケットタイプに依存するため、Mikey-Ticketフレームワークに関する一般的なセキュリティに関する考慮事項のみが議論されています。
This specification includes a large number of optional features, which adds complexity to the general case. Protocol designers are strongly encouraged to establish strict profiles defining MIKEY-TICKET options (e.g., exchanges or message fields) that SHOULD or MUST be supported. Such profiles should preclude unexpected consequences from compliant implementations with wildly differing option sets.
この仕様には、一般的なケースに複雑さを加える多数のオプション機能が含まれています。プロトコルデザイナーは、サポートする必要がある、またはサポートする必要がある、またはサポートする必要があるマイキーチケットオプション（例：交換またはメッセージフィールド）を定義する厳格なプロファイルを確立することを強くお勧めします。このようなプロファイルは、オプションセットが大きく異なる準拠の実装から予期せぬ結果を排除する必要があります。
In addition to the Ticket Policy, the KMS MAY have its own set of policies (authorized key lengths, algorithms, etc.) that in some way are shared with the peers. The KMS MAY also provide keying material to authorized intermediate nodes performing various network functions (e.g., transcoding services, recording services, conference bridges). The key management service can enforce end-to-end security by only distributing the keys to authorized end-users. As in [RFC3830], the user identities are not confidentiality protected. If user privacy is needed, some kind of Privacy Enhancing Technologies (PET) like anonymous or temporary credentials MAY be used.
チケットポリシーに加えて、KMSには、何らかの形でピアと共有される独自のポリシー（認定キー長、アルゴリズムなど）がある場合があります。KMSは、さまざまなネットワーク関数（たとえば、トランスコーディングサービス、レコーディングサービス、会議ブリッジなど）を実行する許可された中間ノードにキーイング素材を提供する場合があります。キーマネジメントサービスは、承認されたエンドユーザーにキーを配布することにより、エンドツーエンドのセキュリティを実施できます。[RFC3830]のように、ユーザーのアイデンティティは保護されていません。ユーザーのプライバシーが必要な場合は、匿名または一時的な資格情報のような何らかのプライバシー強化テクノロジー（PET）を使用できます。
In the standard MIKEY modes [RFC3830], the keys are generated by the Initiator (or by both peers in the Diffie-Hellman scheme). If a bad PRNG (Pseudorandom Number Generator) is used, this is likely to make any key management protocol sensitive to different kinds of attacks, and MIKEY is no exception. As the choice of the PRNG is implementation specific, the easiest (and often bad) choice is to use the PRNG supplied by the operating system. In MIKEY-TICKET's default mode of operation, the key generation is mostly done by the KMS, which can be assumed to be less likely to use a bad random number generator. All keys (including keys used to protect the ticket) MUST have adequate strength/length, i.e., 128 bits or more.
標準のMikeyモード[RFC3830]では、キーはイニシエーターによって（またはDiffie-Hellmanスキームの両方のピアによって生成されます）。悪いPRNG（擬似ランダム数ジェネレーター）が使用されている場合、これはさまざまな種類の攻撃に敏感になる重要な管理プロトコルを作る可能性が高く、Mikeyも例外ではありません。PRNGの選択は実装固有であるため、最も簡単な（そしてしばしば悪い）選択は、オペレーティングシステムから提供されるPRNGを使用することです。Mikey-Ticketのデフォルトの動作モードでは、主要生成は主にKMSによって行われます。これは、悪い乱数ジェネレーターを使用する可能性が低いと想定できます。すべてのキー（チケットを保護するために使用されるキーを含む）には、適切な強度/長さ、つまり128ビット以上が必要です。
The use of random nonces (RANDs) in the key derivation is of utmost importance to counter offline pre-computation attacks and other generic attacks. A key of length n, using RANDs of length r, has effective key entropy of (n + r) / 2 against a birthday attack. Therefore, the sum of the lengths of RANDRi and RANDRr MUST at least be equal to the size of the longest pre-shared key/envelope key/MPK/ TGK/GTGK, RANDRkms MUST at least be as long as the longest MPKr/TGK, and the RAND in the MIKEY base ticket MUST at least be as long as the longest of TPK and MPK.
主要な導出におけるランダムノンセ（RAND）の使用は、オフラインの事前コンピューション攻撃やその他の一般的な攻撃に対抗するために最も重要です。長さrのランドを使用した長さnのキーは、誕生日攻撃に対して（n r） / 2の効果的なキーエントロピーを持っています。したがって、RANDRIとRANDRRの長さの合計は、少なくとも最も長い株式キー/エンベロープキー/MPK/TGK/GTGKのサイズに等しくなければなりません。RandRKMSは、少なくとも最長のMPKR/TGKと同じくらい長くなければなりません。そして、マイキーベースのチケットのランドは、少なくともTPKとMPKの最長と同じくらい長くなければなりません。
Note that the CSB Updating messages reuse the old RANDs. This means that the total effective key entropy (relative to pre-computation attacks) for k consecutive key updates, assuming the TGKs are each n bits long, is still no more than n bits. In other words, the time and memory needed by an attacker to get all k n-bit keys are proportional to 2^n. While this might seem like a defect, this is in practice (for all reasonable values of k) not better than brute force, which on average requires k * 2^(n-1) work (even if different RANDs would be used). A birthday attack would only require 2^(n/2) work, but would need access to 2^(n/2) sessions protected with equally many different keys using a single pair of RANDs. This is, for typical values of n, clearly totally infeasible. The success probability of such an attack can be controlled by limiting the number of updates correspondingly. As stated in [RFC3830], the fact that more than one key can be compromised in a single attack is inherent to any solution using secret- or public-key algorithms. An attacker always gets access to all the exchanged keys by doing an exhaustive search on the pre-shared key/envelope key/MPK. This requires 2^m work, where m is the effective size of the key.
メッセージを更新するメッセージは、古いランドを再利用することに注意してください。これは、Kの連続したキーアップデートの総有効なキーエントロピー（プレコンピューション攻撃と比較）は、TGKが各Nビットの長さであると仮定して、まだNビットにすぎないことを意味します。言い換えれば、攻撃者がすべてのk nビットキーを取得するために必要な時間とメモリは2^nに比例します。これは欠陥のように思えるかもしれませんが、これは実際には（kのすべての合理的な値について）ブルートフォースよりも優れていません。平均してK * 2^（n-1）作業が必要です（異なるランドが使用されていても）。誕生日の攻撃では、2^（n/2）作業のみが必要ですが、単一のランドを使用して同様に多くの異なるキーで保護された2^（n/2）セッションへのアクセスが必要です。これは、nの典型的な値の場合、明らかに完全に実行不可能です。このような攻撃の成功確率は、それに応じて更新の数を制限することで制御できます。[RFC3830]に記載されているように、単一の攻撃で複数のキーを損なう可能性があるという事実は、秘密または公開アルゴリズムを使用した任意のソリューションに固有のものです。攻撃者は、事前に共有されたキー/エンベロープキー/MPKを徹底的に検索することにより、常にすべての交換されたキーにアクセスできます。これには2^mの作業が必要です。ここで、mはキーの有効サイズです。
As the Responder MAY generate a RAND, the Ticket Transfer exchange can provide mutual freshness guarantee for all derived keys.
レスポンダーがRANDを生成する可能性があるため、チケット移籍交換はすべての派生キーに相互の新鮮さの保証を提供できます。
The new algorithms PRF-HMAC-SHA-256, AES-CM-256, and HMAC-SHA-256-256 use 256-bit keys and offer a higher security level than the previously defined algorithms. If one of the 256-bit algorithms are supported, the other two algorithms SHALL also be supported. The 256-bit algorithms SHOULD be used together, and they SHALL NOT be mixed with algorithms using key sizes less than 256 bits. If session keys (TEK/TGK/GTGK) longer than 128 bits are used, 128-bit algorithms SHALL NOT be used.
新しいアルゴリズムPRF-HMAC-SHA-256、AES-CM-256、およびHMAC-SHA-256-256は、256ビットキーを使用し、以前に定義されたアルゴリズムよりも高いセキュリティレベルを提供します。256ビットアルゴリズムの1つがサポートされている場合、他の2つのアルゴリズムもサポートされます。256ビットアルゴリズムは一緒に使用する必要があり、256ビット未満のキーサイズを使用してアルゴリズムと混合してはなりません。セッションキー（TEK/TGK/GTGK）が128ビットより長い場合は、128ビットアルゴリズムを使用してはなりません。
In some situations, the TRANSFER_INIT message may be delivered to multiple endpoints. For example, when a Responder is registered on several devices (e.g., mobile phone, fixed phone, and computer) or when an invite is being made to addresses of the type IT-support@example.com, a group of users where only one is supposed to answer. The Initiator may not even always know exactly who the authorized group members are. To prevent all forms of eavesdropping, entities other than the endpoint that answers MUST NOT get access to the session keys.
状況によっては、Transf_initメッセージが複数のエンドポイントに配信される場合があります。たとえば、レスポンダーが複数のデバイス（携帯電話、固定電話、コンピューターなど）に登録されている場合、またはタイプit-support@example.comのアドレスに招待されている場合、1つだけのユーザーのグループであるユーザーのグループである場合答えることになっています。イニシエーターは、認可されたグループメンバーが誰であるかを常に正確に知っているわけではありません。あらゆる形態の盗聴を防ぐために、回答がセッションキーにアクセスしてはならないエンドポイント以外のエンティティ。
When key forking is not used, keys are accessible by everyone that can resolve the ticket. When key forking is used, some keys (MPKr and TGKs encoded in the ticket) are modified, making them cryptographically unique for each responder targeted by the forking. As only the Initiator and the KMS have access to the master TGKs, it is infeasible for anyone else to derive the session keys.
キーフォークを使用しない場合、チケットを解決できるすべての人がキーにアクセスできます。キーフォーキングを使用すると、一部のキー（チケットにエンコードされたMPKRとTGK）が変更され、フォーキングが標的とする各応答者に対して暗号化にユニークになります。イニシエーターとKMSのみがマスターTGKにアクセスできるため、他の誰かがセッションキーを導き出すことは不可能です。
When key forking is used, some keys (MPKi and TEKs and GTGK encoded in the ticket) are still accessible by everyone that can resolve the ticket and should be used with this in mind. This also concerns session keys transferred in a KEMAC in the first TRANSFER_INIT (as they are protected with MPKi).
キーフォークを使用すると、一部のキー（チケットにエンコードされたMPKIとTEKSおよびGTGK）は、チケットを解決できるすべての人がまだアクセスでき、これを念頭に置いて使用する必要があります。これは、最初のTransfer_initのKemacで転送されたセッションキー（MPKIで保護されているため）にも関係しています。
This protocol is resistant to denial-of-service attacks against the KMS in the sense that it does not construct any state (at the key management protocol level) before it has authenticated the Initiator or Responder. Since the Responder, in general, cannot verify the validity of a TRANSFER_INIT message without first contacting the KMS, denial of service may be launched against the Responder and/or the KMS via the Responder. Typical prevention methods such as rate-limiting and ACL (Access Control List) capability SHOULD therefore be implemented in the KMS as well as the clients. If something in the signaling is suspicious, the Responder SHOULD abort before attempting a RESOLVE_INIT with the KMS. The types and amount of prevention needed depends on how critical the system is and may vary depending on the Ticket Type.
このプロトコルは、イニシエーターまたはレスポンダーを認証する前に（主要な管理プロトコルレベルで）状態を構築しないという意味で、KMSに対するサービス拒否攻撃に耐性があります。対応者は一般に、最初にKMSに連絡しない限り、転送_initメッセージの有効性を検証できないため、レスポンダーおよび/またはレスポンダーを介してKMSに対してサービスの拒否を開始することができます。したがって、レート制限やACL（アクセス制御リスト）機能などの典型的な予防方法は、クライアントだけでなくKMSに実装する必要があります。信号の何かが疑わしい場合、kmsでResolve_initを試みる前に、レスポンダーが中止する必要があります。必要な予防の種類と量は、システムがどれほど重要であるかによって異なり、チケットの種類によって異なる場合があります。
In a replay attack, an attacker may intercept and later retransmit the whole or part of a MIKEY message, attempting to trick the receiver (Responder or KMS) into undesired operations, e.g., leading to a lack of key freshness. MIKEY-TICKET implements several mechanisms to prevent and detect such attacks. Timestamps together with a replay cache efficiently stop the replay of entire MIKEY messages. Parts of the received messages (or their hashes) can be saved in the replay cache until their timestamp is outdated. To prevent replay attacks, the sender's (Initiator or Responder) and the receiver's (Responder or KMS) identity is always (explicitly or implicitly) included in the MAC/Signature calculation.
リプレイ攻撃では、攻撃者が傍受し、後でマイキーメッセージの全部または一部を再送信し、レシーバー（レスポンダーまたはKMS）を不足していない操作にだまそうとする場合があります。マイキーチケットは、そのような攻撃を防止および検出するためのいくつかのメカニズムを実装しています。タイムスタンプとリプレイキャッシュと一緒にマイキーメッセージ全体のリプレイを効率的に停止します。受信したメッセージ（またはハッシュ）の一部は、タイムスタンプが時代遅れになるまで、リプレイキャッシュに保存できます。リプレイ攻撃を防ぐために、送信者（イニシエーターまたはレスポンダー）とレシーバー（レスポンダーまたはKMS）のアイデンティティは、常に（明示的または暗黙的に）Mac/署名計算に含まれます。
An attacker may also attempt to replay a ticket by inserting it into a new MIKEY message. A possible scenario is that Alice and Bob first communicate based on a ticket, which an attacker Mallory intercepts. Later, Mallory (acting as herself) invites Bob by inserting the ticket into her own TRANSFER_INIT message. If key forking is used, such replays will always be detected when Bob has resolved the ticket. If key forking is not used, such replays will be detected unless Mallory has knowledge of the MPKi. And if Mallory has knowledge of the MPKi (i.e., she is authorized to resolve the ticket) and key forking is not used, there is no attack. For the reasons explained above, it is RECOMMENDED to use key forking.
攻撃者は、チケットを新しいマイキーメッセージに挿入して、チケットを再生しようとする場合もあります。考えられるシナリオは、アリスとボブが最初にチケットに基づいて通信し、攻撃者のマロリーが傍受することです。その後、マロリー（自分のように行動する）は、チケットを自分の転送メッセージに挿入することでボブを招待します。キーフォーキングが使用されている場合、ボブがチケットを解決したとき、そのようなリプレイは常に検出されます。キーフォーキングが使用されない場合、MalloryがMPKIの知識を持っていない限り、そのようなリプレイは検出されます。そして、MalloryがMPKIの知識を持っている（つまり、彼女はチケットを解決することを許可されている）、キーフォーキングが使用されない場合、攻撃はありません。上記の理由により、キーフォークを使用することをお勧めします。
In a group scenario, only authorized group members must have access to the keys. In some situation, the communication may be initiated by the Initiator using a group identity and the Initiator may not even know exactly who the authorized group members are. Moreover, group membership may change over time due to leaves/joins. In such a situation, it is foremost the responsibility of the KMS to reject ticket resolution requests from unauthorized responders, implying that the KMS needs to be able to map an individual's identity (carried in the RESOLVE_INIT message) to group membership (where the group identity is carried in the ticket).
グループシナリオでは、承認されたグループメンバーのみがキーにアクセスできる必要があります。ある状況では、グループIDを使用してイニシエーターによってコミュニケーションが開始される場合があり、イニシエーターは、認可されたグループメンバーが誰であるかを正確に知らない場合があります。さらに、グループメンバーシップは、葉/結合のために時間とともに変化する場合があります。このような状況では、不正なレスポンダーからのチケット解決要求を拒否することはKMSの責任であり、KMSがグループメンバーシップ（グループIDのグループID）に個人の身元（Resolve_initメッセージに携帯）をマッピングできる必要があることを暗示しています。チケットに入れられます）。
As noted, reuse of tickets, which bypasses the KMS, is NOT RECOMMENDED when the Initiator is not fully ensured about group membership status.
前述のように、KMSをバイパスするチケットの再利用は、イニシエーターがグループメンバーシップステータスについて完全に保証されていない場合、推奨されません。
The authors would like to thank Fredrik Ahlqvist, Rolf Blom, Yi Cheng, Lakshminath Dondeti, Vesa Lehtovirta, Fredrik Lindholm, Mats Naslund, Karl Norrman, Oscar Ohlsson, Brian Rosenberg, Bengt Sahlin, Wei Yinxing, and Zhu Yunwen for their support and valuable comments.
著者は、フレドリック・アフルクヴィスト、ロルフ・ブロム、イー・チェン、ラクシュミナス・ドンデティ、ヴェサ・レトヴィルタ、フレドリック・リンドホルム、マット・ナスルンド、カール・ノルマン、オスカー・オハルソン、ブライアン・ローゼンバーグ、ベンテ・サーリン、ウェイ・インキンのサポートに感謝します。コメント。
This document defines several new values for the namespaces Data Type, Next Payload, PRF func, CS ID map type, Encr alg, MAC alg, TS Type, ID Type, Hash func, Error no, and Key Data Type defined in [RFC3830]. The following IANA assignments were added to the MIKEY Payload registry (in parentheses is a reference to the table containing the registered values):
このドキュメントでは、名前空間データ型、次のペイロード、PRF FUNC、CS IDマップタイプ、ENCR ALG、MAC ALG、TSタイプ、IDタイプ、ハッシュFUNC、エラーNO、[RFC3830]で定義されたキーデータ型のいくつかの新しい値を定義します。。次のIANAの割り当てがマイキーペイロードレジストリに追加されました（括弧内には、登録値を含むテーブルへの参照です）：
o Data Type (see Table 6.1)
o データ型（表6.1を参照）
o Next Payload (see Table 6.2) o PRF func (see Table 6.3)
o 次のペイロード（表6.2を参照）O PRF FUNC（表6.3を参照）
o CS ID map type (see Table 6.4)
o CS IDマップタイプ（表6.4を参照）
o Encr alg (see Table 6.5)
o encr alg（表6.5を参照）
o MAC alg (see Table 6.6)
o Mac Alg（表6.6を参照）
o TS Type (see Table 6.7)
o TSタイプ（表6.7を参照）
o ID Type (see Table 6.9)
o IDタイプ（表6.9を参照）
o Hash func (see Table 6.11)
o ハッシュファン（表6.11を参照）
o Error no (see Table 6.13)
o エラー番号（表6.13を参照）
o Key Data Type (see Table 6.14)
o キーデータタイプ（表6.14を参照）
The TR payload defines an 8-bit TS Role field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of a TS Role name and its associated value. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are Reserved for Private Use, and the values 0 and 255 are Reserved according to [RFC5226]. The initial contents of the registry are as follows:
TRペイロードは、IANAが作成した8ビットTSロールフィールドを定義し、マイキーペイロードレジストリに新しい名前空間を維持します。割り当ては、TSロール名とそれに関連する値で構成されています。範囲1〜239の値は、必要な仕様のプロセス、範囲240-254の値が私的使用のために予約され、値0と255は[RFC5226]に従って予約されていることを承認する必要があります。レジストリの最初の内容は次のとおりです。
Value TS Role
------- ------------------------------
0 Reserved
1 Time of issue (TRi)
2 Start of validity period (TRs)
3 End of validity period (TRe)
4 Rekeying interval (TRr)
5-239 Unassigned
240-254 Reserved for Private Use
255 Reserved
The IDR payload defines an 8-bit ID Role field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of an ID Role name and its associated value. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are Reserved for Private Use, and the values 0 and 255 are Reserved according to [RFC5226]. The initial contents of the registry are as follows:
IDRペイロードは、IANAが作成した8ビットIDロールフィールドを定義し、マイキーペイロードレジストリに新しい名前空間を維持します。割り当ては、IDロール名とそれに関連する値で構成されています。範囲1〜239の値は、必要な仕様のプロセス、範囲240-254の値が私的使用のために予約され、値0と255は[RFC5226]に従って予約されていることを承認する必要があります。レジストリの最初の内容は次のとおりです。
Value ID Role
------- -----------------------
0 Reserved
1 Initiator (IDRi)
2 Responder (IDRr)
3 KMS (IDRkms)
4 Pre-Shared Key (IDRpsk)
5 Application (IDRapp)
6-239 Unassigned
240-254 Reserved for Private Use
255 Reserved
The RANDR payload defines an 8-bit RAND Role field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of a RAND Role name and its associated value. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are Reserved for Private Use, and the values 0 and 255 are Reserved according to [RFC5226]. The initial contents of the registry are as follows:
RANDRペイロードは、IANAが作成した8ビットRANDロールフィールドを定義し、マイキーペイロードレジストリに新しい名前空間を維持します。割り当ては、RANDロール名とそれに関連する値で構成されています。範囲1〜239の値は、必要な仕様のプロセス、範囲240-254の値が私的使用のために予約され、値0と255は[RFC5226]に従って予約されていることを承認する必要があります。レジストリの最初の内容は次のとおりです。
Value RAND Role
------- ------------------
0 Reserved
1 Initiator (RANDRi)
2 Responder (RANDRr)
3 KMS (RANDRkms)
4-239 Unassigned
240-254 Reserved for Private Use
255 Reserved
The TP/TICKET payload defines a 16-bit Ticket Type field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of a Ticket Type name and its associated value. Values in the range 1-61439 SHOULD be approved by the process of Specification Required, values in the range 61440- 65534 are Reserved for Private Use, and the values 0 and 65535 are Reserved according to [RFC5226]. The initial contents of the registry are as follows:
TP/チケットペイロードは、IANAが作成した16ビットチケットタイプのフィールドを定義し、Mikey Payloadレジストリに新しい名前空間を維持します。割り当ては、チケットタイプ名とそれに関連する値で構成されています。範囲1-61439の値は、必要な仕様のプロセス、範囲61440〜65534の値が個人使用のために予約され、値0と65535は[RFC5226]に従って予約されています。レジストリの最初の内容は次のとおりです。
Value Ticket Type
----------- -----------------
0 Reserved
1 MIKEY base ticket
2 3GPP base ticket
3-61439 Unassigned
61440-65534 Reserved for Private Use
65535 Reserved
[FIPS.180-3] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008, <http://csrc.nist.gov/publications/fips/ fips180-3/fips180-3_final.pdf>.
[FIPS.180-3]国立標準技術研究所、「Secure Hash Standard（SHS）」、Fips Pub 180-3、2008年10月、<http://csrc.nist.gov/publications/fips/ fips180-3/fips180-3_final.pdf>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330] Mills、D。、「IPv4、IPv6およびOSI用のSimple Network Time Protocol（SNTP）バージョン4」、RFC 4330、2006年1月。
[RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.
[RFC4563] Carrara、E.、Lehtovirta、V。、およびK. Norrman、「マルチメディアインターネットキーイング（Mikey）の一般的な拡張ペイロードのキーID情報タイプ」、RFC 4563、2006年6月。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567] Arkko、J.、Lindholm、F.、Naslund、M.、Norrman、K。、およびE. Carrara、「セッション説明プロトコル（SDP）およびリアルタイムストリーミングプロトコル（RTSP）のキー管理拡張機能」、RFC4567、2006年7月。
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006.
[RFC4738] Ignjatic、D.、Dondeti、L.、Audet、F。、およびP. Lin、「Mikey-RSA-R：マルチメディアインターネットキーイング（Mikey）のキー分布の追加モード」、RFC 4738、2006年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[3GPP.33.328] 3GPP, "IP Multimedia Subsystem (IMS) media plane security", 3GPP TS 33.328 9.3.0, December 2010.
[3GPP.33.328] 3GPP、「IPマルチメディアサブシステム（IMS）メディアプレーンセキュリティ」、3GPP TS 33.328 9.3.0、2010年12月。
[Otway-Rees] Otway, D., and O. Rees, "Efficient and Timely Mutual Authentication", ACM SIGOPS Operating Systems Review v.21 n.1, p.8-10, January 1987.
[Otway-Rees] Otway、D。、およびO. Rees、「効率的かつタイムリーな相互認証」、ACM Sigopsオペレーティングシステムレビューv.21 N.1、p.8-10、1987年1月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650] Euchner、M。、「マルチメディアインターネットキーイング（Mikey）のためのHMAC-Authenticated Diffie-Hellman」、RFC 4650、2006年9月。
[RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions", RFC 5197, June 2008.
[RFC5197] Fries、S。and D. Ignjatic、「さまざまなマルチメディアインターネットキーイング（Mikey）モードと拡張機能の適用性について」、RFC 5197、2008年6月。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009.
[RFC5479] Wing、D.、Fries、S.、Tschofenig、H。、およびF. Audet、「メディアセキュリティ管理プロトコルの要件と分析」、RFC 5479、2009年4月。
The MIKEY base ticket MAY be used in any of the modes described in Section 4.1.1. The Ticket Data SHALL be constructed of MIKEY payloads and SHALL be protected by a MAC based on a pre-shared Ticket Protection Key (TPK). The parties that shares the TPK depends on the mode. Unexpected payloads in the Ticket Data SHOULD be ignored.
マイキーベースチケットは、セクション4.1.1で説明されているモードのいずれかで使用できます。チケットデータはマイキーペイロードで構築され、事前共有チケット保護キー（TPK）に基づいてMACによって保護されます。TPKを共有する当事者は、モードによって異なります。チケットデータの予期しないペイロードは無視する必要があります。
Ticket Data = THDR, T, RAND, KEMAC, [IDRpsk], V
チケットデータ= thdr、t、rand、kemac、[idrpsk]、v
The Ticket Data MUST always begin with a Ticket Header payload (THDR). The ticket header is a new payload type; for the definition, see Appendix A.3.
チケットデータは、常にチケットヘッダーペイロード（THDR）から開始する必要があります。チケットヘッダーは新しいペイロードタイプです。定義については、付録A.3を参照してください。
T is a timestamp containing the time of issue or a counter. It MAY be used in the IV (Initialization Vector) formation (e.g., Section 4.2.3 of [RFC3830]).
Tは、問題またはカウンターを含むタイムスタンプです。IV（初期化ベクトル）形成（[RFC3830]のセクション4.2.3など）で使用できます。
RAND is used as input to the key derivation function when keys are derived from the TPK and the MPK (see Appendices A.2.1 and A.2.2).
RANDは、キーがTPKおよびMPKから派生した場合、キー導出関数への入力として使用されます（付録A.2.1およびA.2.2を参照）。
The KEMAC payload SHALL use the NULL authentication algorithm, as a MAC is included in the V payload. The encryption key (encr_key) and salting key (salt_key) SHALL be derived from the TPK (see Appendix A.2.1). Depending on the encryption algorithm, the salting key be used in the IV creation (see Section 4.2.3 of [RFC3830]). If CSB ID is needed in the IV creation it SHALL be set to '0xFFFFFFFF'. The KEMAC is hence constructed as follows:
KEMACペイロードは、MacがVペイロードに含まれているため、Null認証アルゴリズムを使用するものとします。暗号化キー（ENCR_KEY）と塩漬けキー（SALT_KEY）は、TPKから派生している必要があります（付録A.2.1を参照）。暗号化アルゴリズムに応じて、IV作成で塩漬けキーを使用します（[RFC3830]のセクション4.2.3を参照）。IV作成でCSB IDが必要な場合は、「0xffffffff」に設定されます。したがって、Kemacは次のように構築されます。
KEMAC = E(encr_key, MPK || {TEK|TGK|GTGK})
MPKi and MPKr are derived from the MPK as defined in Appendix A.2.2.
MPKIとMPKRは、付録A.2.2で定義されているMPKから派生しています。
IDRpsk contains an identifier that enables the KMS/Responder to retrieve the TPK. It MAY be omitted when the TPK can be retrieved anyhow.
IDRPSKには、KMS/レスポンダーがTPKを取得できるようにする識別子が含まれています。とにかくTPKを取得できる場合は、省略される場合があります。
The last payload SHALL be a Verification payload (V) where the authentication key (auth_key) is derived from the TPK. The MAC SHALL be calculated over the entire TICKET payload except the Next Payload field (in the TICKET payload), the Initiator Data length field, the Initiator Data field, and the MAC field itself.
最後のペイロードは、認証キー（auth_key）がTPKから導出される検証ペイロード（v）でなければなりません。MACは、次のペイロードフィールド（チケットペイロード内）、イニシエーターデータ長、イニシエーターデータフィールド、およびMACフィールド自体を除き、チケットのペイロード全体にわたって計算されます。
The labels in the key derivations SHALL NOT include entire RAND payloads, only the fields RAND length and RAND from the corresponding payload.
キー派生のラベルには、RANDペイロード全体を含めるものではなく、対応するペイロードからのFields RANDの長さとRANDのみが含まれます。
In the following, we describe how keying material is derived from a TPK. The key derivation method SHALL be executed using the PRF indicated in the Ticket Policy. The parameters for the PRF are:
以下では、キーイング素材がTPKからどのように導出されるかについて説明します。キー派生法は、チケットポリシーに示されているPRFを使用して実行されるものとします。PRFのパラメーターは次のとおりです。
inkey: : TPK inkey_len : bit length of the inkey label : constant || 0xFF || 0xFFFFFFFF || 0x05 || length RAND || RAND outkey_len : desired bit length of the outkey (encr_key, auth_key, salt_key)
inkey ：： tpk inkey_len：inkeyラベルのビット長：定数||0xff ||0xffffffff ||0x05 ||長さのrand ||rand outkey_len：outkeyの希望ビット長（encr_key、auth_key、salt_key）
Length RAND is the length of RAND in bytes as an 8-bit unsigned integer. The constants are as defined in Section 4.1.4 of [RFC3830]. The key derivation and its dependencies on Ticket Data contents when AES-CM is used are illustrated in Figure 10. The key derivation is done by the party that creates the ticket (KMS or Initiator) and by the party that resolves the ticket (KMS or Responder). The encryption key and the IV are used to encrypt the KEMAC.
長さのRANDは、8ビットの署名されていない整数としてバイトのランドの長さです。定数は、[RFC3830]のセクション4.1.4で定義されています。AES-CMが使用されるときのチケットデータコンテンツへのキー派生とその依存関係を図10に示します。キー派生は、チケット（KMSまたはイニシエーター）を作成するパーティー（KMSまたはKMSまたは解決）によって行われます。対応者）。暗号化キーとIVを使用して、KEMACを暗号化します。
----- auth_key ------
----- TPK | |----------------------->| AUTH |
| TPK |----------->| | encr_key ------
----- | PRF |--------------------+ |
^ +-->| | salt_key | |
: | | |----------------+ | |
: | ----- | | |
: | v | |
identify : RAND | TS value ---- | | MAC
: | +------------>| IV | | |
: | | ---- | |
: | | IV | | |
: | | v v v
Ticket +---+----+---+--+---+---+-+-+------------+-------+---+---+
Data | IDRpsk |...| RAND |...| T |............| KEMAC |...| V |
+--------+---+------+---+---+------------+-------+---+---+
Figure 10: Deriving keys from a TPK
図10：TPKからキーの導出
In the following, we describe how MPKi and MPKr are derived from the MPK in the KEMAC payload. The key derivation method SHALL be executed using the PRF indicated in the Ticket Policy. The parameters for the PRF are:
以下では、MPKIとMPKRがKEMACペイロードのMPKに由来する方法について説明します。キー派生法は、チケットポリシーに示されているPRFを使用して実行されるものとします。PRFのパラメーターは次のとおりです。
inkey: : MPK inkey_len : bit length of the inkey label : constant || 0xFF || 0xFFFFFFFF || 0x06 || length RAND || RAND outkey_len : desired bit length of the outkey (MPKi, MPKr) SHALL be equal to inkey_len
inkey ：： mpk inkey_len：inkeyラベルのビット長：定数||0xff ||0xffffffff ||0x06 ||長さのrand ||rand outkey_len：outkeyの希望ビット長（mpki、mpkr）はinkey_lenに等しくなります
Length RAND is the length of RAND in bytes as an 8-bit unsigned integer. The constant depends on the derived key type as summarized below.
長さのRANDは、8ビットの署名されていない整数としてバイトのランドの長さです。定数は、以下に要約されているように、導出されたキータイプに依存します。
Derived key | Constant
------------+-----------
MPKi | 0x220E99A2
MPKr | 0x1F4D675B
Table A.1: Constants for MPK key derivation
表A.1：MPKキー派生の定数
The constants are taken from the decimal digits of e as described in [RFC3830].
定数は、[RFC3830]に記載されているように、Eの小数桁から取得されます。
The ticket header payload contains an indicator of the next payload as well as implementation-specific data.
チケットヘッダーのペイロードには、次のペイロードのインジケーターと実装固有のデータが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! THDR Data length ! THDR Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Payload (8 bits): identifies the payload that is added after this payload.
* 次のペイロード（8ビット）：このペイロード後に追加されたペイロードを識別します。
* THDR Data length (16 bits): the length of the THDR Data field (in bytes).
* THDRデータの長さ（16ビット）：THDRデータフィールドの長さ（バイト単位）。
* THDR Data (variable length): implementation specific data that SHOULD be ignored if it is not expected.
* THDRデータ（変数長）：予想されない場合に無視する必要がある特定のデータを実装します。
MIKEY-TICKET can be used to define a Ticket Type compatible with [RFC3830] or any other half-round-trip key management protocol. The Initiator requests and gets a ticket from the KMS where the Ticket Data is a [RFC3830] message protected with a pre-shared key (KMS-Responder) or with the Responder's certificate. The Ticket Data is then sent to the Responder according to [RFC3830]. In this way, the Initiator can communicate with a Responder that only supports [RFC3830] and with whom the Initiator do not have any shared credentials.
Mikey-Ticketを使用して、[RFC3830]またはその他の半ラウンドキー管理プロトコルと互換性のあるチケットタイプを定義できます。イニシエーターは、チケットデータが[RFC3830]メッセージが事前に共有キー（KMS応答）またはレスポンダーの証明書で保護されている[RFC3830]メッセージであるKMSからチケットを要求します。チケットデータは、[RFC3830]に従ってレスポンダーに送信されます。このようにして、イニシエーターは[RFC3830]のみをサポートし、イニシエーターが共有資格情報を持っていないレスポンダーと通信できます。
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
REQUEST_INIT
-------------------------------->
REQUEST_RESP
<--------------------------------
3830 MIKEY
---------------------------------------------------------------->
Figure 11: Compatibility mode
図11：互換性モード
Authors' Addresses
著者のアドレス
John Mattsson Ericsson AB SE-164 80 Stockholm Sweden
ジョン・マッツソン・エリクソンAB SE-164 80ストックホルム・スウェーデン
Phone: +46 10 71 43 501
EMail: john.mattsson@ericsson.com
Tian Tian ZTE Corporation 4F, RD Building 2, Zijinghua Road Yuhuatai District, Nanjing 210012 P.R. China
Tian Tian Zte Corporation 4F、RD Building 2、Zijinghua Road Yuhuatai District、Nanjing 210012 P.R. China
Phone: +86-025-5287-7867
EMail: tian.tian1@zte.com.cn