RFC 6043
MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
5. Key Management Functions
5.1. Key Derivation
For all messages in the Ticket Request and Ticket Resolve exchanges, the keys used to protect the MIKEY messages are derived from a pre- shared key or an envelope key. As crypto sessions SHALL NOT be handled, further keying material (i.e., TEKs) does not have to be derived. In the Ticket Transfer exchange, the keys used to protect the MIKEY messages are derived from an MPK. If key forking is used, the KMS and the Initiator SHALL fork the MPKr and the TGKs (encoded in the ticket) based on a modifier, and different MPKs (MPKi and MPKr') SHALL be used to protect the TRANSFER_INIT and TRANSFER_RESP messages. In addition, the Responder MAY generate a RAND used to give Responder key freshness guarantee. The key hierarchy and its dependencies on TRANSFER_INIT message contents for the case without key forking and RANDRr are illustrated in Figure 4. The KEMAC shown is the KEMAC sent from the KMS to the Initiator and the Responder. The illustrated key derivations are done by the Initiator and the Responder.
+------+------------------+-----+------+ 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 illustrated in Figure 5. The KEMAC shown is the KEMAC sent from the KMS to the Initiator. MOD is the modifier (IDRr, RANDRkms). The two key derivations that produce forked keys are done by the Initiator and the KMS, and the remaining two key derivations are done by the Initiator and the Responder. The random value RANDRi from the TRANSFER_INIT message is used as input to the derivation of the auth_key and may be used as input to the derivation of the TEK, but this is omitted from the figure. The protection of the TRANSFER_INIT message is done as in Figure 4.
+------+--------------------------+-----+------+ 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_len
where the ID Data field is taken from the IDRr payload sent in the
RESOLVE_RESP and TRANSFER_RESP messages. Length ID Data is the
length of the ID Data field in bytes as a 16-bit unsigned integer.
Length RANDRkms is the length of RANDRkms in bytes as an 8-bit
unsigned integer. The constant depends on the derived key type as
summarized below.
Derived key | Constant
------------+-----------
MPKr' | 0x2B288856
TGK' | 0x1512B54A
Table 5.1: Constants for forking key derivation
The 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 used to protect the MIKEY
messages. For the Ticket Request and Ticket Resolve exchanges, the
keys used to protect the MIKEY messages are derived from a pre-shared
key or an envelope key. For the Ticket Transfer exchange, the keys
are derived from an MPK. If key forking is used, different MPKs
(MPKi and MPKr') SHALL be used to protect the TRANSFER_INIT and
TRANSFER_RESP messages. The initial messages SHALL be protected with
keys derived using the following parameters:
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
Similar to [RFC3830], MIKEY-TICKET provides a means of updating the CSB (Crypto Session Bundle), e.g., transporting a new TEK/TGK/GTGK or adding new crypto sessions. The CSB updating is done by executing the Ticket Transfer exchange again, e.g., before a TEK expires or when a new crypto session is needed. The CSB updating can be started by the Initiator: Initiator Responder TRANSFER_INIT = ----> HDR, T, [IDRi], [IDRr], {SP}, [KEMAC], V < - - TRANSFER_RESP = HDR, T, [IDRr], {SP}, [KEMAC], V The CSB updating can also be started by the Responder: Responder Initiator TRANSFER_INIT = ----> HDR, T, [IDRr], [IDRi], {SP}, [KEMAC], V < - - TRANSFER_RESP = HDR, T, [IDRi], {SP}, [KEMAC], V The new message exchange MUST use the same CSB ID as the initial exchange but MUST use new timestamps. The crypto sessions negotiation (#CS field, CS ID map info field, and SP payloads) are handled as in the initial exchange. In the TRANSFER_INIT message the V flag SHALL be used to indicate whether or not a response message is expected. Static payloads such as RANDRi, RANDRr, RANDRkms, and TICKET that were provided in the initial exchange SHOULD NOT be included unless they are needed by a specific use case. New RANDs or TICKETs MUST NOT be included. The reason that new RANDs SHALL NOT be used is that if several TGKs are used, the peers would need to keep track of which RANDs to use for each TGK. This adds unnecessary complexity. Both messages SHALL be protected with the same keys (derived from MPKi or MPKr') that protected the last message (TRANSFER_INIT or TRANSFER_RESP) in the initial exchange.
New keying material MAY be sent in a KEMAC payload. If indicated by the Ticket Policy (L and M flags), KEMAC payloads SHALL NOT be included. In the TRANSFER_RESP message, a session key MUST be provided for each crypto session. The KEMAC SHALL use the NULL authentication algorithm, as a MAC is included in the V payload. The encr_key (and salt_key) SHALL be derived from the MPK (MPKi or MPKr'). Depending on the encryption algorithm, the salting key may go into the IV (see [RFC3830]). If a new TGK is exchanged, it SHALL NOT be forked. The KEMAC is hence constructed as follows: KEMAC = E(encr_key, (TEK|TGK|GTGK))5.3. Ticket Reuse
MIKEY-TICKET includes features aiming to offload the KMS from receiving ticket requests. One such feature is that tickets may be reused. This means that a user may request a ticket for media sessions with another user and then under the ticket's validity period use this ticket to protect several media sessions with that user. When reusing a ticket that has been used in a previous Ticket Transfer exchange, a new Ticket Transfer exchange is executed. The new exchange MUST use a new CSB ID, a new timestamp, and new RANDs (RANDRi, RANDRr). If the Responder has resolved the ticket before, the Responder does not need to resolve the ticket again. In that case, the same modifier (IDRr, RANDRkms) SHALL be used. If the Ticket Policy forbids reuse (J flag), the ticket MUST NOT be reused. Note that such reuse cannot be detected by a stateless KMS. When group keys are used, ticket reuse leaves the Initiator responsible to ensure that group membership has not changed since the ticket was last used. (Otherwise, unauthorized responders may gain access to the group communication.) Thus, if group dynamics are difficult to verify, the Initiator SHOULD NOT initiate ticket reuse. When key forking is used, only the user that requested the ticket has access to the encoded master keys (MPKr, TGKs). Because of this, no one else can initiate a Ticket Transfer exchange using the ticket.5.4. Error Handling
If a fatal error occurs during the parsing of a message, the message SHOULD be discarded, and an Error message SHOULD be sent to the other party (Initiator, Responder, KMS). If a failure is due to the inability to authenticate the peer, the message SHALL be discarded, the Error message is OPTIONAL, and the caveats in Section 5.1.2 of [RFC3830] apply. Error messages may be used to report errors in both initial and response messages, but not in Error messages.
In the Ticket Request and Ticket Resolve exchanges, the Error message
MAY be authenticated with a MAC or a signature. The Error message is
hence constructed as follows:
Error message = HDR, T, (ERR), [V|SIGNx]
where x is in the set {i, r, kms} (Initiator, Responder, KMS).
Unexpected payloads in the Error message SHOULD be ignored.
In the Ticket Transfer exchange, the Error message MAY be
authenticated with a MAC. If the suggested security policies are not
supported, the Error message SHOULD include the supported parameters.
The Error message is hence constructed as follows:
Error message = HDR, T, (ERR), {SP}, [V]
In Error messages, the version, PRF func, and CSB ID fields in the
HDR payload SHALL be identical to the corresponding fields in the
message where the error occurred. The V field SHALL be set to '0'
and be ignored.
If one of the NTP timestamp types is used, a fresh timestamp value
SHALL be used. If the COUNTER timestamp type (see Section 6.6 of
[RFC3830]) is used, the timestamp value MAY be equal to the one in
the message where the error occurred.
The MAC/Signature in the V/SIGN payloads covers the entire Error
message, except the MAC/Signature field itself. The auth_key SHALL
be the same as in the message where the error occurred.
5.5. MAC/Signature Coverage
The MAC/Signature in the V/SIGN payloads covers the entire MIKEY
message, except the MAC/Signature field itself. For initial
messages, the identities (not whole payloads) of the parties involved
MUST directly follow the MIKEY message in the Verification MAC/
Signature calculation. In the TRANSFER_INIT message, the MAC SHALL
NOT cover the Initiator Data length and Initiator Data fields in the
TICKET payload. Note that in the Transfer Exchange, Identity_r in
TRANSFER_RESP (e.g., user1@example.com) MAY differ from that
appearing in TRANSFER_INIT (e.g., IT-support@example.com). For
response messages, the entire initial message (including the MAC/
Signature field) MUST directly follow the MIKEY message in the
Verification MAC/Signature calculation (the identities are implicitly
covered as they are covered by the initial message's MAC/Signature).
Message type | MAC/Signature coverage --------------+-------------------------------------------- REQUEST_INIT | REQUEST_INIT || Identity_i || Identity_kms REQUEST_RESP | REQUEST_RESP || REQUEST_INIT TRANSFER_INIT | TRANSFER_INIT || Identity_i || Identity_r TRANSFER_RESP | TRANSFER_RESP || TRANSFER_INIT RESOLVE_INIT | RESOLVE_INIT || Identity_r || Identity_kms RESOLVE_RESP | RESOLVE_RESP || RESOLVE_INIT Error message | Error message Table 5.2: MAC/Signature coverage6. Payload Encoding
This section does not describe all the payloads that are used in the new message types. It describes in detail the new TR, IDR, RANDR, TP, and TICKET payloads. For the other payloads, only the additions and changes compared to [RFC3830] are described. For a detailed description of the other MIKEY payloads, see [RFC3830]. Note that the fields with variable length are byte aligned and not 32-bit aligned.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 message Table 6.1: Data Type (Additions)
* Next Payload (8 bits): identifies the payload that is added after
this payload.
Next Payload | Value | Section
-------------+-------+--------
TR | 13 | 6.4
IDR | 14 | 6.6
RANDR | 15 | 6.8
TP | 16 | 6.10
TICKET | 17 | 6.10
Table 6.2: Next Payload (Additions)
* V (1 bit): flag to indicate whether a response message is expected
('1') or not ('0'). It MUST be set to '0' and ignored in all
messages except TRANSFER_INIT messages used for CSB updating (see
Section 5.2).
* PRF func (7 bits): indicates the PRF function that has been/will
be used for key derivation. Besides the PRFs already defined in
[RFC3830] the following additional PRF may be used.
PRF func | Value
-----------------+------
PRF-HMAC-SHA-256 | 1
Table 6.3: PRF func (Additions)
The new PRF SHALL be constructed as described in Section 4.1.2 of
[RFC3830] with the differences that HMAC-SHA-256 (see Section 6.2)
SHALL be used instead of HMAC-SHA-1 and the value 256 SHALL be used
instead of 160. This corresponds to the full output length of
SHA-256.
* #CS (8 bits): indicates the number of crypto sessions in the CS ID
map info.
* CS ID map type (8 bits): specifies the method of uniquely mapping
crypto sessions to the security protocol sessions. In the Ticket
Transfer exchange the new GENERIC-ID map type, which is intended
to eliminate the limitations with the existing SRTP-ID map type,
SHOULD be used. The map type SRTP-ID SHALL NOT be used.
CS ID map type | Value
----------------------
GENERIC-ID | 2
Table 6.4: CS ID map type (Additions)
* CS ID map info (variable length): identifies and maps the crypto
sessions to the security protocol sessions for which security
associations should be created.
6.1.1. The GENERIC-ID Map Type
For the GENERIC-ID map type, the CS ID map info consists of #CS
number of blocks, each mapping policies, session data (e.g., SSRC),
and key to a specific crypto session.
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, #P SHALL always be
exactly 1. So if #P = 0 in an initial message, a security profile
MUST be provided in the response message. If #P > 0, one of the
suggested policies SHOULD be chosen in the response message. If
needed (e.g., in group communication, see Section 9), the
suggested policies MAY be changed.
* Ps (variable length): lists the policies for the crypto session.
It SHALL contain exactly #P policies, 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. The S flag 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)
For the KEMAC payload, new encryption and authentication algorithms
are defined.
* 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, new types of keys are defined. The
Group TGK (GTGK) is used as a regular TGK, with the difference that
it SHALL NOT be forked. It is intended to enable the establishment
of a group TGK when key forking is used. The MIKEY Protection Key
(MPK) is used to protect the MIKEY messages in the Ticket Transfer
exchange. The MPK is used as the pre-shared key in the pre-shared
key method of [RFC3830]; however, it is not known by the Responder
before the ticket has been resolved.
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, a new type of timestamp is defined. The new type is intended to be used when defining validity periods, where fractions of seconds seldom matter. The NTP-UTC-32 string contains four bytes, in the same format as the first four bytes in the NTP timestamp format, defined in [RFC4330]. This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 7 February 2036, the time value will overflow. [RFC4330] describes a procedure to extend the time to 2104 and this procedure is MANDATORY to support. * 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 uses all the fields from the standard timestamp payload (T) but expands it with a new field describing the role of the timestamp. Whereas the TS Type describes the type of the TS Value, the TS Role describes the meaning of the timestamp itself. The TR payload is intended to eliminate ambiguity when a MIKEY message contains several timestamp payloads (e.g., in the Ticket Policy). 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, a new ID Type byte string is defined. The byte string type is intended to be used when the ID payload is used to identify a pre-shared key. Contrary to the previously defined ID Types (URI, Network Access Identifier), the byte string does not have any encoding rules. * ID 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 uses all the fields from the standard identity payload (ID) but expands it with a new field describing the role of the ID payload. Whereas the ID Type describes the type of the ID Data, the ID Role describes the meaning of the identity itself. The IDR payload is intended to eliminate ambiguity when a MIKEY message contains several identity payloads. The IDR payload MUST be used instead of the ID payload in all MIKEY-TICKET messages. 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 Role IDRapp 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)
The RANDR payload uses all the fields from the standard RAND payload (RAND) but expands it with a new field describing the role (the generating entity) of the RAND. The RANDR payload is intended to eliminate ambiguity when a MIKEY message contains several RAND payloads. 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)
For the key data sub-payload, new types of errors are defined. * 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)
Note that the Ticket Policy payload (TP) and the Ticket Payload (TICKET) are two different payloads (having different payload identifiers). However, as they share much of the payload structure, they are described in the same section. The Ticket Policy payload contains a desired Ticket Policy and does not include the Ticket Data length, Ticket Data, Initiator Data length, or Initiator Data fields. The ticket payload contains the granted Ticket Policy as well as Ticket Data (the default ticket type is defined in Appendix A). The Ticket Policy contains information intended for all parties involved whereas the Ticket Data is only intended for the party that resolves the ticket. The Ticket Type provided in the Ticket Data is indicated in the Ticket Policy. When key forking is used (I flag), the Initiator Data authenticates the Initiator. Note that the flags are not independent: NOT D implies L, G implies F, NOT G implies H, NOT H implies G, I implies E, K implies D, and M implies F. The F flag SHALL be set to '1' when the I flag (key forking) is set to '1' and a TGK is encoded in the ticket.
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 Type Subtype = 0x01 and Version = 0x01 refers to 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 identifies 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, Vr
The 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].
(page 43 continued on part 3)
