RFC 6043
MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY) ✨ (Part 1 of 13)
Okay bestie, this one is from the IETF, and it was written by J. Mattsson of Ericsson and T. Tian of ZTE 🫶. It's an Informational RFC, which means it's shared for info and is not an Internet Standards Track spec 📚. It was published as RFC 6043 in March 2011, and its ISSN is 2070-1721 🎀. The title block doesn't list any RFCs that it obsoletes or updates, so it's just a standalone drop 💅.
Abstract ✨
Okay so MIKEY (the Multimedia Internet KEYing spec) is a key management scheme for real-time apps 🎧. This doc says the modes MIKEY already has aren't enough for setups built around a centralized key management service, and those setups are getting more popular 📈. So it defines a new set of MIKEY modes that actually work well there 🦋. These modes use a trusted key management service plus a ticket concept that's similar to Kerberos 🎟️. They also support stuff lots of existing apps need, like when you don't know exactly who the other endpoint is yet at the start of the session 👀.
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.
Info about the current status of this doc, any errata, and how to give feedback can be found at 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. 🩷
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 carefully, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License 📜.
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 ........................................581. Introduction ✨
Okay so key management systems usually work in one of three ways 🔑. Either the peers negotiate and swap stuff directly with each other (think Diffie-Hellman-based schemes), or user credentials get pre-distributed (shared secrets or certificates), or there's a trusted Key Management Service (KMS) 🏛️. The modes in the Multimedia Internet KEYing (MIKEY) spec [RFC3830] and its extensions [RFC4650] [RFC4738] are all variants of the first two options 💅.
Now, when a security system has a ton of users, a KMS-based solution is often the move 💖. With a service like that, you don't have to pre-distribute credentials that could directly set up security associations between peers for protected communication, because users can just request credentials whenever they need them 🙌. Trusted KMS-based solutions also scale really well as the number of users grows 📈.
This document introduces a set of new MIKEY modes that go under the common name MIKEY-TICKET 🎀. These modes have a ticket concept, similar to the one in Kerberos [RFC4120], and it's used to identify and deliver keys 🎟️. Here's the big picture: the Initiator requests keys and a ticket from the KMS and then sends the ticket to the Responder. The ticket holds a reference to the keys, or the enveloped keys 📦. Then the Responder sends the ticket to the KMS, and the KMS returns the right keys ✨.
MIKEY-TICKET is mainly designed for media plane security in the 3rd Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS) [3GPP.33.328] 📞. That means some extensions to the basic Kerberos idea are needed 🧩. For example, the Initiator might not always know the exact identity of the Responder when it starts talking to the key management server 👀.
This document defines a signaling framework that lets peers request, transfer, and resolve various Ticket Types using a key management service 📡. A default Ticket Type is also defined 🌸. To let users with high security needs use 256-bit keys, extra encryption, authentication, and pseudorandom functions are defined too 🔐. And because the existing SRTP-ID map type has limitations, a new CS ID map type called GENERIC-ID is defined 🦋.
2. Terminology ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] 📖. Definitions of terms and notation are, unless stated otherwise, the same as the ones in [RFC3830] 💅.
2.1. Definitions and Notation
Here's the glossary bestie 🫶:
Forking: Delivering a request to multiple endpoints, either multiple devices owned by one user or multiple users 📲.
Key forking: When it's used alongside forking, key forking means modifying keys so they're cryptographically unique for each responder that the forking targets 🔀.
(Media) session: The communication session that the MIKEY-TICKET provided key(s) are meant to secure 🎥.
Session information: Info about the security protocols used to protect the media session, like keys, salts, algorithms, and so on 🗝️.
Ticket: A Kerberos-like object used to identify and deliver keys over an untrusted network 🎫.
Ticket Data: The part of the ticket with info meant only for the party that resolves the ticket (for example, keys) 🤫.
Ticket Request: The exchange the Initiator uses to request keys and a ticket from a trusted KMS 🙋.
Ticket Transfer: The exchange that transfers the ticket plus session information from the Initiator to the Responder 🚚.
Ticket Resolve: The exchange the Responder uses to ask the KMS to return the keys encoded in a ticket 🔓.
Ticket Policy: The policy for ticket generation and resolution, including authorized applications, key derivation, and so on 📋.
Ticket Type: Defines the ticket format and how it gets processed. It may further have a subtype and version 🏷️.
Here's how the arrows work in the diagrams ✨. Solid arrows (----->) show mandatory messages, and dashed arrows (- - ->) show optional messages 🏹.
And here's the notation cheat sheet 🧾:
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
|| Concatenation
| OR (selection operator)2.2. Abbreviations ✨
okay so this is the big ol' glossary bestie 🎀 every acronym you'll run into in the rest of the spec lives right here, so bookmark it 🔖 (no cap, you will be scrolling back up a lot 💀)
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 Time2.3. Payloads 🎁
okay the payloads are the little packages MIKEY messages are made of, and this list is the name tag on each one 🧚 you'll see these everywhere, so learn the vibes now bestie 💜
CERTx: Certificate of entity x
CHASH: Hash of the certificate used
HDR: Common Header payload
ID: Identity payload
IDRx: Identifier for entity x
IDRpsk: Identifier for pre-shared key
IDRapp: Identifier for application/service
KEMAC: Key data transport payload
PKE: Encrypted envelope key
RAND: RAND payload
RANDRx: Random value generated by entity x
SIGNx: Signature created using entity x's private key
SP: Security Policy payload
T: Timestamp payload
TRy: Timestamp payload with role indicator y
THDR: Ticket Header payload
TICKET: Ticket payload
TP: Ticket Policy payload
V: Verification payload
where
x is in the set {i, r, kms} (Initiator, Responder, KMS) and
y is in the set {i, s, e, r} (time of Issue, Start time, End time,
Rekeying interval).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).
3. Design Considerations 🧠
okay so bestie, the big picture: none of the MIKEY modes we've covered so far are based on a KMS 🙈 the pre-shared key method and the public-key encryption method in [RFC3830] are basically systems built on pre-distributing user credentials 🗝️, and the Diffie-Hellman method in [RFC3830] is about negotiating directly between peers 🤝.
Now the forking drama 🍿. A request can get delivered to multiple endpoints, like one person's phone, desk phone and laptop all ringing at once 📱💻, or a shared inbox like IT-support@example.com where only one person is supposed to answer 📬. We're calling all of these "forking" 🔀. SIP does this with forking and retargeting, per [RFC3261] 📞. Here's the thing: only the endpoint that actually answers should get the session keys 🔐, otherwise it's an eavesdropping situation and that is NOT it 💀. Naively using [RFC3830] where every endpoint shares the same pre-shared or private key is not secure for forking, because every endpoint ends up with the session keys 😭. But per-user unique pre-shared keys or certificates create a different headache, since the initiator has no idea which one to use when the session starts 🤷♀️. For SIP-signaled media protection, check out [RFC5479], and [RFC5197] talks about where the different MIKEY modes fit 📚.
Next up, big systems with tons of users 🌍. A key management service (KMS) is usually the move here. With one in place, nobody has to pre-distribute credentials that could directly set up security associations between peers, because users just request them when they need them 🙌. This is especially helpful in things like National Security and Public Safety (NSPS), where the controlling org wants to enforce key policies 👮♀️. A trusted KMS makes central policy enforcement way easier, and it scales nicely as the number of users grows 📈. Symmetric-key KMS designs have a real advantage too, since symmetric algorithms are generally much less computationally intensive than asymmetric ones ⚡.
Systems built on a KMS need a signaling mechanism so peers can fetch each other's credentials 🎟️. A handy approach is a ticket concept, similar to the one in Kerberos [RFC4120], used to identify and deliver keys. The ticket rides along in the signaling for session setup 🛫. The initiator asks the KMS for a ticket and sends it to the responder, and the responder forwards the ticket to the KMS, which hands back the matching keys 🔑.
Quick note: Kerberos doesn't require the responder to contact the KMS too 🤔. But to support those forking scenarios, the ticket can't be tied to the exact identity (or credentials) of the responder until the final responder is fully known 🕵️♀️. Group and forking setups also get better access control if key access can be enforced at a finer granularity on the responder side 🔒. This mechanism is useful for any system where the initial message might go to arbitrarily many potential responders, and where that set of responders can change at any time 🌪️. And on top of all that, it also supports group key management 👑.
The ticket can either hold a reference to keys stored in the key management system, or hold the keys itself 🎫. If it holds the keys, the ticket must be confidentiality and integrity protected (enveloped) 🛡️. From here on, "encoded keys" covers both cases, plus keys derived from them 💅.
Ticket Types and ticket policies can be mixed and matched, and some let the initiator or responder create or resolve tickets without help from the KMS 🧩. That means a wide range of security levels and use cases can be covered, which is seriously flexible 🦋.
Ticket-based systems can also help with deferred delivery of end-to-end protected content to users who are offline right now 📭. Direct online negotiation schemes (like Diffie-Hellman) are ruled out for that, because the responder can't count on reaching the initiator to get keys 🚫.
Last but not least, a real plot twist 🎭: a centralized key management service can become a single point of (security) failure 😱. In high-security applications, protecting and implementing the KMS may need to be about as strict as what's expected of an AAA (Authentication, Authorization, and Accounting) server or a Certification Authority (CA) 🏰.
4. MIKEY-TICKET 🎟️
4.1. Overview ✨
Okay so every MIKEY mode we've looked at so far is just one round trip (or half of one) between two peers 💅. MIKEY-TICKET is giving main character because it can have up to three round trips (Ticket Request, Ticket Transfer, and Ticket Resolve) with three parties (Initiator, Responder, and KMS) 😭. The number of round trips and the order of messages can change, so MIKEY-TICKET is really the umbrella name for a whole set of modes, all built around one idea: the ticket 🎀. The third party, the KMS, only shows up in some of the MIKEY exchanges, and never in the resulting secure media session 🙈. The Ticket Request and Ticket Resolve exchanges are only meant to be used together with the Ticket Transfer exchange, not on their own. Figure 1 shows the signaling for the full three round-trip MIKEY-TICKET mode 🦋.
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
REQUEST_INIT
-------------------------------->
REQUEST_RESP
<--------------------------------
TRANSFER_INIT
---------------------------------------------------------------->
RESOLVE_INIT
<--------------------------------
RESOLVE_RESP
-------------------------------->
TRANSFER_RESP
<----------------------------------------------------------------
Figure 1: Full three round-trip signalingThe Initiator (I) wants a secure media session with the Responder (R) 🫶. They don't share any credentials, so instead they both trust a third party, the KMS, which they either already share credentials with or can set up shared credentials with 🤝. Those pre-established trust relations are what get used to build a security association between I and R. Figure 2 shows the trust model 💜.
Pre-established trust relation Pre-established trust relation
<------------------------------> <------------------------------>
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
<--------------------------------------------------------------->
Security association based on ticket
Figure 2: Trust modelNote that there doesn't have to be just one KMS. Multiple KMSs may be involved, e.g., one for the Initiator and one for the Responder. That's covered in Section 10 🌸.
The Initiator asks the KMS for keys and a ticket (encoding the same keys) by sending a REQUEST_INIT message 📨. The REQUEST_INIT message carries 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. This is 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 sends the keys and the ticket back 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).
The Initiator then puts the ticket in a TRANSFER_INIT message and sends it 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. That happens 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) 🙃.
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 KMS modifies the keys so they're bound to the Responder, see Section 5.1.1 💅. The keys and additional information then go to the Responder in a RESOLVE_RESP message. The Responder sends a TRANSFER_RESP message to the Initiator as verification. The TRANSFER_RESP message might include information used for further key derivation 🌈.
The use case and signaling 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 📚.
The session keys are normally generated or supplied by the KMS (encoded in the ticket). In certain use cases (see Section 8), though, the session key may be supplied by the Initiator or Responder, sent in a separate KEMAC that's protected with keys derived from the MPK 🫧.
MIKEY-TICKET offers a framework that's flexible enough for users with a broad range of security and functional needs 👑. The framework consists of the three exchanges, and different Ticket Types can be defined for them. The ticket is made of a Ticket Policy plus Ticket Data. The Ticket Policy holds information meant for all parties involved, whereas the Ticket Data is only meant 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 everything itself, or it could be a mix of the two. The format of the Ticket Data depends on the Ticket Type signaled in the Ticket Policy. The Ticket Data for the default Ticket Type, called MIKEY base ticket, is defined in Appendix A, and requirements for new Ticket Types are given in Section 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 🔐.
4.1.1. Modes 💖
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 or 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), because the Responder can resolve the ticket without help from the KMS (mode 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: ModesIf 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]), because the Initiator can create the ticket without help 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 🦋.
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. Also, since tickets may be reused (see Section 5.3), a single Ticket Request exchange may be followed by several Ticket Transfer exchanges 🍓.
4.2. Exchanges 🎀
4.2.1. Ticket Request 🧁
This exchange is how the Initiator requests keys and a ticket from a trusted KMS that it has pre-shared credentials with 🗝️. The request holds information (e.g., participant identities, etc.) that describes the session the ticket is meant to protect. The Initiator needs a full round trip 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] 💜.
Initiator KMS
REQUEST_INIT_PSK = ---->
HDR, T, RANDRi, [IDRi],
[IDRkms], TP, <---- REQUEST_RESP =
[IDRpsk], V HDR, T, [IDRkms],
TICKET, KEMAC, VThe second variant corresponds to the public-key (PK) method of [RFC3830] 🌈.
Initiator KMS
REQUEST_INIT_PK = ---->
HDR, T, RANDRi, [IDRi],
{CERTi}, [IDRkms], TP, <---- REQUEST_RESP =
[CHASH], PKE, SIGNi HDR, T, [IDRkms],
TICKET, KEMAC, VAs 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 🫶.
In addition to the ticket, the Initiator receives keys it doesn't already know ✨. The ticket contains both session information and the information needed to resolve the ticket later, see Section 6.10 👑.
4.2.1.1. Common Components of the REQUEST_INIT Messages 🎀
okay so the REQUEST_INIT message MUST always include the Header (HDR), Timestamp (T), and RANDRi payloads. no skipping these, bestie 🫶
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, because a response is MANDATORY 💅. since 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] ✨.
IDRi holds the identity of the Initiator. this identity SHOULD be included in the granted Ticket Policy 🦋.
IDRkms holds 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 🌸.
the Ticket Policy payload (TP) holds the Ticket Policy you want. it includes stuff like the ticket's validity period, the number of requested keys, and the identities of authorized responders (see Section 6.10) 👑.
4.2.1.2. Components of the REQUEST_INIT_PSK Message 🔑
the IDRi payload SHOULD be included, but it MAY be left out when the KMS can be expected to figure out the Initiator some other way 🧚.
the IDRpsk payload shows which pre-shared key is being used. it MAY be omitted if the KMS can find the pre-shared key by other means 🍓.
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) 🔒.
4.2.1.3. Components of the REQUEST_INIT_PK Message 🪄
the identity IDRi and certificate CERTi SHOULD be included, but they MAY be left out when the KMS can be expected to get the certificate some other way 💖. if a certificate chain is provided, each certificate in the chain SHOULD go in its own separate CERT payload. the Initiator's certificate MUST come first, and each following certificate MUST directly certify the one before it. main character certificate chain energy 👑.
PKE holds the encrypted envelope key: PKE = E(PKkms, env_key). it gets encrypted with the KMS's public key (PKkms). if the KMS has several public keys, the Initiator can indicate which one was used in the CHASH payload 🎀.
SIGNi is a signature covering the entire REQUEST_INIT_PK message, made with the Initiator's signature key (see Section 5.5 for the exact definition) ✍️.
4.2.1.4. Processing the REQUEST_INIT Message 🧠
if the KMS can verify the integrity of the received message and the message can be parsed correctly, 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 🫠.
4.2.1.5. Components of the REQUEST_RESP Message 🌈
the version, PRF func and CSB ID, #CS, and CS ID map type fields in the HDR payload SHALL be identical to the matching 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 🦋.
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 🔢.
the TICKET payload carries the granted Ticket Policy and the Ticket Data (see Section 6.10). since the KMS decides which Ticket Policy to use, it may not match what the Initiator asked for. the Ticket Type and the Ticket Data depend on the granted Ticket Policy 🎟️.
the KEMAC payload SHALL use the NULL authentication algorithm, because a MAC is included in the V payload 🙅♀️. depending on the type of REQUEST_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the encr_key (and salt_key). depending on the encryption algorithm, the salting key may go into the IV (see [RFC3830]) 🧂. if the TP payload in the REQUEST_INIT message does not contain a KEMAC, it is RECOMMENDED that the KMS's default KEMAC include a single TGK 💅.
the KEMAC SHALL include an MPK (MIKEY Protection Key), MPKi, which is 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 (as 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 therefore constructed like this:
KEMAC = E(encr_key, MPKi || [MPKr] || {TEK|TGK|GTGK})the last payload SHALL be a Verification payload (V). depending on the type of REQUEST_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the auth_key. the MAC SHALL cover the entire REQUEST_RESP message as well as the REQUEST_INIT message (see Section 5.5 for the exact definition) 🛡️.
4.2.1.6. Processing the REQUEST_RESP Message 🎯
if the Initiator can verify the integrity of the received message and the message can be parsed correctly, 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 🧹.
before using the received ticket, the Initiator MUST check that the granted Ticket Policy is acceptable. if it isn't, the Initiator SHALL discard it and MAY send a new REQUEST_INIT message suggesting a different Ticket Policy than before 🚩.
4.2.2. Ticket Transfer ✨
this exchange transfers a ticket plus session information from the Initiator to a Responder 🎁. it's modeled after the pre-shared key mode [RFC3830], except that 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 go from the Initiator to the Responder (similar to [RFC3830]) or from the Responder to the Initiator (similar to [RFC4738]) 🔄. since the goal of this exchange is to set up 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 🌊.
Initiator Responder
TRANSFER_INIT = ---->
HDR, T, RANDRi, [IDRi],
[IDRr], {SP}, TICKET, < - - TRANSFER_RESP =
[KEMAC], V HDR, T, [RANDRr],
[IDRr], [RANDRkms],
{SP}, [KEMAC], V4.2.2.1. Components of the TRANSFER_INIT Message 📦
the TRANSFER_INIT message MUST always include the Header (HDR), Timestamp (T), and RANDRi payloads 🫶. 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 🙃.
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 the Responder can be expected to have a single identity 🪪.
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]) 🍰.
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 holds information meant for all the parties involved, whereas the Ticket Data is only meant for the party that resolves the ticket 🎫. the Ticket Type given in the Ticket Data is indicated in the Ticket Policy. the Initiator Data authenticates the Initiator when key forking (I flag) is used 🕵️♀️.
the KEMAC payload is handled the same way as if it were sent in a later CSB update (see Section 5.2), with one difference: the encr_key is always derived from MPKi, so every responder authorized to resolve the ticket can access it 🗝️. 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 the Ticket Policy indicates it (L flag), a KEMAC payload SHALL NOT be included 🚫.
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) 🔏.
4.2.2.2. Processing the TRANSFER_INIT Message 🫣
since the Initiator and Responder don't 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 aren't, the Responder SHALL reject without contacting the KMS 🛑. this is an early reject mechanism, so no unnecessary KMS signaling happens when the Responder can already tell from the information at hand that it won't accept the connection 🏃♀️. after the ticket has been resolved, 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 💌.
4.2.2.3. Components of the TRANSFER_RESP Message ✨
okay so the version, PRF func and CSB ID fields in the HDR payload SHALL be identical to the matching fields in the TRANSFER_INIT message, no changes bestie 💅 The V flag literally has no meaning in this context 🙈 The Responder SHALL set it to '0' and the Initiator SHALL ignore it. 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 where the Initiator has not supplied Session Data and SPI. If needed, the Responder MAY update the Session Data and SPI the Initiator provided. If the Responder adds crypto sessions, the #CS SHALL be updated.
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. ⏰
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. 🎀
If the Responder receives an IDRr payload in the RESOLVE_RESP message, the same identity MUST be sent in an IDRr payload in the TRANSFER_RESP message. The identity sent in the IDRr payload in the TRANSFER_RESP message (e.g., user1@example.com) MAY differ from the one sent in the IDRr payload in the TRANSFER_INIT message (e.g., IT-support@example.com). 🦋
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. 🌸
The Responder MAY provide additional Security Policy payloads. The Responder SHOULD NOT resend SP payloads which the Initiator supplied. 🍓
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. 🔐
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). 🫶
4.2.2.4. Processing the TRANSFER_RESP Message 🔍
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. 🙏
4.2.3. Ticket Resolve 🎟️
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]. 🗝️
Responder KMS
RESOLVE_INIT_PSK = ---->
HDR, T, RANDRr, [IDRr],
[IDRkms], TICKET, <---- RESOLVE_RESP
[IDRpsk], V HDR, T, [IDRkms], KEMAC,
[IDRr], [RANDRkms], VThe second variant corresponds to the public-key (PK) method of [RFC3830]. 🔑
Responder KMS
RESOLVE_INIT_PK = ---->
HDR, T, RANDRr, [IDRr],
{CERTr}, [IDRkms], TICKET, <---- RESOLVE_RESP
[CHASH], PKE, SIGNr HDR, T, [IDRkms], KEMAC,
[IDRr], [RANDRkms], VAs 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. 🛡️
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. 🧩
4.2.3.1. Common Components of the RESOLVE_INIT Messages 💫
The RESOLVE_INIT message MUST always include the Header (HDR), Timestamp (T), and RANDRr payloads. 📋
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]. 🚫
IDRkms SHOULD be included, but it MAY be left out when it can be expected that the KMS has a single identity. 🆔
The TICKET payload contains the Ticket Policy and Ticket Data that the Responder wants to have resolved. 🎫
4.2.3.2. Components of the RESOLVE_INIT_PSK Message 🔐
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. 🙋
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. 🗝️
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). 🧾
4.2.3.3. Components of the RESOLVE_INIT_PK Message 🪪
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. 📜
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. 🔏
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). ✍️
4.2.3.4. Processing the RESOLVE_INIT Message 🧐
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. ✅
4.2.3.5. Components of the RESOLVE_RESP Message 🎁
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. 🙈
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. ⏰
The KEMAC payload SHALL use the NULL authentication algorithm, as a MAC is included in the V payload. Depending on the type of RESOLVE_INIT message, either the pre-shared key or the envelope key SHALL be used to derive the encr_key (and salt_key). Depending on the encryption algorithm, the salting key may go into the IV (see [RFC3830]). The KEMAC SHALL include an MPK (MPKi), used as a pre-shared key to protect the messages in the Ticket Transfer exchange. The KEMAC is hence constructed as follows: 🧁
KEMAC = E(encr_key, MPKi || [MPKr'] || {TEK|TGK|GTGK})If key forking (see Section 5.1.1) is used (determined by the I flag in the Ticket Policy), a second MPK (MPKr') SHALL be included in the KEMAC. Then, MPKi SHALL be used to verify the TRANSFER_INIT message and MPKr' SHALL be used to protect the TRANSFER_RESP message. The KMS SHALL also fork the MPKr and the TGKs. The modifier used to derive the forked keys SHALL be included in the IDRr and RANDRkms payloads, where IDRr is the identity of the endpoint that answered and RANDRkms is a fresh (pseudo-)random byte string generated by the KMS. The reason that the KMS MAY adjust the Responder's identity is so that it matches an identity encoded in the ticket. 🍭
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). 🫧
4.2.3.6. Processing the RESOLVE_RESP Message 🎀
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. 💜
5. Key Management Functions 🔑
5.1. Key Derivation ✨
okay so bestie, for every message in the Ticket Request and Ticket Resolve exchanges, the keys that protect the MIKEY messages come 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. no cap, that's a lot less work 💅
In the Ticket Transfer exchange, the keys that 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. Also, the Responder MAY generate a RAND to give the Responder key freshness guarantee 🫶
The key hierarchy and its dependencies on TRANSFER_INIT message contents, for the case without key forking and RANDRr, are shown 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 🌸
+------+------------------+-----+------+
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
The key hierarchy and its dependencies on TRANSFER_RESP message contents, for the case with key forking and RANDRr, are shown 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.
+------+--------------------------+-----+------+
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
The labels in the key derivations SHALL NOT include entire RANDR payloads, only the fields RAND length and RAND from the corresponding payload 🙈
5.1.1. Deriving Forked Keys 🍓
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_lenwhere 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 💜
Derived key | Constant
------------+-----------
MPKr' | 0x2B288856
TGK' | 0x1512B54A
Table 5.1: Constants for forking key derivationThe constants are taken from the decimal digits of e, as described in [RFC3830] 🧚
5.1.2. Deriving Keys from an Envelope Key/PSK/MPK 🎀
This derivation is used to form the keys that protect the MIKEY messages. For the Ticket Request and Ticket Resolve exchanges, the keys that 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:
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)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)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. 🌈
5.1.3. Deriving Keys from a TGK/GTGK 💖
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:
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)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. 🦋
5.2. CSB Updating 🦋
okay so [RFC3830] already has the CSB (Crypto Session Bundle) updating idea, and MIKEY-TICKET takes it and runs with it 💅. You can transport a new TEK/TGK/GTGK or add new crypto sessions by running the Ticket Transfer exchange again, like right before a TEK expires or when a new crypto session is needed. The Initiator can kick things off:
Initiator Responder
TRANSFER_INIT = ---->
HDR, T, [IDRi], [IDRr],
{SP}, [KEMAC], V < - - TRANSFER_RESP =
HDR, T, [IDRr],
{SP}, [KEMAC], VThe Responder can start it too 🫶:
Responder Initiator
TRANSFER_INIT = ---->
HDR, T, [IDRr], [IDRi],
{SP}, [KEMAC], V < - - TRANSFER_RESP =
HDR, T, [IDRi],
{SP}, [KEMAC], VThe new exchange MUST use the same CSB ID as the first one, but it MUST use new timestamps ⏰. The crypto session negotiation (the #CS field, the CS ID map info field, and the SP payloads) works the same way as the initial exchange ✨. In the TRANSFER_INIT message, the V flag SHALL be used to say whether a response message is expected or not 🎀. Static payloads like RANDRi, RANDRr, RANDRkms, and TICKET that came with the initial exchange SHOULD NOT be included unless a specific use case actually needs them. New RANDs or TICKETs MUST NOT be included 🙅♀️. New RANDs SHALL NOT be used, and here's why: if several TGKs are in play, the peers would have to track which RANDs go with which TGK, and that's just 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 🔐.
New keying material MAY be sent in a KEMAC payload 🍓. If the Ticket Policy (L and M flags) says so, 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, because a MAC is already 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 🚫. So the KEMAC is built like this:
KEMAC = E(encr_key, (TEK|TGK|GTGK))5.3. Ticket Reuse 🎟️
MIKEY-TICKET has features that take pressure off the KMS so it doesn't have to handle every ticket request 🧚. One of them is that tickets can be reused. A user can request a ticket for media sessions with another user, and then, while the ticket is still valid, use it to protect several media sessions with that same user 💜.
When you reuse a ticket that was already used in a previous Ticket Transfer exchange, you run a new Ticket Transfer exchange. The new exchange MUST use a new CSB ID, a new timestamp, and new RANDs (RANDRi, RANDRr) 💖. If the Responder already resolved the ticket before, it doesn't have to resolve it 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 🛑. Heads up: a stateless KMS can't detect this kind of reuse 👀. When group keys are involved, the Initiator is on the hook for making sure group membership hasn't changed since the ticket was last used. (Otherwise, unauthorized responders could get into the group communication 😱.) So if group dynamics are hard to verify, the Initiator SHOULD NOT initiate ticket reuse 🙈.
When key forking is used, only the user who requested the ticket can access the encoded master keys (MPKr, TGKs). Because of that, nobody else can start a Ticket Transfer exchange with the ticket 🔒.
5.4. Error Handling 🚨
If a fatal error happens while a message is being parsed, the message SHOULD be discarded, and an Error message SHOULD be sent to the other party (Initiator, Responder, KMS) 💌. If the failure is because the peer couldn't be authenticated, the message SHALL be discarded, the Error message is OPTIONAL, and the caveats in Section 5.1.2 of [RFC3830] apply 🙃. Error messages can be used to report errors in both initial and response messages, but not in Error messages themselves 🤭.
In the Ticket Request and Ticket Resolve exchanges, the Error message MAY be authenticated with a MAC or a signature ✍️. So the Error message is built like this:
Error message = HDR, T, (ERR), [V|SIGNx]Here, x is one of {i, r, kms} (Initiator, Responder, KMS). Unexpected payloads in the Error message SHOULD be ignored 🧹.
In the Ticket Transfer exchange, the Error message MAY be authenticated with a MAC. If the suggested security policies aren't supported, the Error message SHOULD include the supported parameters 📋. So this one is built like this:
Error message = HDR, T, (ERR), {SP}, [V]In Error messages, the version, PRF func, and CSB ID fields in the HDR payload SHALL be identical to the matching fields in the message where the error happened 🪞. The V field SHALL be set to '0' and be ignored 😌.
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 the same as the one in the message where the error happened 🔢.
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 the one in the message where the error occurred 🗝️.
5.5. MAC/Signature Coverage 🧾
The MAC/Signature in the V/SIGN payloads covers the whole MIKEY message, except the MAC/Signature field itself 💅. For initial messages, the identities (not the 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 🙅. Also, in the Transfer Exchange, Identity_r in TRANSFER_RESP (e.g., user1@example.com) MAY differ from the one in TRANSFER_INIT (e.g., IT-support@example.com) 👀. For response messages, the entire initial message (including its MAC/Signature field) MUST directly follow the MIKEY message in the Verification MAC/Signature calculation. The identities are implicitly covered there, because the initial message's MAC/Signature already covers them 🔁.
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 messageTable 5.2: MAC/Signature coverage 📊
6. Payload Encoding 🧚
This section doesn't go through every payload used in the new message types ✨. It goes into detail on 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, check [RFC3830] 📖. Note that the fields with variable length are byte aligned, not 32-bit aligned 📏.
6.1. Common Header Payload (HDR) 🎀
For the Common Header Payload, new values are added to the Data Type, Next Payload, PRF func, and CS ID map type name spaces 🌈.
- Data Type (8 bits): describes the type of message 💌.
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 messageTable 6.1: Data Type (Additions)
- Next Payload (8 bits): tells you which payload comes right after this one 🎁.
Next Payload | Value | Section
-------------+-------+--------
TR | 13 | 6.4
IDR | 14 | 6.6
RANDR | 15 | 6.8
TP | 16 | 6.10
TICKET | 17 | 6.10Table 6.2: Next Payload (Additions)
- V (1 bit): a flag that says 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) 🙅♀️.
- PRF func (7 bits): tells you which PRF function has been or will be used for key derivation 🔑. Besides the PRFs already defined in [RFC3830], the following additional PRF may be used ✨.
PRF func | Value
-----------------+------
PRF-HMAC-SHA-256 | 1Table 6.3: PRF func (Additions)
The new PRF SHALL be built as described in Section 4.1.2 of [RFC3830], with two differences: 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 💖. That matches the full output length of SHA-256 🧁.
- #CS (8 bits): tells you how many crypto sessions are in the CS ID map info 🔢.
- CS ID map type (8 bits): says how crypto sessions get uniquely mapped to the security protocol sessions 🗺️. In the Ticket Transfer exchange, the new GENERIC-ID map type SHOULD be used 🌟. It's meant to get rid of the limitations of the existing SRTP-ID map type. The map type SRTP-ID SHALL NOT be used 🚫.
CS ID map type | Value
---------------+------
GENERIC-ID | 2Table 6.4: CS ID map type (Additions)
- CS ID map info (variable length): identifies and maps the crypto sessions to the security protocol sessions that should get security associations created 🫧.
6.1.1. The GENERIC-ID Map Type ✨
okay so the GENERIC-ID map type is giving main character 💅. The CS ID map info is made up of #CS number of blocks, and each block bundles up policies, session data (like the SSRC 🎀) and a key for one specific crypto session 🔐.
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.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]).S(1 bit): flag that MAY be used by the Session Data.#P(7 bits): indicates the number of security policies provided for the crypto session. In response messages,#PSHALL always be exactly 1. So if#P = 0in 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.Ps(variable length): lists the policies for the crypto session. It SHALL contain exactly#Ppolicies, each having the specified Prot type.
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.
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.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. TheSflag is used to indicate whether the ROC and SEQ fields are provided ('1') or if they are omitted ('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.ROC(32 bits): current/initial rollover counter. If the session has not started, this field is set to'0'.SEQ(16 bits): current/initial sequence number.
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(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.
6.2. Key Data Transport Payload (KEMAC) 🔑
okay, so for the KEMAC payload, two brand new algorithms show up to the party 🎉: a new encryption one and a new authentication one.
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 | Value | Comment
-----------+-------+---------------------------
AES-CM-256 | 3 | AES-CM using a 256-bit key
Table 6.5: Encr alg (Additions)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.
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 | Value | Length
-----------------+-------+---------
HMAC-SHA-256-256 | 2 | 256 bits
Table 6.6: MAC alg (Additions)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.
6.2.1. Key Data Sub-Payload 🗝️
for the key data sub-payload, there are new types of keys too 💖. The Group TGK (GTGK) gets used like a regular TGK, with one twist: it SHALL NOT be forked. It exists so a group TGK can be set up when key forking is in play 🫶. The MIKEY Protection Key (MPK) protects the MIKEY messages in the Ticket Transfer exchange. The MPK works as the pre-shared key in the pre-shared key method of [RFC3830], but the Responder doesn't know it yet, because it isn't known before the ticket has been resolved 🙈.
An SPI (or MKI) MUST be specified for each key (see Section 6.13 of [RFC3830]).
Type(4 bits): indicates the type of key included in the payload.
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.3. Timestamp Payload (T) ⏰
for the timestamp payload, there's a new type of timestamp, and it's made for validity periods where fractions of a second honestly don't matter 🙌. The NTP-UTC-32 string is four bytes, in the same format as the first four bytes of the NTP timestamp format defined in [RFC4330]. It counts the seconds since 0h on 1 January 1900, relative to Coordinated Universal Time (UTC). Heads up: on 7 February 2036 the time value overflows 😬. [RFC4330] describes a procedure to extend the time to 2104, and this procedure is MANDATORY to support.
TS Type(8 bits): specifies the timestamp type used.
TS Type | Value | Length
-----------+-------+--------
NTP-UTC-32 | 3 | 32 bits
Table 6.8: TS Type (Additions)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).
6.4. Timestamp Payload with Role Indicator (TR) 🎀
the TR payload has every field from the standard timestamp payload (T), plus a brand new field that says what the timestamp is for 🧠. TS Type tells you what kind of TS Value you're looking at, while TS Role tells you what the timestamp means. The TR payload is there to kill ambiguity when a MIKEY message carries several timestamp payloads (e.g., in the Ticket Policy) 💅.
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 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 Role6.5. ID Payload (ID) 🪪
for the ID payload, there's a new ID Type called byte string 🧶. It's meant for when the ID payload is used to identify a pre-shared key. Unlike the ID Types that already exist (URI, Network Access Identifier), the byte string has no encoding rules at all, so it's very much a no-rules-just-bytes situation 💀.
ID Type(8 bits): specifies the identifier type used.
ID Type | Value
------------+------
Byte string | 2
Table 6.10: ID Type (Additions)6.6. ID Payload with Role Indicator (IDR) 🌸
the IDR payload has all the fields from the standard identity payload (ID), plus a new field for the role of that ID payload 🦋. ID Type says what kind of ID Data you're getting, and ID Role says what the identity actually means. The IDR payload is there to cut down on ambiguity when a MIKEY message holds several identity payloads. The IDR payload MUST be used instead of the ID payload in all MIKEY-TICKET messages 🚨.
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 Role | Value
------------------------+------
Initiator (IDRi) | 1
Responder (IDRr) | 2
KMS (IDRkms) | 3
Pre-Shared Key (IDRpsk) | 4
Application (IDRapp) | 5
Table 6.11: ID RoleIDRapp is intended to specify the authorized Application IDs (see Sections 5.1.3 and 6.10) 🎯.
6.7. Cert Hash Payload (CHASH) 🔐
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.
Hash func | Value | Hash Length
----------+-------+------------
SHA-256 | 2 | 256 bits
Table 6.12: Hash func (Additions)The SHA-256 hash function is defined in [FIPS.180-3] ✨.
6.8. RAND Payload with Role Indicator (RANDR) ✨
okay so the RANDR payload is basically the regular RAND payload (RAND) with ONE extra field that tells you who made the RAND (the generating entity) 🎀 this is so things don't get confusing when a single MIKEY message has a bunch of RAND payloads in it 🫶
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 Role | Value
-------------------+------
Initiator (RANDRi) | 1
Responder (RANDRr) | 2
KMS (RANDRkms) | 3
Table 6.13: RAND Role6.9. Error Payload (ERR)
okay so for the key data sub-payload, there are NEW error types 🚨💅
- Error no (8 bits): indicates the type of error that was encountered.
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.10. Ticket Policy Payload (TP) / Ticket Payload (TICKET)
bestie, pay attention here 👑 the Ticket Policy payload (TP) and the Ticket Payload (TICKET) are TWO different payloads with different payload identifiers 🦋 but they share most of their structure, so they get described together in the same section 🌸
the Ticket Policy payload carries a desired Ticket Policy and does NOT have the Ticket Data length, Ticket Data, Initiator Data length, or Initiator Data fields 🙈 the ticket payload carries the granted Ticket Policy AND the Ticket Data (the default ticket type is defined in Appendix A) ✨ the Ticket Policy has info meant for everyone involved, while the Ticket Data is ONLY for the party that resolves the ticket 🔐 the Ticket Type inside the Ticket Data gets indicated in the Ticket Policy 💜 and when key forking is used (I flag), the Initiator Data authenticates the Initiator 🫶
the flags are NOT independent, so watch out 💀 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 🎀
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.
- Ticket Type (16 bits): specifies the Ticket Type used.
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 TypeSubtype = 0x01 and Version = 0x01 refers to the MIKEY Base Ticket as defined in this document 🧚
- Subtype (8 bits): specifies the ticket subtype used.
- Version (8 bits): specifies the ticket subtype version used.
- PRF Func (7 bits): specifies the PRF that SHALL be used for key forking.
- D (1 bit): flag to indicate whether the ticket was generated by the KMS ('1') or by the Initiator ('0').
- E (1 bit): flag to indicate whether the Ticket Resolve exchange is MANDATORY ('1') or if the Responder MAY resolve the ticket ('0').
- F (1 bit): flag to indicate whether the TRANSFER_RESP message SHALL be sent ('1') or if it SHALL NOT be sent ('0').
- G (1 bit): flag to indicate whether the Responder SHALL generate RANDRr ('1') or if the Responder SHALL NOT generate RANDRr ('0').
- H (1 bit): flag to indicate whether RANDRi SHALL be used when deriving keys from a TGK/GTGK ('1') or if RANDRi SHALL NOT be used ('0').
- I (1 bit): flag to indicate whether key forking SHALL be used ('1') or if key forking SHALL NOT be used ('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').
- 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.
- L (1 bit): flag to indicate whether the Initiator MAY supply session keys ('1') or if the Initiator SHALL NOT supply session keys ('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').
- 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.
- 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.
- Res (5 bits): reserved for future use.
- TP Data length (16 bits): length of TP Data (in bytes).
- 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 Data = First Payload, [IDRkms], [IDRi], [TRs],
[TRe], [TRr], [KEMAC], {IDRapp}, (IDRr)- IDRkms contains the identity of a KMS that can resolve the ticket.
- IDRi contains the identity of the peer that requested or created the ticket.
- 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.
- 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.
- 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.
- 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 = {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.
- 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.
- 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.
- Ticket Data length (16 bits): the length of the Ticket Data field (in bytes). Not present in the TP payload.
- Ticket Data (variable length): contains the Ticket Data. Not present in the TP payload.
- Initiator Data length (16 bits): the length of the Initiator Data field (in bytes). Not present in the TP payload.
- 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 identify the first payload. The rest of Initiator Data SHALL be constructed of MIKEY payloads. Unexpected payloads in the Initiator Data SHOULD be ignored.
Initiator Data = First Payload, Vi, VrThe Vi payload SHALL be identical to the V payload in the TRANSFER_INIT message.
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:
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)The constant depends on the derived key type as defined in Section 4.1.4 of [RFC3830].
7. Transport Protocols
okay now the transport bit 🚀 MIKEY messages are NOT tied to any specific transport protocol, so they're pretty flexible 🦋 [RFC4567] defines extensions for SDP and RTSP to carry MIKEY messages (and therefore MIKEY-TICKET messages) 🎀 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) 💖
BUT the MIKEY-TICKET exchanges that don't establish keying material for media sessions (Ticket Request and Ticket Resolve) might not be a good fit for SDP or RTSP 🙈 so if SDP or RTSP isn't used, the transport protocol needs to be defined 🌈 and in [3GPP.33.328], it's defined how the Ticket Request and Ticket Resolve exchanges are carried over HTTP 🍓✨
8. Pre-Encrypted Content 🎬
okay so the default is that the KMS hands over the session keys, tucked inside the ticket 🎟️. but that literally can't work when the content is already pre-encrypted, like Video on Demand 📺. in those cases the key exchange gets flipped around, and it MAY be done like this: the Initiator sends a ticket without encoded session keys to the Responder in a TRANSFER_INIT message. the Responder has access to the TEKs that protect the requested content, but it may not be streaming the content yet 🙈. so the Responder puts the TEK in a TRANSFER_RESP message, which goes back to the Initiator 💖.
+---+ +---+
| I | | R |
+---+ +---+
TRANSFER_INIT
---------------------------------------------------------------->
TRANSFER_RESP {KEMAC}
<----------------------------------------------------------------Figure 6: Distribution of pre-encrypted content
9. Group Communication 🫂
okay this part is so fun 🥹. everything we've covered so far can also be used for group communication! the MIKEY signaling for multi-party sessions can be centralized, like in Figure 7 ✨.
+---+ +---+ +---+
| A | | B | | C |
+---+ +---+ +---+
Ticket Transfer
<-------------------------------> Ticket Transfer
<--------------------------------------------------------------->Figure 7: Centralized signaling around party A
or it can be decentralized, like in Figure 8 🦋.
+---+ +---+ +---+
| A | | B | | C |
+---+ +---+ +---+
Ticket Transfer
<-------------------------------> Ticket Transfer
<------------------------------->Figure 8: Decentralized signaling
in the decentralized scenario, the identities of B and C SHALL be used in the second Ticket Transfer exchange. and no matter how the MIKEY signaling is done, a group key may be used as the session key 🔥.
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 the group key, the same RANDs MUST be used to derive the session keys in all Ticket Transfer exchanges. also, be careful with ticket reuse in group settings, as discussed in Section 5.3 🚨.
9.1. Key Forking 🔑
when key forking is used, only the user who requested the ticket can start a Ticket Transfer exchange with that ticket, see Section 5.3. so if a group key needs to be distributed, the MIKEY signaling MUST be centralized to the party that originally requested the ticket. the other option is to use different tickets in each Ticket Transfer exchange and send the group key in a KEMAC 💅.
another thing: different users get different session keys if TGKs (encoded in the ticket) are used 👀.
10. Signaling between Different KMSs 🌍
a user can generally only be expected to have a trust relation with a single KMS 🥺. so different users might end up with tickets from different KMSs, using only locally known keys. that means if users with trust relations to different KMSs want to set up a secure session with each other, the KMSs involved have to cooperate, and there has to be a trust relation between them too 🤝. the KMSs SHALL be mutually authenticated, and signaling between them SHALL be integrity and confidentiality protected. the technical means for inter-KMS security are outside the scope of this specification, though 🙃. under these assumptions, the following approach MAY be used.
+---+ +---+ +-------+ +-------+
| I | | R | | KMS R | | KMS I |
+---+ +---+ +-------+ +-------+
TRANSFER_INIT
--------------------> RESOLVE_INIT
- - - - - - - - - - -> RESOLVE_INIT
- - - - - - - - - - ->
RESOLVE_RESP
RESOLVE_RESP <- - - - - - - - - - -
TRANSFER_RESP < - - - - - - - - - -
<--------------------Figure 9: Routing of resolve messages
if the Responder cannot resolve a ticket directly, the ticket SHOULD be included in a RESOLVE_INIT message sent to a KMS 📨. if the Responder doesn't have a shared credential with the KMS that issued the ticket (KMS I), or if it doesn't know which KMS issued the ticket, the Responder SHOULD send the RESOLVE_INIT message to one of its trusted KMSs (KMS R). if KMS R didn't issue the ticket, KMS R normally wouldn't be able to resolve it directly, so it must hence ask another KMS to resolve it (typically the issuing KMS) 🔁.
the signaling between different KMSs MAY be done with a Ticket Resolve exchange, as shown in Figure 9. the IDRr and TICKET payloads from the previous RESOLVE_INIT message SHOULD be reused 💜. just note that IDRr can't be used to look up the pre-shared key or certificate 🙅♀️.
11. Adding New Ticket Types to MIKEY-TICKET 🧚
the Ticket Data (in the TICKET payload) could be a reference to information like keys, stored by the key management service. or it could contain all the information itself, or it could be a mix of both 🍓. for systems serving lots of users, the reference-only approach isn't ideal, because it would force the key management service to keep state for every issued ticket that's still valid 😩. tickets can carry many different types of information that help enforce usage policies, and those policies can be group policies or per-user policies ✨.
tickets may be transparent, meaning they can be resolved without contacting the KMS that generated them, or opaque, meaning the original KMS must be contacted. the ticket information SHOULD typically be integrity protected, and certain fields need confidentiality protection, especially the keys if they're explicitly included 🔐. other types of information may also need confidentiality protection for 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)), since this may allow multiple peers to resolve the ticket 🫶.
the Ticket Data MUST include information so 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 don't add any extra payloads or processing 📋. new Ticket Types SHOULD NOT change the processing for the Responder. if a new Ticket Type needs additional processing, it MUST be indicated in the Ticket Policy (N and O flags) 🚩. new specifications MUST specify which modes are supported, and whether any additional security considerations apply 🙏.
12. Security Considerations 💀
unless otherwise stated, the security considerations in [RFC3830] still apply. they have the notes on the security properties of the MIKEY protocol, key derivation functions, and other components 🔒. since some security properties depend on the specific Ticket Type, only the generic security considerations for the MIKEY-TICKET framework are discussed here.
this specification includes a large number of optional features, and that adds complexity to the general case 😵💫. protocol designers are strongly encouraged to establish strict profiles that define MIKEY-TICKET options (e.g., exchanges or message fields) that SHOULD or MUST be supported. those profiles should prevent unexpected consequences from compliant implementations with wildly different option sets. this is literally the difference between a secure system and a chaotic one, bestie 🚨💅
12.1. General 🔐
Okay bestie, so in addition to the Ticket Policy, the KMS MAY have its own set of policies (authorized key lengths, algorithms, etc.) that kinda get shared with the peers 💅 The KMS MAY also provide keying material to authorized intermediate nodes doing network functions (like transcoding services, recording services, and 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 🫶
In the standard MIKEY modes [RFC3830], the keys get generated by the Initiator (or by both peers in the Diffie-Hellman scheme) 🧚 If a bad PRNG (Pseudorandom Number Generator) is used, that's likely to make any key management protocol sensitive to different kinds of attacks, and MIKEY is no exception 💀 Since the choice of 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 🔥
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. So 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 📏
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. Kinda sounds like a defect, ngl 🙃 But in practice (for all reasonable values of k) it's 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 it would need access to 2^(n/2) sessions protected with equally many different keys using a single pair of RANDs. For typical values of n, that is 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 🔍
As the Responder MAY generate a RAND, the Ticket Transfer exchange can provide mutual freshness guarantee for all derived keys ✨
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 is 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. Main character rules, periodt 💅🔥
12.2. Key Forking 🔑
Okay so sometimes the TRANSFER_INIT message may be delivered to multiple endpoints 📨 For example, when a Responder is registered on several devices (e.g., mobile phone, fixed phone, and computer), or when an invite is being made to addresses of the type IT-support@example.com, which is 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 🙈
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) get 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 🫶
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, so use them with this in mind ⚠️ This also concerns session keys transferred in a KEMAC in the first TRANSFER_INIT (as they are protected with MPKi).
12.3. Denial of Service 🚫
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 👑
12.4. Replay 🔁
In a replay attack, an attacker may intercept and later retransmit the whole or part of a MIKEY message, trying 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 🔐
An attacker may also attempt to replay a ticket by inserting it into a new MIKEY message. A possible scenario: 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 🌸
12.5. Group Key Management 👯♀️
In a group scenario, only authorized group members must have access to the keys 🫂 Sometimes 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. So in a situation like this, it is foremost the responsibility of the KMS to reject ticket resolution requests from unauthorized responders, which means 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) 🧠
As noted, reuse of tickets, which bypasses the KMS, is NOT RECOMMENDED when the Initiator is not fully ensured about group membership status 🚨
13. Acknowledgements 🙏
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 🥰🫶
14. IANA Considerations ✨
okay so this section is all about IANA, the folks who keep the official registries, and it's giving organization 📋💖 this document adds a bunch of new values to 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, all defined in [RFC3830]. Every one of these lives in the MIKEY Payload registry, and the table you'll look at for each one is listed in parentheses:
- Data Type (see Table 6.1)
- Next Payload (see Table 6.2)
- PRF func (see Table 6.3)
- CS ID map type (see Table 6.4)
- Encr alg (see Table 6.5)
- MAC alg (see Table 6.6)
- TS Type (see Table 6.7)
- ID Type (see Table 6.9)
- Hash func (see Table 6.11)
- Error no (see Table 6.13)
- Key Data Type (see Table 6.14)
🎀 Next up is the TR payload, which has an 8-bit TS Role field. IANA made and will look after a brand new namespace for it inside the MIKEY Payload registry. Each assignment is a TS Role name paired with its value. Values in the range 1-239 SHOULD be approved through Specification Required, values 240-254 are Reserved for Private Use, and 0 and 255 are Reserved according to [RFC5226]. Here's how the registry starts out:
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 gets the same treatment with an 8-bit ID Role field and its own brand new registry in the MIKEY Payload registry. Assignments are an ID Role name plus its value. Same rules again: 1-239 SHOULD be approved by Specification Required, 240-254 are Reserved for Private Use, and 0 and 255 are Reserved according to [RFC5226]. The starting list looks like this:
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 has an 8-bit RAND Role field, and IANA again creates and maintains a new namespace for it in the MIKEY Payload registry. Assignments are a RAND Role name plus its value. Values in the range 1-239 SHOULD be approved by Specification Required, 240-254 are Reserved for Private Use, and 0 and 255 are Reserved according to [RFC5226]. Starting contents:
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🧚 Last one is the TP/TICKET payload, which has a 16-bit Ticket Type field. IANA sets up a new namespace for it in the MIKEY Payload registry, and assignments are a Ticket Type name plus its value. Values in the range 1-61439 SHOULD be approved by Specification Required, 61440-65534 are Reserved for Private Use, and 0 and 65535 are Reserved according to [RFC5226]. The initial registry:
Value Ticket Type
----------- -----------------
0 Reserved
1 MIKEY base ticket
2 3GPP base ticket
3-61439 Unassigned
61440-65534 Reserved for Private Use
65535 Reserved15. References
15.1. Normative References
These are the must-read ones 📚 Each one is listed with its label, author(s), title, and publication details:
- [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>. - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
- [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
- [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.
- [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.
- [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.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
15.2. Informative References
These ones are good background reading 🌈
- [3GPP.33.328] 3GPP, "IP Multimedia Subsystem (IMS) media plane security", 3GPP TS 33.328 9.3.0, December 2010.
- [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.
- [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.
- [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
- [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006.
- [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions", RFC 5197, June 2008.
- [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009.
Appendix A. MIKEY Base Ticket ✨
okay this is the big one for tickets 🎫 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. Here's the layout:
Ticket Data = THDR, T, RAND, KEMAC, [IDRpsk], VA.1. Components of the Ticket Data
💖 The Ticket Data MUST always begin with a Ticket Header payload (THDR). The ticket header is a brand new payload type, and you can find its definition in Appendix A.3.
🕰️ T is a timestamp holding the time of issue or a counter. It MAY be used in the IV (Initialization Vector) formation, for example as in Section 4.2.3 of [RFC3830].
🔑 RAND is the input to the key derivation function whenever keys are derived from the TPK and the MPK. See Appendices A.2.1 and A.2.2 for those.
The KEMAC payload SHALL use the NULL authentication algorithm, because a MAC is already 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'. So the KEMAC is built like this:
KEMAC = E(encr_key, MPK || {TEK|TGK|GTGK})MPKi and MPKr are derived from the MPK, as defined in Appendix A.2.2.
🙈 IDRpsk holds an identifier that lets the KMS/Responder retrieve the TPK. It MAY be omitted when the TPK can be retrieved anyhow.
🌟 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.
A.2. Key Derivation
The labels in the key derivations SHALL NOT include entire RAND payloads, only the fields RAND length and RAND from the corresponding payload.
A.2.1. Deriving Keys from a TPK ✨
Okay so this is where the keys actually get cooked 🔑 Keying material is derived from a TPK, and the derivation method SHALL be run with whatever PRF the Ticket Policy names. Here are the parameters:
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)Length RAND is the length of RAND in bytes, stored as an 8-bit unsigned integer. The constants come from Section 4.1.4 of [RFC3830] 💖 The whole key derivation, plus how it depends on the Ticket Data contents when AES-CM is used, is drawn out in Figure 10.
----- 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
So who does this math? Both the party that creates the ticket (KMS or Initiator) and the party that resolves it (KMS or Responder) run the derivation 🫶 The encryption key and the IV are then used to encrypt the KEMAC, which is the whole point of the dance 💅
A.2.2. Deriving MPKi and MPKr 🦋
Next up is how MPKi and MPKr get derived from the MPK sitting in the KEMAC payload. Same vibe as before: the key derivation method SHALL be run with the PRF the Ticket Policy indicates. The parameters are:
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_lenAgain, Length RAND is the length of RAND in bytes as an 8-bit unsigned integer. The constant you use depends on which derived key you're making, so check the table below 👀
Derived key | Constant
------------+-----------
MPKi | 0x220E99A2
MPKr | 0x1F4D675B
Table A.1: Constants for MPK key derivationThe constants are taken from the decimal digits of e, as described in [RFC3830]. Iconic math moment 🧚
A.3. Ticket Header Payload (THDR) 🎀
The ticket header payload is where the next payload gets flagged, along with some implementation-specific data. Here's the layout:
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.
- THDR Data length (16 bits): the length of the THDR Data field, in bytes.
- THDR Data (variable length): implementation-specific data that SHOULD be ignored if it is not expected. 🙈
Appendix B. Alternative Use Cases 🌈
B.1. Compatibility Mode 🍓
MIKEY-TICKET can be used to define a Ticket Type that's compatible with [RFC3830], or with any other half-round-trip key management protocol. Here's the flow: the Initiator requests and gets a ticket from the KMS, and the Ticket Data is a [RFC3830] message protected either with a pre-shared key (KMS-Responder) or with the Responder's certificate. The Ticket Data then goes to the Responder according to [RFC3830]. Result? The Initiator can talk to a Responder that only supports [RFC3830], even when the two of them don't have any shared credentials. Main character energy, honestly 👑
+---+ +-----+ +---+
| I | | KMS | | R |
+---+ +-----+ +---+
REQUEST_INIT
-------------------------------->
REQUEST_RESP
<--------------------------------
3830 MIKEY
---------------------------------------------------------------->Figure 11: Compatibility mode
Authors' Addresses 💜
John Mattsson
Ericsson AB
SE-164 80 Stockholm
Sweden
Phone: +46 10 71 43 501
EMail: john.mattsson@ericsson.com
Tian Tian
ZTE Corporation
4F, RD Building 2, Zijinghua Road
Yuhuatai District, Nanjing 210012
P.R. China
Phone: +86-025-5287-7867
EMail: tian.tian1@zte.com.cn📦 where this page comes from
- ietf: rfc6043 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms