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)
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）仕様は、リアルタイム・アプリケーションのための鍵管理方式が記載されています。この文書では、我々は、現在定義されてMIKEYモードは、キーの集中管理サービスを中心に構築された展開シナリオに対処するには不十分であることに注意してください。このような展開への関心が増加しています。したがって、そのようなシナリオではうまく機能新しい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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
鍵管理システムは、いずれかの信頼できるキー管理サービス（KMS）の交渉や仲間の間で直接やり取り（例えば、ディフィー・ヘルマン・ベースのスキーム）、ユーザーの資格情報の事前配布（共有秘密/証明書）、または可用性に基づいています。マルチメディアインターネットキーイング（MIKEY）仕様[RFC3830]及びその拡張[RFC4650]、[RFC4738]に記載のモードは、すべての最初の二つの選択肢の変異体です。
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の下に行く新しいマイキーモードのセットを紹介します。新しいモードは、キーを識別し、配信するために使用されるケルベロス[RFC4120]と同様のチケット概念を、サポートしています。マイキー-TICKETの高レベルの概要本明細書で定義されるイニシエータが、KMSからキーとチケットを要求してレスポンダにチケットを送信していることです。チケットは、キー、または包まれたキーへの参照が含まれています。 Responderは、適切なキーを返す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チケットは、主に第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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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チケット設けられたキー（複数可）によって固定されることを意図通信セッション。
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からキーとチケットを要求するためイニシエータによって使用されるExchange。
Ticket Transfer: Exchange used to transfer the ticket as well as session information from the Initiator to the Responder.
チケット譲渡：レスポンダにイニシエータからチケットだけでなく、セッション情報を転送するために使用されるExchange。
Ticket Resolve: Exchange used by the Responder to request the KMS to return the keys encoded in a ticket.
チケット解決：チケットにエンコードされたキーを返すようにKMSを要求するためにレスポンダで使用されるExchange。
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
鍵kエンティティXのK」のPKX公開鍵とPのE（K、P）暗号二股鍵k [P] Pは、PのP（P）は、1つまたは複数の出現の任意{P} 0回以上の繰り返しであります
|| Concatenation | OR (selection operator)
||連結| OR（選択演算子）
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：暗号化セッションバンドルIMS：IPマルチメディアサブシステムGTGK：グループTGK HMAC：ハッシュ・ベースのメッセージ認証コードKMS：キーマネージメントサービスMAC：メッセージ認証コードMIKEY：マルチメディアインターネットキーイングNSPS：国家安全保障と公安MKI：マスターキー識別子MPK：MIKEY保護キーNTP：ネットワークタイムプロトコルPET：プライバシー強化技術PK：公開鍵PRF：擬似ランダム関数のPRNG：擬似乱数ジェネレータPSK：事前共有キーRTSP：リアルタイムストリーミングプロトコルSDP：セッション記述プロトコルSHA：セキュアハッシュアルゴリズムSIP：セッション開始プロトコルSPI：セキュリティパラメータインデックスSRTP：リアルタイム転送プロトコルTEKセキュア：交通暗号化キーTGK：TEK世代キー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
CERTx：エンティティのx CHASHの証明書：共通ヘッダのペイロードID：アイデンティティペイロードIDRx：エンティティのx IDRpskための識別子：事前共有鍵IDRappための識別子：アプリケーション/サービスKEMACの識別子：キーデータトランスポートペイロード証明書のハッシュはHDRを使用しました
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
PKE：暗号化されたエンベロープキーRAND：RANDペイロードRANDRx：エンティティによって生成されるランダム値X SIGNx：セキュリティポリシーペイロードT：タイムスタンプペイロード試してみてください：チケットヘッダーペイロードTICKET：役割インジケータのy THDRとタイムスタンプペイロードエンティティXの秘密鍵のSPを使用して作成した署名：チケットペイロードTP：チケットポリシーペイロードV：検証ペイロード
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がセット内にある場合（イニシエータ、レスポンダ、KMS）およびyは集合{I、S、E、R}である（問題の時間、時刻、終了時刻、リキー間隔を開始）{iが、R、KMS}。
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ペイロードは[RFC3830]に、（認証タグを運ぶ）VペイロードおよびHDRペイロードにおけるVフラグ（両方が定義されていることを第6注で定義されてはいるかどうかを示す、または応答メッセージ）が期待されていません。
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]で定義された公開鍵暗号方式は、ユーザーの資格情報の事前分布に基づいたシステムの例です。ディフィー・ヘルマン法[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].
いくつかの状況では、要求は、複数のエンドポイントに配信することができます。エンドポイントは、単一のユーザー（例えば、携帯電話、固定電話、およびコンピュータ）が所有する複数のデバイス、または複数のユーザーであってもよい（例えば、IT-support@example.com、一方だけが答えることになっているユーザーのグループ） 。以下では、「フォーク」という用語はすべて、このような例を記述するために使用されます。複数のエンドポイントへの配信の一例は、フォークとSIP [RFC3261]に再標的化されます。盗聴の任意のフォームを防ぐために、答えるだけのエンドポイントは、セッションキーへのアクセスを取得する必要があります。素朴なアプリケーション[RFC3830]すべてのエンドポイントが、それはフォークに来るとき、すべてのエンドポイントがセッションキーへのアクセスを得るよう、セキュリティで保護されていない同じ事前共有鍵/秘密鍵を共有しています。イニシエータは、セッション開始時に使用する事前共有鍵/証明書を知らないと逆に、ユーザごとのユニークな事前共有鍵/証明書を持つことは、フォークとのより根本的な問題が発生します。 SIP-シグナリングメディア保護が[RFC5479]及び[RFC5197]に記載されている異なるMIKEYモードの適用に記載されています。
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.
多数のユーザーにサービスを提供するセキュリティシステムでは、キー管理サービスに基づくソリューションは、多くの場合、好ましいです。代わりに、このようなサービスでは、必要なときに、ユーザーは、このような資格情報を要求することができますよう、直接保護された通信のためにピア間でセキュリティアソシエーションを確立するために用いることができる資格情報を事前に配布する必要はありません。多くのアプリケーションでは、例えば、国家安全保障と公安（NSPS）、制御組織は、鍵の使用にポリシーを適用したいと考えています。それはそれが簡単に一元的ポリシーを適用することができますよう、信頼できる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に基づくシステムでは、ピアが他のピアの資格情報を取得することを可能にするシグナリングメカニズムが必要です。そのようなシグナリング・スキームを実装するための便利な方法は、キーを特定して送達するためにケルベロス[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が応答者でも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.
チケットベースのシステムの使用はまた、エンドツーエンドの保護されたコンテンツには現在オフラインユーザーの遅延配信のためのキーの取り扱いに役立つかもしれません。このようなシナリオは、応答者がキーへのアクセスを取得するには、開始剤と接触しに頼ることはできないとして、ピア間の直接オンラインの交渉のいくつかのタイプ（例えば、ディフィー・ヘルマンベースのスキーム）に基づいており、すべての鍵管理方式を除外する。
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つのピア間で単一の（または半）の往復から成ります。それは三人の者（イニシエータ、レスポンダ、およびKMS）を含む最大3件の異なるラウンドトリップ（チケット要求、チケット譲渡、およびチケットの解決）で構成されてMIKEY-TICKETは、これらのモードとは異なります。往復とメッセージの順序の数は変更になる場合がありますので、MIKEY-TICKETは、すべてのチケットコンセプトを中心、実際にモードのセットの一般名です。第三者、KMSは、MIKEY交換の一部ではなく、まったくその結果、安全なメディアセッションでのみ関与しています。チケット要求とチケット解決の交換は自分でチケット譲渡交換やないと組み合わせて使用することを意図しています。図1において、完全な三往復MIKEYチケットモードのためのシグナリングが示されています。
+---+ +-----+ +---+
| 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）との安全なメディアセッションを確立することを望んでいます。イニシエータとレスポンダは、任意の資格情報を共有することはありません。代わりに、彼らは彼らの両方を持っているか、または共有の資格情報を確立することが可能なサードパーティ、KMSを、信頼しています。これらの事前に確立された信頼関係は、信頼モデルが図2に示されていると仮定IおよびR.ザ間のセキュリティアソシエーションを確立するために使用されます。
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よりなお、複数KMSSは、例えば、イニシエータ用とレスポンダのための1つに関与している可能性があります。これは、セクション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メッセージは、セッション情報を含む（例えば、許可された応答者の識別情報）とである[RFC3830に事前共有鍵と公開鍵暗号化モードに事前共有キーまたは署名によって（類似に基づいて、MACによって保護保全]）。要求が許可されている場合は、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).
イニシエータは、次のレスポンダに送信されるTRANSFER_INITメッセージにチケットを含みます。 TRANSFER_INITメッセージがチケットにエンコードさMPK（MIKEY保護キー）に基づいてMACによって保護されています。 Responderがチケットポリシーおよびセッションセキュリティポリシーが許容見つけた場合、ResponderはKMSにチケットを転送します。これは、チケットにエンコードされたキーを返すようにKMSを要求するRESOLVE_INITメッセージ、で行われます。 RESOLVE_INITメッセージが（レスポンダとKMS間）または署名によって事前共有鍵に基づいてMACによって保護されています。チケット解決交換は（チケットポリシーに依存する）オプションで、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は、その後の検証として、イニシエータにTRANSFER_RESPメッセージを送信します。 TRANSFER_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.
上述のユースケースとシグナリングは、完全な三往復モードであるが、他のモードは、セクション4.1.1を参照できます。プリ暗号化されたコンテンツは、グループ通信は、セクション9で説明され、そして異なるKMSS間のシグナリングは、別のユースケースは、付録Bに記載されている第10章に記載されている、セクション8に記載されています
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を参照）のセッション鍵は、イニシエータまたはレスポンダ（に由来するキーで別KEMACで送信保護によって供給されてもよいです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つの交換から成ります。チケットはチケットポリシーと同様にチケットのデータで構成されています。チケットデータのみがチケットを解決するパーティーのために意図されたのに対し、チケットポリシーは、すべての関係者を対象とした情報が含まれています。チケットデータは、鍵管理サービスによって格納された情報（鍵など）を参照することができ、それはすべての情報自体を含むことができ、またはそれは二つの選択肢の組み合わせであってもよいです。チケットデータの形式は、チケットポリシーに合図チケットの種類によって異なります。 MIKEYベースチケットと呼ばれるデフォルトのチケットの種類に対応したチケットデータは、付録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チケットは、[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).
チケットの種類やチケットポリシーに応じて、取引所の一部は、イニシエータとレスポンダの両方を持っているに、チケットの保護はKMSによってのみ知られているキーに基づいている場合は、図3を参照して、すべてで使用されるオプションのかないかもしれません解決/リクエストにKMSを連絡券（モード1）。チケットを保護するために使用されるキーは、KMSとレスポンダの間で共有されている場合はResponderがKMS（モード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の間で共有されている場合は、チケット要求の交換は、イニシエータが（KMSからの支援なしでチケットを作成することができるように、（オトウェイ-Reesのプロトコル[オトウェイ-リース]と同様）を省略することができますモード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.
チケットと対応するキーは、他の方法でイニシエータにKMSから配信された場合にモード1及び2において、チケット要求の交換を省略することができます。チケットが再利用することができるように加えて、単一のチケット要求交換は、いくつかのチケット譲渡交換が続いてもよい、（セクション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からキーとチケットを要求するためイニシエータによって使用されます。要求は、チケットを保護するためのセッションを記述する情報（例えば、参加者のIDなど）が含まれています。フルラウンドトリップがチケットを受け取るためにイニシエータために必要です。最初のメッセージはrequest_initは二つの変形に入っています。最初の変異体は、[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].
第二の変異体は、[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にイニシエータのアイデンティティを確認しなければならないので、それは、事前共有キーまたは署名によって基づくMACによって保護保全されなければなりません。応答メッセージREQUEST_RESPは、二つの変異体について同じであるとは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において、CSB ID（暗号化セッションバンドルID）は、[RFC3830]のように割り当てられます。 Vフラグが「1」に設定しなければなりませんが、応答が必須であるようにKMSによって無視されます。暗号化セッション（CSS）を取り扱わないように、#CSは「0」に設定しなければならなくて、[RFC4563]で定義されるようにCS IDマップタイプは、「空のマップ」でなければなりません。
IDRi contains the identity of the Initiator. This identity SHOULD be included in the granted Ticket Policy.
IDRIは、イニシエータのアイデンティティを含んでいます。このIDは、付与されたチケットポリシーに含まれるべきです。
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は単一のIDを持っていることを期待することができたときにそれが出て残してもよいです。
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（キー派生仕様のセクション5.1.2を参照）によって共有事前共有キーから導出される検証ペイロード（V）でなければなりません。 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と証明書CERTIが含まれるべきであるが、KMSは、他のいくつかの方法で証明書を取得することが期待できるとき、彼らは取り残されるかもしれません。証明書チェーンを提供する場合、チェーン内の各証明書は、別個CERTペイロードに含まれるべきです。イニシエータの証明書が最初に来なければなりません。それぞれの次の証明書は直接それに先行するものを証明する必要があります。
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 = E（PKkms、env_key）：PKEは暗号化されたエンベロープキーが含まれています。これは、KMSの公開鍵（PKkms）を使用して暗号化されています。 KMSは、いくつかの公開鍵を持っている場合、イニシエータはCHASHペイロードに使用するキーを示すことができます。
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は（正確な定義についてはセクション5.5を参照）イニシエータの署名鍵を使用して、全体REQUEST_INIT_PKメッセージをカバーする署名です。
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タイムスタンプのタイプのいずれかが使用される場合、KMSは、クロック同期のために使用することができる、（[RFC3830]とは異なり）、新鮮なタイムスタンプ値を生成しなければなりません。 COUNTERタイムスタンプ型は（[RFC3830]のセクション6.6を参照）が使用される場合、タイムスタンプ値は、はrequest_initメッセージ内の1つに等しくてもよいです。
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.
TICKETペイロードは、（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
MACは、Vペイロードに含まれるようKEMACペイロードは、NULL認証アルゴリズムを使用しなければなりません。 、はrequest_initメッセージのタイプに応じて事前共有キーまたはエンベロープキーのいずれかがencr_key（及びsalt_key）を導出するために使用されます。暗号化アルゴリズムによっては、塩漬けキー（[RFC3830]を参照）IVに入ることがあります。 request_initメッセージ内のTPのペイロードがない場合
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が含まれている、KMSのデフォルトKEMACは、単一TGKを含めることをお勧めします。 KEMACは、チケット譲渡交換でメッセージを保護するために、事前共有キーとして使用MPKi MPK（MIKEY保護キー）を、含まなければなりません。 （チケットポリシーによって決定される）に使用されるキーフォーク（セクション5.1.1を参照）は、第2のMPK、MPKr、KEMACに含めなければならない場合。次いで、MPKiはTRANSFER_INITメッセージを保護するために使用されるものとMPKrはTRANSFER_RESPメッセージを検証するために使用されなければなりません。次のようにKEMACは、従って構成されています。
KEMAC = E(encr_key, MPKi || [MPKr] || {TEK|TGK|GTGK})
KEMAC = E（encr_key、PKI || [PKR] || {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メッセージの種類に応じて、いずれかの事前共有キーまたはエンベロープキーが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が使用されます。セッションキーもTICKETペイロードにエンコードされますが、いくつかのユースケースで、彼らは別のKEMACペイロードに送信する必要があります（セクション8を参照）されています。セッション情報は、（[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.
TRANSFER_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において、CSB ID（暗号化セッションバンドルID）は、[RFC3830]のように割り当てられます。 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は省略することができ、そしてResponderが単一のIDを持っていることが期待できる場合IDRrが取り残されるかもしれません。
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ペイロードは、それがencr_keyは常にMPKi由来ため、チケットを解決する権限をすべてのレスポンダからアクセスされていることを唯一の違いは、（5.2節を参照）後にCSBアップデートで送信されたかのように同じように扱われています。イニシエータは、コンテンツおよび特定の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（キー派生仕様のセクション5.1.2を参照）から誘導される検証ペイロード（V）でなければなりません。 MACは全体TRANSFER_INITメッセージだけでなく、関係者のアイデンティティ（正確な定義については、セクション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.
イニシエータとレスポンダは、任意の事前共有鍵を持っていないので、チケットが解決される前に、レスポンダは、メッセージの正当性をチェックすることはできません。 Responderはしかし、チケットポリシーとセキュリティポリシーの両方が許容されていることをチェックしなければなりません。そうでない場合は、ResponderはKMSと接触せずに却下します。これは、初期のResponderが、それが接続を受け付けません手元の情報から結論付けることができたときに、シグナリング、不要なKMSを回避するための仕組みを拒否しています。チケットが解決された後、TRANSFER_INITメッセージの構文解析は継続します。 TRANSFER_INITメッセージに予期しないペイロードが無視されるべきです。 5.4節で説明したようにエラーが処理されます。チケットポリシーでのFフラグが設定されている場合、ResponderはTRANSFER_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」に設定し、イニシエータによって無視されなければなりません。各暗号化セッションは正確に一つのセキュリティポリシーが示しているように、ResponderはCS IDマップの情報を更新するものとします。レスポンダは、イニシエータがセッションデータおよびSPIを供給しなかった各暗号化セッションのセッションデータ（少なくともためのSRTP）およびSPIを提供しなければなりません。必要であれば、レスポンダはイニシエータが提供するセッション・データおよびSPIを更新することができます。 Responderが暗号化セッションを追加する場合は、#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タイムスタンプのタイプのいずれかが使用される場合、レスポンダは、（[RFC3830]とは異なり）、新鮮なタイムスタンプ値を生成しなければなりません。 COUNTERタイムスタンプ型は（[RFC3830]のセクション6.6を参照）が使用される場合、タイムスタンプ値はTRANSFER_INITメッセージ内の1つに等しくてもよいです。
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
レスポンダはRESOLVE_RESPメッセージにIDRrペイロードを受信した場合、同じIDはTRANSFER_RESPメッセージにIDRrペイロードで送らなければなりません。でIDRrペイロードで送らアイデンティティ
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).
TRANSFER_RESPメッセージ（例えば、user1@example.com）TRANSFER_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メッセージにRANDRkmsペイロードを受信した場合、同じRANDはTRANSFER_RESPメッセージにRANDRkmsペイロードで送らなければなりません。
The Responder MAY provide additional Security Policy payloads. The Responder SHOULD NOT resend SP payloads, which the Initiator supplied.
Responderは、追加のセキュリティポリシーのペイロードを提供することができます。レスポンダは、イニシエータが付属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.
それは、セクション5.2を参照してください、後でCSBアップデートで送信されたかのようにKEMACペイロードが正確に処理されるものとします。 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は全体TRANSFER_RESPメッセージだけでなく、TRANSFER_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メッセージを送信することができます。 TRANSFER_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は、フルラウンドトリップが鍵を受け取るために、レスポンダに要求されるセクション10を参照してください、もともとチケットを発行した同じKMSをする必要はありません。チケット解決交換は（チケットポリシーに依存する）オプションで、ResponderがKMSからの支援なしでチケットを解決できない場合にのみ使用してください。最初のメッセージRESOLVE_INITは、二つの変種（使用は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].
第二の変異体は、[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は、二つの変異体について同じであり、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フラグ）を使用した場合、レスポンダは、要求されたか、チケットを作成したピアはまたTRANSFER_INITメッセージを送ったことが保証されます。 Responderは、それが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（暗号化セッションバンドルID）は、[RFC3830]のように割り当てられます。 Vフラグが「1」に設定しなければなりませんが、応答が必須であるようにKMSによって無視されます。暗号化セッションは取り扱わないように、#CSは「0」に設定しなければならなくて、[RFC4563]で定義されるようにCS IDマップタイプは、「空のマップ」でなければなりません。
IDRkms SHOULD be included, but it MAY be left out when it can be expected that the KMS has a single identity.
IDRkmsが含まれるべきであるが、KMSは単一のIDを持っていることを期待することができたときにそれが出て残してもよいです。
The TICKET payload contains the Ticket Policy and Ticket Data that the Responder wants to have resolved.
TICKETペイロードは、レスポンダが解決しているしたいとチケットポリシーとチケットのデータが含まれています。
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は、他のいくつかの方法で証明書を取得することが期待できるとき、彼らは取り残されるかもしれません。証明書チェーンを提供する場合、チェーン内の各証明書は、別個CERTペイロードに含まれるべきです。レスポンダの証明書が最初に来なければなりません。それぞれの次の証明書は直接それに先行するものを証明する必要があります。
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 = E（PKkms、env_key）：PKEは暗号化されたエンベロープキーが含まれています。それはPKkmsを使用して暗号化されます。 KMSは、いくつかの公開鍵を持っている場合は、ResponderはCHASHペイロードに使用するキーを示すことができます。
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は（正確な定義についてはセクション5.5を参照）レスポンダの署名キーを使用して、全体RESOLVE_INIT_PKメッセージをカバーする署名です。
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もTICKETペイロード内のイニシエータデータフィールドの整合性を検証しなければなりません。 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タイムスタンプのタイプのいずれかが使用される場合、KMSは、クロック同期のために使用することができる、（[RFC3830]とは異なり）、新鮮なタイムスタンプ値を生成しなければなりません。 COUNTERタイムスタンプ型は（[RFC3830]のセクション6.6を参照）が使用される場合、タイムスタンプ値はRESOLVE_INITメッセージ内の1つに等しくてもよいです。
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:
MACは、Vペイロードに含まれるようKEMACペイロードは、NULL認証アルゴリズムを使用しなければなりません。 RESOLVE_INITメッセージ、のいずれかで事前共有キーまたはエンベロープキーがencr_key（およびsalt_key）を導出するために使用されるものの種類に応じ。暗号化アルゴリズムによっては、塩漬けキー（[RFC3830]を参照）IVに入ることがあります。 KEMACは、チケット譲渡交換でメッセージを保護するために事前共有キーとして使用MPK（MPKi）を含まなければなりません。次のようにKEMACは、従って構成されています。
KEMAC = E(encr_key, MPKi || [MPKr'] || {TEK|TGK|GTGK})
KEMAC = E（encr_key、PKI || [PKR「] || {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.
（チケットポリシーでIフラグによって決定される）に使用されるキーフォーク（セクション5.1.1を参照）、第二MPK（MPKr '）はKEMACに含めなければならない場合。その後、MPKiはTRANSFER_INITメッセージを確認するために使用されるものとしMPKr」TRANSFER_RESPメッセージを保護するために使用しなければなりません。 KMSもMPKrとTGKsをforkものとします。フォークのキーを導出するために使用される修飾子はIDRrが答えてRANDRkmsは、KMSによって生成された新鮮な（擬似）ランダムなバイト列であるエンドポイントのアイデンティティであるIDRrとRANDRkmsペイロードに含めなければなりません。それはチケットにエンコードされたアイデンティティと一致するようにKMSがレスポンダのIDを調整することができるという理由があります。
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メッセージの種類に応じて、いずれかの事前共有キーまたはエンベロープキーが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が受信したメッセージの整合性を検証することができますし、メッセージを正しく解析することができた場合は、ResponderはMPKiとTRANSFER_INITメッセージがKMSから受信確かめなければなりません。キーフォークが使用される場合、レスポンダはまたTRANSFER_INITメッセージにおけるVペイロードにMACフィールドは、TICKETペイロードにおけるイニシエータデータフィールドにおける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.
チケット要求とチケット解決交換のすべてのメッセージのために、MIKEYメッセージを保護するために使用されるキーは、事前共有キーまたはエンベロープキーから導出されます。暗号化セッションを取り扱わないように、さらに鍵材料（すなわち、の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.
チケット譲渡交換では、MIKEYメッセージを保護するために使用されるキーは、MPKから派生しています。キーフォークを使用する場合は、KMSとイニシエータは、修飾に基づいてMPKrとTGKs（チケットにエンコードされた）をフォークものとし、異なるMPKs（MPKiとMPKr '）TRANSFER_INITとTRANSFER_RESPメッセージを保護するために使用しなければなりません。また、Responderはキー鮮度保証レスポンダ与えるために使用されるRANDを生成してもよいです。
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メッセージの内容に依存関係が示さKEMACがKEMACがイニシエータとレスポンダにKMSから送信された図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有する場合のTRANSFER_RESPメッセージの内容に依存関係が示さKEMACがKEMACがイニシエータにKMSから送信された図5に示されています。 MODは修飾（IDRr、RANDRkms）です。フォークキーを生成する2つのキー導出は、イニシエータとKMSによって行われ、残りの2つのキー導出は、イニシエータとレスポンダによって行われます。 TRANSFER_INITメッセージからランダム値RANDRiはAUTH_KEYの導出への入力として使用され、TEKの導出への入力として使用することができるが、これは図から省略されています。 TRANSFER_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ペイロード、フィールドのみ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及びTGKs（チケットに符号化された）が二股ことSHALL。 TEKとGTGKs（グループTGKs）が、しかし、フォークされないものとします。このキーフォークはチケットポリシーに示されているKMSとPRF（擬似ランダム関数）を使用して、イニシエータによって行われます。 PRFのためのパラメータは次のとおりINKEY：MPKr又はTGK inkey_len：INKEYラベルのビット長：定数|| 0xFFを|| 0xFFFFFFFFの|| 0x00の||長さIDデータ|| IDデータ||長RANDRkms || outkey_len RANDRkms：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:
この導出はMIKEYメッセージを保護するために使用されるキーを形成するために使用されます。チケット要求とチケット解決の交換については、MIKEYメッセージを保護するために使用されるキーは、事前共有キーまたは封筒キーから導出されています。チケット譲渡交換のために、キーはMPKから派生しています。キーフォークを使用する場合は、異なるMPKs（MPKiとMPKr '）はTRANSFER_INITとTRANSFER_RESPメッセージを保護するために使用しなければなりません。最初のメッセージは、次のパラメータを使用して派生キーで保護されなければなりません。
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：事前共有鍵、エンベロープキー、または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は、チケット解決交換を保護するために使用される鍵の導出およびチケットポリシーがTRANSFER_RESPメッセージ（Gフラグ）に存在しなければならないと判断した場合TRANSFER_RESPを保護するために使用されるキーの導出に含めなければなりません。長RANDRiは8ビットの符号なし整数としてバイト単位RANDRiの長さであり、長さRANDRrは8ビットの符号なし整数としてバイト単位RANDRrの長さです。 RANDRiが省略された場合、長さRANDRiは0でなければならないとRANDRrが省略された場合、長さRANDRrはRANDRiと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マップ情報フィールドで与えられます。チケットポリシーは、それが（Hフラグ）を使用しなければならないと判断した場合RANDRiを含めなければなりません。チケットポリシーは、それがTRANSFER_RESPメッセージ（Gフラグ）に存在しなければならないと判断した場合RANDRrを含めなければなりません。長RANDRiは8ビットの符号なし整数としてバイト単位RANDRiの長さであり、長さRANDRrは8ビットの符号なし整数としてバイト単位RANDRrの長さです。 RANDRi又はRANDRrが省略された場合、対応する長さRANDRiとRANDRrの少なくとも一方を使用しなければならないことは0注意しなければなりません。
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チケットは、例えば、CSB（暗号化セッションバンドル）を更新し、新しいTEK / TGK / GTGKを輸送したり、新しい暗号化セッションを追加する手段を提供します。 TEKの有効期限が切れる前に、または新しい暗号セッションが必要な場合にCSBの更新は、例えば、再びチケット譲渡交換を実行することによって行われます。 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ペイロード）は初期の交換のように扱われます。 TRANSFER_INITメッセージにVフラグは、応答メッセージが期待されているかどうかを示すために使用されなければなりません。それらは特定のユースケースで必要とされない限り、最初の交換で提供された、このようなRANDRi、RANDRr、RANDRkms、チケットなどの静的ペイロードが含まれるべきではありません。新ランズまたはチケットが含まれてはいけません。新しいランズを使用してはならないという理由は、いくつかのTGKsが使用されている場合、ピアは各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ペイロードは含まれないもの。 TRANSFER_RESPメッセージに、セッション鍵は、各暗号化セッションのために提供されなければなりません。 MACは、Vペイロードに含まれるようKEMACは、NULL認証アルゴリズムを使用しなければなりません。 encr_key（及びsalt_key）は、MPK（MPKi又はMPKr '）に由来するものとします。暗号化アルゴリズムによっては、塩漬けキー（[RFC3830]を参照）IVに入ることがあります。新しい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.
前のチケット譲渡交換に使用されてきたチケットを再利用する場合、新しいチケット譲渡交換が実行されます。新しい交換は、新しいCSB ID、新しいタイムスタンプ、および新しいランズ（RANDRi、RANDRr）を使用する必要があります。 Responderが前にチケットを解決した場合は、Responderは再びチケットを解決する必要はありません。その場合には、同一の改質剤（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、TGKs）へのアクセス権を持っています。このため、誰もチケットを使用してチケット譲渡交換を開始することはできません。
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}（イニシエータ、レスポンダ、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]
エラーメッセージ= 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.
エラーメッセージは、バージョン、PRFのFUNC、およびCSB IDにHDRペイロードのフィールドは、エラーが発生したメッセージの対応するフィールドと同じでなければなりません。 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タイムスタンプの種類のいずれかが使用されている場合は、新鮮なタイムスタンプ値を使用しなければなりません。 COUNTERタイムスタンプ型は（[RFC3830]のセクション6.6を参照）が使用される場合、タイムスタンプ値は、エラーが発生したメッセージ内の1つに等しくてもよいです。
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メッセージをカバーします。最初のメッセージについては、当事者の身元（全体ではないペイロード）を直接検証MAC /署名の計算でMIKEYメッセージに従わなければなりません。 TRANSFER_INITメッセージに、MACは、チケットペイロードにおけるイニシエータデータ長とイニシエータのデータフィールドをカバーしないもの。転送Exchangeで、TRANSFER_RESPでIdentity_r（例えば、user1@example.com）はTRANSFER_INITに現れる（例えば、IT-support@example.com）と異なってもよいことに留意されたいです。応答メッセージの場合は、（MAC /署名フィールドを含む）全体の最初のメッセージは直接検証MAC /署名の計算にMIKEYメッセージを（彼らは最初のメッセージの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、およびTICKETペイロードを説明します。他のペイロード、[RFC3830]に比べのみ追加や変更のために記載されています。他のMIKEYペイロードの詳細については、[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更新（セクション5.2を参照）に使用TRANSFER_INITメッセージを除くすべてのメッセージに無視しなければなりません。
* 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.
HMAC-SHA-256、その違いが[RFC3830]のセクション4.1.2に記載したように、新しいPRF（セクション6.2を参照）構造でなければならない代わりに、HMAC-SHA-1を使用しなければならないと値256の代わりに使用しなければなりません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ビット）：暗号化セッションのために使用されるセキュリティプロトコルを定義します。許容値は、（[RFC3830]のセクション6.10を参照）SPペイロード内Protのタイプフィールドに対して定義されたものです。
* 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の場合、提案されたポリシーの一つは、応答メッセージに選択しなければなりません。 （例えば、グループ通信では、第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およびSEQフィールドが設けられているかどうかを示すために使用される（「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.
*配列（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 ALG（付加）
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.
新しい認証アルゴリズムは、[FIPS.180-3] SHA-256と一緒にハッシュベースのメッセージ認証コード（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保護キー（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タイムスタンプに埋められます）。
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の役割は、アイデンティティそのものの意味を説明しています。 IDRペイロードはMIKEYメッセージは、いくつかのアイデンティティペイロードが含まれている場合、あいまいさを排除することを意図しています。 IDRペイロードはすべてMIKEYチケットメッセージに代えて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.
*ハッシュFUNC（8ビット）：使用されるハッシュ関数を示しています。すでに[RFC3830]で定義されたハッシュ関数の他に、次のハッシュ関数を使用することができます。
Hash func | Value | Hash Length
----------+-------+------------
SHA-256 | 2 | 256 bits
Table 6.12: Hash func (Additions)
表6.12：ハッシュFUNC（追加）
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ペイロードはMIKEYメッセージがいくつかの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：RAND役割
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を意味NOT、GはFを意味し、NOT GはHを意味し、NOT HはGを意味し、IはEを意味し、KはDを意味し、Mは、F.ザFフラグが '1' に設定しなければならない意味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.
この文書で定義されているサブタイプ= 0×01と版= 0x01ではMIKEYベースチケットを指します。
* 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ビット）：TRANSFER_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（「0」）を生成しないものとした場合レスポンダはRANDRr（「1」）を生成したり、ものとするかどうかを示すフラグ。
* 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ビット）：（「1」）TGK / GTGKから鍵を導出する際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ビット）：チケット（「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ビット）：それは（「0」）していない場合は、KMS（「1」）の所望のチケットポリシーまたは所望KEMACを変更かどうかを示すフラグ。 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」）又は追加の処理が必要な場合（「0」）を使用してTRANSFER_INITメッセージを開始することができるかどうかを示します。フラグが「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ビット）：フラグはこの仕様を以下のレスポンダがチケットを含むTRANSFER_INITメッセージを処理できるかどうかを示す（「1」）または追加の処理が必要な場合（「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データの残りの部分はMIKEYペイロードの構造でなければなりません。 TPデータに予期しないペイロードは無視されるべきです。
TP Data = First Payload, [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であると解釈されます。省略したTR有効期間が全く定義され始めていないことを意味します。
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 rekeyingsの間の時間は、タイムスタンプの整数部の秒数よりも長くしてはなりません。どのように再入力が行われていることは、実装固有のものです。
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（キー有効）データ）を指定するために使用することができます。 MACは、Vペイロードに含まれるようKEMACペイロードは、NULL暗号化アルゴリズムおよびNULL認証アルゴリズムを使用しなければなりません。次のようにKEMACは、従って構成されています。
KEMAC = {TEK|TGK|GTGK}
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は、応答やチケットを解決するために許可された応答者のグループのアイデンティティです。複数のレスポンダのアイデンティティが存在する場合、各レスポンダのアイデンティティは、別個の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ビットは、最初のペイロードを識別する。イニシエータのデータの残りの部分はMIKEYペイロードの構造でなければなりません。イニシエータのデータに予期しないペイロードは無視されるべきです。
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]で、MIKEYメッセージ（したがってMIKEYチケットメッセージ）を運ぶSDPとRTSPのための拡張が定義されています。チケット譲渡交換におけるメッセージ（TRANSFER_INIT、TRANSFER_RESP）は、好ましくは（例えば、SIP INVITEを200 OK）、セッション設定シグナリングに含まれています。しかし、メディアセッションのための鍵材料（チケット要求とチケット解決）SDPまたはRTSPで搬送されることを確立していないMIKEYチケット交換に適しないかもしれません。 SDPまたはRTSPを使用しない場合、トランスポート・プロトコルが定義される必要があります。チケット要求とチケット解決交換がHTTPを介して搬送されている方法[3GPP.33.328]において、それが定義されています。
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は（チケットにエンコードされた）セッションキーを提供することです。コンテンツは（オンデマンド例えば、ビデオ）事前に暗号化されている場合、これは不可能です。このようなユースケースでは、キー交換は、典型的に反転され、次のように行うことができます。イニシエータはTRANSFER_INITメッセージでレスポンダにエンコードされたセッションキーなしでチケットを送信します。 Responderは要求されたコンテンツを保護するために使用の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に示すように、マルチパーティセッションのMIKEYシグナリングが集中することができます。
+---+ +---+ +---+
| 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.
分散シナリオでは、B及びCのアイデンティティは、第二のチケット譲渡交換に使用しなければなりません。 MIKEYシグナリングがどのように行われるかとは無関係に、グループ鍵をセッション鍵として使用することができます。
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.
グループ鍵が使用される場合に要求された場合、グループ鍵とセッション情報は、（[RFC4738]と同様）（[RFC3830]と同様に）すべてのグループメンバーにプッシュ、または分散させることができます。 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を参照してください、そのチケットを使用してチケット譲渡交換を開始することができます。グループキーを配布するのであれば、MIKEYシグナリングは当初、チケットを要求した当事者、または別のチケットに集中しなければならない各チケット譲渡交換に使用する必要があり、グループキーがKEMACに送信する必要があります。
Another consideration is that different users get different session keys if TGKs (encoded in the ticket) are used.
もう1つの考慮事項は、（チケットでエンコード）TGKsが使用されている場合は、別のユーザーが異なるセッションキーを取得することです。
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.
ユーザーは、一般的に、単一のKMSとの信頼関係を持つことが期待できます。異なるユーザはそのためローカルでのみ知られているキーを使用して異なるKMSSによって発行されたチケットを使用する場合があります。異なるKMSSへの信頼関係を持つユーザーが相互に安全なセッションを確立することができるようになっている場合はこのように、関与KMSSは協力しなければならないと、それらの間の信頼関係がなければなりません。 KMSSは、相互に認証されなければならず、それらの間のシグナリングは、完全性と機密保護しなければなりません。間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).
Responderが直接チケットを解決できない場合、チケットはKMSに送信されたRESOLVE_INITメッセージに含まれるべきです。 Responderは、チケットを発行したKMS（KMS I）との共有資格を持っていないか、ResponderがKMSがチケットを発行している知っていない場合、レスポンダはレスポンダの信頼できるKMSS（KMS RのいずれかにRESOLVE_INITメッセージを送る必要がある場合）。 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.
再利用されるべきである前RESOLVE_INITメッセージから図9 IDRrチケットペイロードに示すように異なるKMSS間のシグナリングは、チケット解決交換で行ってもよいです。 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.
（TICKETペイロード内の）チケットデータは、鍵管理サービスによって格納された情報（鍵など）を参照することができ、それはすべての情報自体を含むことができ、またはそれは二つの選択肢の組み合わせであってもよいです。多くのユーザーにサービスを提供するシステムでは、まだ有効であるすべての発行されたチケットの状態を維持するための鍵管理サービスを強制するように、参照のみのチケットのアプローチを使用することが理想的ではありません。チケットは使用ポリシーを施行するために役立った情報の多くの異なる種類を運ぶことができます。ポリシーは、グループポリシーまたはユーザごとのポリシーかもしれません。
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が連絡しなければならないことを意味し、それらを生成し、または不透明KMSに接触することなく解決することができることを意味し、透明であってもよいです。チケット情報は、一般的に整合性が保護されるべきであると特定のフィールドを明示的に含まキー場合は、特に、機密性保護を必要とします。他のタイプの情報も、プライバシー上の理由による機密保護を必要とするかもしれません。モード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を取得できるように、チケットのデータは、情報を含まなければなりません。またTICKETペイロードの整合性を検証することが可能でなければなりません。将来の仕様が推奨されるペイロードの順序を使用し、追加のペイロードまたは処理を追加しないことをお勧めします。新しいチケットの種類は、レスポンダのための処理を変更しないでください。新しいチケットの種類は、追加の処理を必要とする場合、それはチケットポリシー（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プロトコル、鍵導出機能、およびその他のコンポーネントのセキュリティ特性上の注意事項が含まれています。いくつかのセキュリティプロパティは、特定のチケットの種類に依存しているように、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.
この仕様は、一般的な場合に複雑さを追加オプション機能の多数を含んでいます。プロトコルの設計が強く、またはサポートしなければならないべきであるMIKEYチケットのオプション（例えば、交換又はメッセージフィールド）を定義する厳密なプロファイルを確立することが奨励されます。このようなプロファイルは、乱暴に異なるオプションセットに準拠する実装から予期しない結果を排除すべきです。
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]のように、ユーザーIDは、機密保護されていません。ユーザーのプライバシーが必要な場合は、匿名または一時的な資格情報などのプライバシー強化技術（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.
鍵導出のランダムなナンス（ランズ）の使用は、オフラインで事前計算攻撃やその他の一般的な攻撃に対抗するために最も重要です。長さrのランズを使用して長さnの鍵は、誕生日攻撃に対して（N + R）/ 2の有効鍵エントロピーを有しています。したがって、RANDRiとRANDRrの長さの合計は、少なくとも最長の事前共有鍵/エンベロープキーのサイズに等しくなければならない/ MPK / TGK / GTGKは、RANDRkms少なくとも最長MPKrと同じ長さでなければならない/ TGK、そしてMIKEYベースチケット内のRANDは、少なくとも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.
CSB更新メッセージは、旧ランズを再利用することに注意してください。これは、総有効キーエントロピーTGKsを仮定し、K個の連続キー更新のための（相対する事前計算攻撃）は、各nビット長であることを意味し、依然としてnビット以下です。換言すれば、全てのk nビットの鍵を取得するために攻撃者によって必要とされる時間とメモリが2 ^ Nに比例します。これは欠陥のように思えるかもしれませんが、これは平均でK * 2 ^（n-1）の作業を必要とブルートフォース、より良くない（kのすべての妥当な値のために）（異なるランズが使用される場合でも）実際にあります。誕生日の攻撃は2 ^（N / 2）の作業を必要とするが、ランズの単一のペアを使用しても同様に多くの異なったキーで保護された2 ^（N / 2）セッションにアクセスする必要があります。これは明らかに、n個の代表的な値については、完全に実行不可能です。このような攻撃の成功確率は、それに応じて更新の数を制限することによって制御することができます。 [RFC3830]に記載されているように、複数のキーが単一の攻撃で妥協することができるという事実はsecret-または公開鍵アルゴリズムを使用して、任意の溶液に固有のものです。攻撃者は、常に、事前共有キー/封筒キー/ MPKに網羅的な探索を行うことによって、すべての交換キーへのアクセスを取得します。これは、mは、キーの実効サイズは2 ^ m個の作業を必要とします。
As the Responder MAY generate a RAND, the Ticket Transfer exchange can provide mutual freshness guarantee for all derived keys.
Responderが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ビットのアルゴリズムのいずれかがサポートされている場合、他の2つのアルゴリズムもサポートされます。 256ビットアルゴリズムが一緒に使用されるべきであり、それらは256ビット未満のキーサイズを使用するアルゴリズムと混合することがないもの。 128ビットより長いセッションキー（TEK / TGK / GTGK）が使用される場合、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
いくつかの状況では、TRANSFER_INITメッセージは、複数のエンドポイントに送達することができます。例えば、レスポンダは、いくつかのデバイス（例えば、携帯電話、固定電話、およびコンピュータ）に登録されている場合、または招待タイプのアドレスになされています
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.
IT-support@example.com、一つだけが答えることになっているユーザーのグループ。イニシエータでも常に許可グループのメンバーがあり、正確に誰か分からないことがあります。盗聴のすべてのフォームを防ぐために、答えるエンドポイント以外のエンティティは、セッションキーへのアクセスを取得してはなりません。
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とTGKs）いくつかのキーは、フォークの対象となる各応答のためにそれらを暗号的にユニークな作り、修正されています。唯一のイニシエータとKMSはマスターTGKsへのアクセス権を持っているとして、他の誰がセッションキーを導出するために、それが実行不可能です。
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とのTEKとチケットでエンコードGTGK）はまだチケットを解決することができますし、これを念頭において使用されるべきで誰でもアクセス可能です。また、これは最初のTRANSFER_INIT（それらはMPKiで保護されているよう）にKEMACで転送セッションキーに関するものです。
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に接触することなくTRANSFER_INITメッセージの正当性を確認できないため、サービスの拒否は、レスポンダを介してレスポンダ及び/又はKMSに対して起動することができます。などの一般的な予防法律速とACL（アクセス制御リスト）機能が故にKMSならびにクライアントで実施されるべきです。シグナリングの中で何かが疑わしい場合は、Responderは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）をだまししようと、MIKEYメッセージの全部または一部を再送信します。 MIKEY-TICKETは、このような攻撃を防ぐと検出するために、いくつかのメカニズムを実装します。リプレイキャッシュと一緒にタイムスタンプを効率的に全体のマイキーメッセージの再生を停止します。受信したメッセージ（またはそのハッシュ）の一部は、そのタイムスタンプが時代遅れになるまで、リプレイキャッシュに保存することができます。リプレイ攻撃を防ぐために、送信者（イニシエータまたはレスポンダ）と受信者（レスポンダまたは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.
攻撃者はまた、新しいマイキーメッセージに挿入して、チケットを再生しようとすることができます。可能なシナリオは、アリスとボブはまずチケット、攻撃者マロリー傍受に基づいて通信することです。その後、（自分として作用する）マロリーは彼女自身のTRANSFER_INITメッセージにチケットを挿入することで、ボブを誘います。キーフォークが使用される場合は、ボブがチケットを解決した際に、そのようなリプレイは常に検出されます。キーフォークが使用されていない場合はマロリーがMPKiの知識を持っていない限り、そのようなリプレイが検出されます。マロリーは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を使用してイニシエータによって開始されると、イニシエータはさえ許可グループのメンバーがあり、正確に誰か分からないことがあります。また、グループのメンバーシップが原因の葉に、時間とともに変化する可能性/結合します。このような状況では、どこのグループアイデンティティ（グループメンバーシップに（RESOLVE_INITメッセージで運ば）KMSは、個人のアイデンティティをマッピングすることができる必要があることを示唆し、不正な応答からチケット解決要求を拒否するようにKMSの責任一番です）チケットに運ばれます。
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.
著者は、彼らのサポートと貴重なためフレドリックAhlqvist、ロルフブロム、李チェン、Lakshminath Dondeti、のVesa Lehtovirta、フレドリックリンドホルム、マッツ・ナズランド、カールNorrman、オスカーOhlsson、ブライアン・ローゼンバーグ、ベングトSahlin、魏Yinxing、と朱Yunwenに感謝したいと思いますコメント。
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が、[RFC3830]で定義されていない、とキーデータ型のエラー。次のIANAの割り当ては（括弧内に登録された値を含むテーブルへの参照である）MIKEYペイロードレジストリに追加されました。
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次ペイロードは、PRFのFUNC O（表6.2参照）（表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)
IDタイプ（表6.9参照）O
o Hash func (see Table 6.11)
（表6.11参照）FUNCハッシュO
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の役割のフィールドを定義し、MIKEYペイロードレジストリに新しい名前空間を維持します。割り当ては、TSのロール名とその値で構成されています。範囲1から239の値は、仕様が必要のプロセスによって承認されるべきで、範囲240から254の値は、[RFC5226]による貸切予約、および値が0と255は予約されています。次のようにレジストリの初期の内容は以下のとおりです。
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の役割のフィールドを定義し、MIKEYペイロードレジストリに新しい名前空間を維持します。割り当ては、IDロール名とその値から成ります。範囲1から239の値は、仕様が必要のプロセスによって承認されるべきで、範囲240から254の値は、[RFC5226]による貸切予約、および値が0と255は予約されています。次のようにレジストリの初期の内容は以下のとおりです。
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の役割のフィールドを定義し、MIKEYペイロードレジストリに新しい名前空間を維持します。割り当ては、RANDのロール名とその値で構成されています。範囲1から239の値は、仕様が必要のプロセスによって承認されるべきで、範囲240から254の値は、[RFC5226]による貸切予約、および値が0と255は予約されています。次のようにレジストリの初期の内容は以下のとおりです。
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 / TICKETペイロードは、IANAが作成していたため、16ビットチケットの種類のフィールドを定義し、MIKEYペイロードレジストリに新しい名前空間を維持します。割り当ては、チケットの種類の名前とその値で構成されています。範囲1から61439までの値は、65534は、私的使用のために予約されている61440-範囲内の値、および値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]米国国立標準技術研究所、 "セキュアハッシュ規格（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.、ベラー、M.、およびR.カネッティ、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、RFC 3830、2004年8月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330]ミルズ、D.、 "IPv4、IPv6、およびOSIのため簡易ネットワークタイムプロトコル（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]カララ、E.、Lehtovirta、V.、およびK. Norrman、RFC 4563、2006年6月 "マルチメディア、インターネットキーイングで一般拡張ペイロード（MIKEY）のためのキーのID情報タイプ"。
[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.、リンドホルム、F.、Naslund、M.、Norrman、K.、およびE.カララ、 "鍵管理拡張セッション記述プロトコル（SDP）、リアルタイムストリーミングプロトコル（RTSP）のための"、RFC 4567、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.林、 "MIKEY-RSA-R：マルチメディアインターネットキーイング（マイキー）で鍵配布の追加モード"、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.
[オトウェイ-リース]オトウェイ、D.、およびO.リース、 "効率的かつタイムリーな相互認証"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 4120、2005年7月。
[RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
[RFC4650] EUCHNER、M.、 "マルチメディアインターネットキーイングのためのHMAC-認証済みのDiffie-Hellmanの（MIKEY）"、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]フリース、RFC 5197、2008年6月 "多様なマルチメディアインターネットキーイング（MIKEY）モードと拡張機能の適用について" S.及びD. Ignjatic、。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009.
[RFC5479]ウイング、D.、フライドポテト、S.、Tschofenig、H.、およびF. Audet、 "要件とメディアセキュリティ管理プロトコルの分析"、RFC 5479、2009年4月。
Appendix A. MIKEY Base Ticket
付録A. MIKEYベースチケット
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.
MIKEYベースチケットは、4.1.1項で説明したのいずれかのモードで使用されるかもしれません。チケットデータは、MIKEYペイロードから構成されるものとし、事前共有チケット保護キー（TPK）に基づいて、MACによって保護されなければなりません。 TPKを共有する当事者は、モードによって異なります。チケットデータに予期しないペイロードは無視されるべきです。
Ticket Data = THDR, T, RAND, KEMAC, [IDRpsk], V
チケットデータ= THDR、T、RAND、KEMAC、[IDRpsk]、V
A.1. Components of the Ticket Data
A.1。チケットデータの成分
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（初期化ベクトル）の形成に使用されてもよい（例えば、セクション4.2.3 [RFC3830]）。
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).
キーがTPKとMPK由来する場合RAND、キー導出関数への入力として使用されている（付録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:
MACは、Vペイロードに含まれるようKEMACペイロードは、NULL認証アルゴリズムを使用しなければなりません。暗号化キー（encr_key）とキー（salt_key）を塩漬けはTPK（付録A.2.1を参照）に由来するものとします。暗号化アルゴリズムによっては、塩漬けキーがIVの生成に使用される（[RFC3830]のセクション4.2.3を参照してください）。 CSB IDは、IVの作成に必要な場合には、「0xFFFFFFFFの」に設定されます。次のようにKEMACは、従って構成されています。
KEMAC = E(encr_key, MPK || {TEK|TGK|GTGK})
KEMAC = E（encr_key、MPK || {TEK | TGK | GTGK}）
MPKi and MPKr are derived from the MPK as defined in Appendix A.2.2.
付録A.2.2で定義されているようMPKiとMPKrは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はTPKを取得するために、KMS /レスポンダを可能に識別子が含まれています。 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は次にペイロードフィールド（TICKETペイロードにおいて）、イニシエータデータ長フィールド、イニシエータデータフィールド、及びMACフィールド自体を除く全体TICKETペイロードにわたって計算しなければなりません。
A.2. Key Derivation
A.2。鍵の導出
The labels in the key derivations SHALL NOT include entire RAND payloads, only the fields RAND length and RAND from the corresponding payload.
鍵導出のラベルは、対応するペイロードから全体RANDペイロード、フィールドのみRAND長及びRANDを含めてはなりません。
A.2.1. Deriving Keys from a TPK
A.2.1。 TPKから鍵を導出します
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ビットの符号なし整数としてバイト単位でRANDの長さです。 [RFC3830]のセクション4.1.4で定義された定数です。鍵導出及びチケットデータ内容に対するその依存性AES-CMが使用されている図10に示される鍵導出がチケットを作成当事者（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から派生鍵
A.2.2. Deriving MPKi and MPKr
A.2.2。 MPKiとMPKrの導出
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ビットの符号なし整数としてバイト単位でRANDの長さです。以下に要約として定数は派生キータイプによって異なります。
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の桁から取られます。
A.3. Ticket Header Payload (THDR)
A.3。チケットヘッダーペイロード（THDR）
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データ（可変長）：それは期待されていない場合は無視されるべきで実装固有のデータ。
Appendix B. Alternative Use Cases
付録B.代替ユースケース
B.1. Compatibility Mode
B.1。互換モード
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チケットは、[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
電話：+46 10 71 43 501 Eメール：john.mattsson@ericsson.com
Tian Tian ZTE Corporation 4F, RD Building 2, Zijinghua Road Yuhuatai District, Nanjing 210012 P.R. China
TI抗押しZ TE法人4F、RDビル2、Z Iエッセンス道路Y Uタイ地区、南京210012中華人民共和国
Phone: +86-025-5287-7867 EMail: tian.tian1@zte.com.cn
電話：+ 86-025-5287-7867 Eメール：tian.tian1@zte.com.cn