RFC 6043
MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
7. Transport Protocols
MIKEY messages are not tied to any specific transport protocols. In [RFC4567], extensions for SDP and RTSP to carry MIKEY messages (and therefore MIKEY-TICKET messages) are defined. The messages in the Ticket Transfer exchange (TRANSFER_INIT, TRANSFER_RESP) are preferably included in the session setup signaling (e.g., SIP INVITE and 200 OK). However, it may not be suitable for the MIKEY-TICKET exchanges that do not establish keying material for media sessions (Ticket Request and Ticket Resolve) to be carried in SDP or RTSP. If SDP or RTSP is not used, the transport protocol needs to be defined. In [3GPP.33.328], it is defined how the Ticket Request and Ticket Resolve exchanges are carried over HTTP.8. Pre-Encrypted Content
The default setting is that the KMS supplies the session keys (encoded in the ticket). This is not possible if the content is pre- encrypted (e.g., Video on Demand). In such use cases, the key
exchange is typically reversed and MAY be carried out as follows. The Initiator sends a ticket without encoded session keys to the Responder in a TRANSFER_INIT message. The Responder has access to the TEKs used to protect the requested content, but may not be streaming the content. The Responder includes the TEK in the TRANSFER_RESP message, which is sent to the Initiator. +---+ +---+ | I | | R | +---+ +---+ TRANSFER_INIT ----------------------------------------------------------------> TRANSFER_RESP {KEMAC} <---------------------------------------------------------------- Figure 6: Distribution of pre-encrypted content9. Group Communication
What has been discussed up to now can also be used for group communication. The MIKEY signaling for multi-party sessions can be centralized as illustrated in Figure 7. +---+ +---+ +---+ | A | | B | | C | +---+ +---+ +---+ Ticket Transfer <-------------------------------> Ticket Transfer <---------------------------------------------------------------> Figure 7: Centralized signaling around party A or decentralized as illustrated 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. Independent of the how the MIKEY signaling is done, a group key may be used as 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 a group key, the same RANDs MUST be used to derive the session keys in all Ticket Transfer exchanges. Also note caveats with ticket reuse in group communication settings as discussed in Section 5.3.9.1. Key Forking
When key forking is used, only the user that requested the ticket can initiate a Ticket Transfer exchange using that ticket, see Section 5.3. So if a group key is to be distributed, the MIKEY signaling MUST be centralized to the party that initially requested the ticket, or different tickets needs to be used in each Ticket Transfer exchange and the group key needs to be sent in a KEMAC. Another consideration is that different users get different session keys if TGKs (encoded in the ticket) are used.10. Signaling between Different KMSs
A user can in general only be expected to have a trust relation with a single KMS. Different users might therefore use tickets issued by different KMSs using only locally known keys. Thus, if users with trust relations to different KMSs are to be able to establish a secure session with each other, the KMSs involved have to cooperate and there has to be a trust relation between them. The KMSs SHALL be mutually authenticated and signaling between them SHALL be integrity and confidentiality protected. The technical means for the inter-KMS security is however outside the scope of this specification. Under these assumptions, the following approach MAY be used. +---+ +---+ +-------+ +-------+ | 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 directly resolve a ticket, the ticket SHOULD be included in a RESOLVE_INIT message sent to a KMS. If the Responder does not have a shared credential with the KMS that issued the ticket (KMS I) or if the Responder does not know which KMS issued the ticket, the Responder SHOULD send the RESOLVE_INIT message to one of the Responder's trusted KMSs (KMS R). If KMS R did not issue the ticket, KMS R would normally be unable to directly resolve the ticket and must hence ask another KMS to resolve it (typically the issuing KMS). The signaling between different KMSs MAY be done with a Ticket Resolve exchange as illustrated in Figure 9. The IDRr and TICKET payloads from the previous RESOLVE_INIT message SHOULD be reused. Note that IDRr cannot be used to look up the pre-shared key/ certificate.11. Adding New Ticket Types to MIKEY-TICKET
The Ticket Data (in the TICKET payload) could be a reference to information (keys, etc.) stored by the key management service, it could contain all the information itself, or it could be a combination of the two alternatives. For systems serving many users, it is not ideal to use the reference-only ticket approach as this would force the key management service to keep state of all issued tickets that are still valid. Tickets may carry many different types of information helping to enforce usage policies. The policies may be group policies or per-user policies. Tickets may either be transparent, meaning they can be resolved without contacting the KMS that generated them, or opaque, meaning that the original KMS must be contacted. The ticket information SHOULD typically be integrity protected and certain fields need confidentiality protection, in particular, the keys if explicitly included. Other types of information may also require confidentiality protection due to privacy reasons. In mode 2 (see Section 4.1.1), it may be preferable to include several encrypted ticket protection keys (similar to Secure/Multipurpose Internet Mail Extensions (S/MIME)) as this may allow multiple peers to resolve the ticket. The Ticket Data MUST include information so that the resolving party can retrieve an encoded KEMAC. It MUST also be possible to verify the integrity of the TICKET payload. It is RECOMMENDED that future specifications use the recommended payload order and do not add any additional payloads or processing. New Ticket Types SHOULD NOT change the processing for the Responder. If a new Ticket Type
requires additional processing, it MUST be indicated in the Ticket Policy (N and O flags). New specifications MUST specify which modes are supported and if any additional security considerations apply.12. Security Considerations
Unless otherwise stated, the security considerations in [RFC3830] still apply and contain notes on the security properties of the MIKEY protocol, key derivation functions, and other components. As some security properties depend on the specific Ticket Type, only generic security considerations concerning the MIKEY-TICKET framework are discussed. This specification includes a large number of optional features, which adds complexity to the general case. Protocol designers are strongly encouraged to establish strict profiles defining MIKEY- TICKET options (e.g., exchanges or message fields) that SHOULD or MUST be supported. Such profiles should preclude unexpected consequences from compliant implementations with wildly differing option sets.12.1. General
In addition to the Ticket Policy, the KMS MAY have its own set of policies (authorized key lengths, algorithms, etc.) that in some way are shared with the peers. The KMS MAY also provide keying material to authorized intermediate nodes performing various network functions (e.g., transcoding services, recording services, conference bridges). The key management service can enforce end-to-end security by only distributing the keys to authorized end-users. As in [RFC3830], the user identities are not confidentiality protected. If user privacy is needed, some kind of Privacy Enhancing Technologies (PET) like anonymous or temporary credentials MAY be used. In the standard MIKEY modes [RFC3830], the keys are generated by the Initiator (or by both peers in the Diffie-Hellman scheme). If a bad PRNG (Pseudorandom Number Generator) is used, this is likely to make any key management protocol sensitive to different kinds of attacks, and MIKEY is no exception. As the choice of the PRNG is implementation specific, the easiest (and often bad) choice is to use the PRNG supplied by the operating system. In MIKEY-TICKET's default mode of operation, the key generation is mostly done by the KMS, which can be assumed to be less likely to use a bad random number generator. All keys (including keys used to protect the ticket) MUST have adequate strength/length, i.e., 128 bits or more.
The use of random nonces (RANDs) in the key derivation is of utmost importance to counter offline pre-computation attacks and other generic attacks. A key of length n, using RANDs of length r, has effective key entropy of (n + r) / 2 against a birthday attack. Therefore, the sum of the lengths of RANDRi and RANDRr MUST at least be equal to the size of the longest pre-shared key/envelope key/MPK/ TGK/GTGK, RANDRkms MUST at least be as long as the longest MPKr/TGK, and the RAND in the MIKEY base ticket MUST at least be as long as the longest of TPK and MPK. Note that the CSB Updating messages reuse the old RANDs. This means that the total effective key entropy (relative to pre-computation attacks) for k consecutive key updates, assuming the TGKs are each n bits long, is still no more than n bits. In other words, the time and memory needed by an attacker to get all k n-bit keys are proportional to 2^n. While this might seem like a defect, this is in practice (for all reasonable values of k) not better than brute force, which on average requires k * 2^(n-1) work (even if different RANDs would be used). A birthday attack would only require 2^(n/2) work, but would need access to 2^(n/2) sessions protected with equally many different keys using a single pair of RANDs. This is, for typical values of n, clearly totally infeasible. The success probability of such an attack can be controlled by limiting the number of updates correspondingly. As stated in [RFC3830], the fact that more than one key can be compromised in a single attack is inherent to any solution using secret- or public-key algorithms. An attacker always gets access to all the exchanged keys by doing an exhaustive search on the pre-shared key/envelope key/MPK. This requires 2^m work, where m is the effective size of the key. 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 are supported, the other two algorithms SHALL also be supported. The 256-bit algorithms SHOULD be used together, and they SHALL NOT be mixed with algorithms using key sizes less than 256 bits. If session keys (TEK/TGK/GTGK) longer than 128 bits are used, 128-bit algorithms SHALL NOT be used.12.2. Key Forking
In some situations, the TRANSFER_INIT message may be delivered to multiple endpoints. For example, when a Responder is registered on several devices (e.g., mobile phone, fixed phone, and computer) or when an invite is being made to addresses of the type
IT-support@example.com, a group of users where only one is supposed to answer. The Initiator may not even always know exactly who the authorized group members are. To prevent all forms of eavesdropping, entities other than the endpoint that answers MUST NOT get access to the session keys. When key forking is not used, keys are accessible by everyone that can resolve the ticket. When key forking is used, some keys (MPKr and TGKs encoded in the ticket) are modified, making them cryptographically unique for each responder targeted by the forking. As only the Initiator and the KMS have access to the master TGKs, it is infeasible for anyone else to derive the session keys. When key forking is used, some keys (MPKi and TEKs and GTGK encoded in the ticket) are still accessible by everyone that can resolve the ticket and should be used with this in mind. This also concerns session keys transferred in a KEMAC in the first TRANSFER_INIT (as they are protected with MPKi).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, attempting to trick the receiver (Responder or KMS) into undesired operations, e.g., leading to a lack of key freshness. MIKEY-TICKET implements several mechanisms to prevent and detect such attacks. Timestamps together with a replay cache efficiently stop the replay of entire MIKEY messages. Parts of the received messages (or their hashes) can be saved in the replay cache until their timestamp is outdated. To prevent replay attacks, the sender's (Initiator or Responder) and the receiver's (Responder or KMS) identity is always (explicitly or implicitly) included in the MAC/Signature calculation.
An attacker may also attempt to replay a ticket by inserting it into a new MIKEY message. A possible scenario is that Alice and Bob first communicate based on a ticket, which an attacker Mallory intercepts. Later, Mallory (acting as herself) invites Bob by inserting the ticket into her own TRANSFER_INIT message. If key forking is used, such replays will always be detected when Bob has resolved the ticket. If key forking is not used, such replays will be detected unless Mallory has knowledge of the MPKi. And if Mallory has knowledge of the MPKi (i.e., she is authorized to resolve the ticket) and key forking is not used, there is no attack. For the reasons explained above, it is RECOMMENDED to use key forking.12.5. Group Key Management
In a group scenario, only authorized group members must have access to the keys. In some situation, the communication may be initiated by the Initiator using a group identity and the Initiator may not even know exactly who the authorized group members are. Moreover, group membership may change over time due to leaves/joins. In such a situation, it is foremost the responsibility of the KMS to reject ticket resolution requests from unauthorized responders, implying that the KMS needs to be able to map an individual's identity (carried in the RESOLVE_INIT message) to group membership (where the group identity is carried in the ticket). 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
This document defines several new values for the namespaces Data Type, Next Payload, PRF func, CS ID map type, Encr alg, MAC alg, TS Type, ID Type, Hash func, Error no, and Key Data Type defined in [RFC3830]. The following IANA assignments were added to the MIKEY Payload registry (in parentheses is a reference to the table containing the registered values): o Data Type (see Table 6.1) o Next Payload (see Table 6.2)
o PRF func (see Table 6.3) o CS ID map type (see Table 6.4) o Encr alg (see Table 6.5) o MAC alg (see Table 6.6) o TS Type (see Table 6.7) o ID Type (see Table 6.9) o Hash func (see Table 6.11) o Error no (see Table 6.13) o Key Data Type (see Table 6.14) The TR payload defines an 8-bit TS Role field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of a TS Role name and its associated value. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are Reserved for Private Use, and the values 0 and 255 are Reserved according to [RFC5226]. The initial contents of the registry are as follows: Value TS Role ------- ------------------------------ 0 Reserved 1 Time of issue (TRi) 2 Start of validity period (TRs) 3 End of validity period (TRe) 4 Rekeying interval (TRr) 5-239 Unassigned 240-254 Reserved for Private Use 255 Reserved The IDR payload defines an 8-bit ID Role field for which IANA has created and will maintain a new namespace in the MIKEY Payload registry. Assignments consist of an ID Role name and its associated value. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are Reserved for Private Use, and the values 0 and 255 are Reserved according to [RFC5226]. The initial contents of the registry are as follows:
Value ID Role
------- -----------------------
0 Reserved
1 Initiator (IDRi)
2 Responder (IDRr)
3 KMS (IDRkms)
4 Pre-Shared Key (IDRpsk)
5 Application (IDRapp)
6-239 Unassigned
240-254 Reserved for Private Use
255 Reserved
The RANDR payload defines an 8-bit RAND Role field for which IANA has
created and will maintain a new namespace in the MIKEY Payload
registry. Assignments consist of a RAND Role name and its associated
value. Values in the range 1-239 SHOULD be approved by the process
of Specification Required, values in the range 240-254 are Reserved
for Private Use, and the values 0 and 255 are Reserved according to
[RFC5226]. The initial contents of the registry are as follows:
Value RAND Role
------- ------------------
0 Reserved
1 Initiator (RANDRi)
2 Responder (RANDRr)
3 KMS (RANDRkms)
4-239 Unassigned
240-254 Reserved for Private Use
255 Reserved
The TP/TICKET payload defines a 16-bit Ticket Type field for which
IANA has created and will maintain a new namespace in the MIKEY
Payload registry. Assignments consist of a Ticket Type name and its
associated value. Values in the range 1-61439 SHOULD be approved by
the process of Specification Required, values in the range 61440-
65534 are Reserved for Private Use, and the values 0 and 65535 are
Reserved according to [RFC5226]. The initial contents of the
registry are as follows:
Value Ticket Type
----------- -----------------
0 Reserved
1 MIKEY base ticket
2 3GPP base ticket
3-61439 Unassigned
61440-65534 Reserved for Private Use
65535 Reserved
15. References
15.1. Normative References
[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
[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
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. 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 new payload type; for the definition, see Appendix A.3. T is a timestamp containing the time of issue or a counter. It MAY be used in the IV (Initialization Vector) formation (e.g., Section 4.2.3 of [RFC3830]). RAND is used as input to the key derivation function when keys are derived from the TPK and the MPK (see Appendices A.2.1 and A.2.2). The KEMAC payload SHALL use the NULL authentication algorithm, as a MAC is included in the V payload. The encryption key (encr_key) and salting key (salt_key) SHALL be derived from the TPK (see Appendix A.2.1). Depending on the encryption algorithm, the salting key be used in the IV creation (see Section 4.2.3 of [RFC3830]). If CSB ID is needed in the IV creation it SHALL be set to '0xFFFFFFFF'. The KEMAC is hence constructed as follows: KEMAC = E(encr_key, MPK || {TEK|TGK|GTGK}) MPKi and MPKr are derived from the MPK as defined in Appendix A.2.2. IDRpsk contains an identifier that enables the KMS/Responder to 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
In the following, we describe how keying material is derived from a TPK. The key derivation method SHALL be executed using the PRF indicated in the Ticket Policy. The parameters for the PRF are: 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 as an 8-bit unsigned integer. The constants are as defined in Section 4.1.4 of [RFC3830]. The key derivation and its dependencies on Ticket Data contents when AES-CM is used are illustrated in Figure 10. The key derivation is done by the party that creates the ticket (KMS or Initiator) and by the party that resolves the ticket (KMS or Responder). The encryption key and the IV are used to encrypt the KEMAC. ----- 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
A.2.2. Deriving MPKi and MPKr
In the following, we describe how MPKi and MPKr are derived from the MPK in the KEMAC payload. The key derivation method SHALL be executed using the PRF indicated in the Ticket Policy. The parameters for the PRF are: inkey: : MPK inkey_len : bit length of the inkey label : constant || 0xFF || 0xFFFFFFFF || 0x06 || length RAND || RAND outkey_len : desired bit length of the outkey (MPKi, MPKr) SHALL be equal to inkey_len Length RAND is the length of RAND in bytes as an 8-bit unsigned integer. The constant depends on the derived key type as summarized below. Derived key | Constant ------------+----------- MPKi | 0x220E99A2 MPKr | 0x1F4D675B Table A.1: Constants for MPK key derivation The constants are taken from the decimal digits of e as described in [RFC3830].A.3. Ticket Header Payload (THDR)
The ticket header payload contains an indicator of the next payload as well as implementation-specific data. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! THDR Data length ! THDR Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next Payload (8 bits): identifies the payload that is added after this payload. * 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 compatible with [RFC3830] or any other half-round-trip key management protocol. The Initiator requests and gets a ticket from the KMS where the Ticket Data is a [RFC3830] message protected with a pre-shared key (KMS-Responder) or with the Responder's certificate. The Ticket Data is then sent to the Responder according to [RFC3830]. In this way, the Initiator can communicate with a Responder that only supports [RFC3830] and with whom the Initiator do not have any shared credentials. +---+ +-----+ +---+ | I | | KMS | | R | +---+ +-----+ +---+ REQUEST_INIT --------------------------------> REQUEST_RESP <-------------------------------- 3830 MIKEY ----------------------------------------------------------------> Figure 11: Compatibility modeAuthors' 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