Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 3830


MIKEY: Multimedia Internet KEYing

Part 2 of 4, p. 15 to 32
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 15 
4.  Selected Key Management Functions

   MIKEY manages symmetric keys in two main ways.  First, following key
   transport or key exchange of TGK(s) (and other parameters) as defined
   by any of the above three methods, MIKEY maintains a mapping between
   Data SA identifiers and Data SAs, where the identifiers used depend
   on the security protocol in question, see Section 4.4.  Thus, when
   the security protocol requests a Data SA, given such a Data SA
   identifier, an up-to-date Data SA will be obtained.  In particular,

Top      Up      ToC       Page 16 
   correct keying material, TEK(s), might need to be derived.  The
   derivation of TEK(s) (and other keying material) is done from a TGK
   and is described in Section 4.1.3.

   Second, for use within MIKEY itself, two key management procedures
   are needed:

   *  in the pre-shared case, deriving encryption and authentication key
      material from a single pre-shared key, and

   *  in the public key case, deriving similar key material from the
      transported envelope key.

   These two key derivation methods are specified in section 4.1.4.

   All the key derivation functionality mentioned above is based on a
   pseudo-random function, defined next.

4.1.  Key Calculation

   In the following, we define a general method (pseudo-random function)
   to derive one or more keys from a "master" key.  This method is used
   to derive:

   *  TEKs from a TGK and the RAND value,

   *  encryption, authentication, or salting key from a pre-shared/
      envelope key and the RAND value.

4.1.1.  Assumptions

   We assume that the following parameters are in place:

   csb_id : Crypto Session Bundle ID (32-bits unsigned integer)
   cs_id  : the Crypto Session ID (8-bits unsigned integer)
   RAND   : (at least) 128-bit (pseudo-)random bit-string sent by the
            Initiator in the initial exchange.

   The key derivation method has the following input parameters:

   inkey     : the input key to the derivation function
   inkey_len : the length in bits of the input key
   label     : a specific label, dependent on the type of the key to be
               derived, the RAND, and the session IDs
   outkey_len: desired length in bits of the output key.

Top      Up      ToC       Page 17 
   The key derivation method has the following output:

   outkey: the output key of desired length.

4.1.2.  Default PRF Description

   Let HMAC be the SHA-1 based message authentication function, see
   [HMAC] [SHA-1].  Similarly to [TLS], we define:

      P (s, label, m) = HMAC (s, A_1 || label) ||
                        HMAC (s, A_2 || label) || ...
                        HMAC (s, A_m || label)

      A_0 = label,
      A_i = HMAC (s, A_(i-1))
      s is a key (defined below)
      m is a positive integer (also defined below).

   Values of label depend on the case in which the PRF is invoked, and
   values are specified in the following for the default PRF.  Thus,
   note that other PRFs later added to MIKEY MAY specify different input

   The following procedure describes a pseudo-random function, denoted
   PRF(inkey,label), based on the above P-function, applied to compute
   the output key, outkey:

   *  let n = inkey_len / 256, rounded up to the nearest integer if not
      already an integer

   *   split the inkey into n blocks, inkey = s_1 || ... || s_n, where *
      all s_i, except possibly s_n, are 256 bits each

   *  let m = outkey_len / 160, rounded up to the nearest integer if not
      already an integer

   (The values "256" and "160" equals half the input block-size and full
   output hash size, respectively, of the SHA-1 hash as part of the P-

   Then, the output key, outkey, is obtained as the outkey_len most
   significant bits of

   PRF(inkey, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ...
                       XOR P(s_n, label, m).

Top      Up      ToC       Page 18 
4.1.3.  Generating keys from TGK

   In the following, we describe how keying material is derived from a
   TGK, thus assuming that a mapping of the Data SA identifier to the
   correct TGK has already been done according to Section 4.4.

   The key derivation method SHALL be executed using the above PRF with
   the following input parameters:

   inkey       : TGK
   inkey_len   : bit length of TGK
   label       : constant || cs_id || csb_id || RAND
   outkey_len  : bit length of the output key.

   The constant part of label depends on the type of key that is to be
   generated.  The constant 0x2AD01C64 is used to generate a TEK from
   TGK.  If the security protocol itself does not support key derivation
   for authentication and encryption from the TEK, separate
   authentication and encryption keys MAY be created directly for the
   security protocol by replacing 0x2AD01C64 with 0x1B5C7973 and
   0x15798CEF respectively, and outkey_len by the desired key-length(s)
   in each case.

   A salt key can be derived from the TGK as well, by using the constant
   0x39A2C14B.  Note that the Key data sub-payload (Section 6.13) can
   carry a salt.  The security protocol in need of the salt key SHALL
   use the salt key carried in the Key data sub-payload (in the pre-
   shared and public-key case), when present.  If that is not sent, then
   it is possible to derive the salt key via the key derivation
   function, as described above.

   The table below summarizes the constant values, used to generate keys
   from a TGK.

   constant    | derived key from the TGK
   0x2AD01C64  | TEK
   0x1B5C7973  | authentication key
   0x15798CEF  | encryption key
   0x39A2C14B  | salting key

   Table 4.1.3: Constant values for the derivation of keys from TGK.

   Note that these 32-bit constant values (listed in the table above)
   are taken from the decimal digits of e (i.e., 2.7182...), where each
   constant consists of nine decimal digits (e.g., the first nine
   decimal digits 718281828 = 0x2AD01C64).  The strings of nine

Top      Up      ToC       Page 19 
   decimal digits are not chosen at random, but as consecutive "chunks"
   from the decimal digits of e.

4.1.4.  Generating keys for MIKEY messages from an envelope/pre-shared

   This derivation is to form the symmetric encryption key (and salting
   key) for the encryption of the TGK in the pre-shared key and public
   key methods.  This is also used to derive the symmetric key used for
   the message authentication code in these messages, and the
   corresponding verification messages.  Hence, this derivation is
   needed in order to get different keys for the encryption and the MAC
   (and in the case of the pre-shared key, it will result in fresh key
   material for each new CSB).  The parameters for the default PRF are

   inkey      : the envelope key or the pre-shared key
   inkey_len  : the bit length of inkey
   label      : constant || 0xFF || csb_id || RAND
   outkey_len : desired bit length of the output key.

   The constant part of label depends on the type of key that is to be
   generated from an envelope/pre-shared key, as summarized below.

   constant    | derived key
   0x150533E1  | encryption key
   0x2D22AC75  | authentication key
   0x29B88916  | salt key

   Table 4.1.4: Constant values for the derivation of keys from an
   envelope/pre-shared key.

4.2.  Pre-defined Transforms and Timestamp Formats

   This section identifies default transforms for MIKEY.  It is
   mandatory to implement and support the following transforms in the
   respective case.  New transforms can be added in the future (see
   Section 4.2.9 for further guidelines).

4.2.1.  Hash functions

   In MIKEY, it is MANDATORY to implement SHA-1 as the default hash

Top      Up      ToC       Page 20 
4.2.2.  Pseudo-random number generator and PRF

   A cryptographically secure random or pseudo-random number generator
   MUST be used for the generation of the keying material and nonces,
   e.g., [BMGL].  However, which one to use is implementation specific
   (as the choice will not affect the interoperability).

   For the key derivations, it is MANDATORY to implement the PRF
   specified in Section 4.1.  Other PRFs MAY be added by writing
   standard-track RFCs specifying the PRF constructions and their exact
   use within MIKEY.

4.2.3.  Key data transport encryption

   The default and mandatory-to-implement key transport encryption is
   AES in counter mode, as defined in [SRTP], using a 128-bit key as
   derived in Section 4.1.4, SRTP_PREFIX_LENGTH set to zero, and using
   the initialization vector

   IV = (S XOR (0x0000 || CSB ID || T)) || 0x0000,

   where S is a 112-bit salting key, also derived as in Section 4.1.4,
   and where T is the 64-bit timestamp sent by the Initiator.

   Note: this restricts the maximum size that can be encrypted to 2^23
   bits, which is still enough for all practical purposes [SRTP].

   The NULL encryption algorithm (i.e., no encryption) can be used (but
   implementation is OPTIONAL).  Note that this MUST NOT be used unless
   the underlying protocols can guarantee security.  The main reason for
   including this is for specific SIP scenarios, where SDP is protected
   end-to-end.  For this scenario, MIKEY MAY be used with the pre-shared
   key method, the NULL encryption, and NULL authentication algorithm
   (see Section 4.2.4) while relying on the security of SIP.  Use this
   option with caution!

   The AES key wrap function [AESKW] is included as an OPTIONAL
   implementation method.  If the key wrap function is used in the
   public key method, the NULL MAC is RECOMMENDED to be used, as the key
   wrap itself will provide integrity of the encrypted content (note
   though that the NULL MAC SHOULD NOT be used in the pre-shared key
   case, as the MAC in that case covers the entire message).  The 128-
   bit key and a 64-bit salt, S, are derived in accordance to Section
   4.1.4 and the key wrap IV is then set to S.

Top      Up      ToC       Page 21 
4.2.4.  MAC and Verification Message function

   MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1
   as the MANDATORY implementation method, see [HMAC].  Authentication
   keys are derived according to Section 4.1.4.  Note that the
   authentication key size SHOULD be equal to the size of the hash
   function's output (e.g., for HMAC-SHA-1, a 160-bit authentication key
   is used) [HMAC].

   The NULL authentication algorithm (i.e., no MAC) can be used together
   with the NULL encryption algorithm (but implementation is OPTIONAL).
   Note that this MUST NOT be used unless the underlying protocols can
   guarantee security.  The main reason for including this is for
   specific SIP scenarios, where SDP is protected end-to-end.  For this
   scenario, MIKEY MAY be used with the pre-shared key method and the
   NULL encryption and authentication algorithm, while relying on the
   security of SIP.  Use this option with caution!

4.2.5.  Envelope Key encryption

   The public key encryption algorithm applied is defined by, and
   dependent on the certificate used. It is MANDATORY to support RSA
   PKCS#1, v1.5, and it is RECOMMENDED to also support RSA OAEP [PSS].

4.2.6.  Digital Signatures

   The signature algorithm applied is defined by, and dependent on the
   certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it
   is RECOMMENDED to also support RSA PSS [PSS].

4.2.7.  Diffie-Hellman Groups

   The Diffie-Hellman key exchange, when supported, uses OAKLEY 5
   [OAKLEY] as a mandatory implementation.  Both OAKLEY 1 and OAKLEY 2
   MAY be used (but these are OPTIONAL implementations).

   See Section 4.2.9 for the guidelines on specifying a new DH Group to
   be used within MIKEY.

4.2.8.  Timestamps

   The timestamp is as defined in NTP [NTP], i.e., a 64-bit number in
   seconds relative to 0h on 1 January 1900.  An implementation MUST be
   aware of (and take into account) the fact that the counter will
   overflow approximately every 136th year.  It is RECOMMENDED that the
   time always be specified in UTC.

Top      Up      ToC       Page 22 
4.2.9.  Adding new parameters to MIKEY

   There are two different parameter sets that can be added to MIKEY.
   The first is a set of MIKEY transforms (needed for the exchange
   itself), and the second is the Data SAs.

   New transforms and parameters (including new policies) SHALL be added
   by registering with IANA (according to [RFC2434], see also Section
   10) a new number for the concerned payload, and also if necessary,
   documenting how the new transform/parameter is used.  Sometimes it
   might be enough to point to an already specified document for the
   usage, e.g., when adding a new, already standardized, hash function.

   In the case of adding a new DH group, the group MUST be specified in
   a companion standards-track RFC (it is RECOMMENDED that the specified
   group use the same format as used in [OAKLEY]).  A number can then be
   assigned by IANA for such a group to be used in MIKEY.

   When adding support for a new data security protocol, the following
   MUST be specified:

   *  A map sub-payload (see Section 6.1).  This is used to be able to
      map a crypto session to the right instance of the data security
      protocol and possibly also to provide individual parameters for
      each data security protocol.

   *  A policy payload, i.e., specification of parameters and supported

   *  General guidelines of usage.

4.3.  Certificates, Policies and Authorization

4.3.1.  Certificate handling

   Certificate handling may involve a number of additional tasks not
   shown here, and effect the inclusion of certain parts of the message
   (c.f. [X.509]).  However, the following observations can be made:

   *  The Initiator typically has to find the certificate of the
      Responder in order to send the first message.  If the Initiator
      does not already have the Responder's certificate, this may
      involve one or more roundtrips to a central directory agent.

   *  It will be possible for the Initiator to omit its own certificate
      and rely on the Responder getting this certificate using other
      means.  However, we only recommend doing this when it is
      reasonable to expect that the Responder has cached the certificate

Top      Up      ToC       Page 23 
      from a previous connection.  Otherwise accessing the certificate
      would mean additional roundtrips for the Responder as well.

   *  Verification of the certificates using Certificate Revocation
      Lists (CRLs) [X.509] or protocols such as OCSP [OCSP] may be
      necessary.  All parties in a MIKEY exchange should have a local
      policy which dictates whether such checks are made, how they are
      made, and how often they are made.  Note that performing the
      checks may imply additional messaging.

4.3.2.  Authorization

   In general, there are two different models for making authorization
   decisions for both the Initiator and the Responder, in the context of
   the applications targeted by MIKEY:

   *  Specific peer-to-peer configuration.  The user has configured the
      application to trust a specific peer.

      When pre-shared secrets are used, this is pretty much the only
      available scheme.  Typically, the configuration/entering of the
      pre-shared secret is taken to mean that authorization is implied.

      In some cases, one could also use this with public keys, e.g., if
      two peers exchange keys offline and configure them to be used for
      the purpose of running MIKEY.

   *  Trusted root.  The user accepts all peers that prove to have a
      certificate issued by a specific CA.  The granularity of
      authorization decisions is not very precise in this method.

      In order to make this method possible, all participants in the
      MIKEY protocol need to configure one or more trusted roots.  The
      participants also need to be capable of performing certificate
      chain validation, and possibly transfer more than a single
      certificate in the MIKEY messages (see also Section 6.7).

   In practice, a combination of both mentioned methods might be
   advantageous.  Also, the possibility for a user to explicitly exclude
   a specific peer (or sub-tree) in a trust chain might be needed.

   These authorization policies address the MIKEY scenarios a-c of
   Section 2.1, where the Initiator acts as the group owner and is also
   the only one that can invite others.  This implies that for each
   Responder, the distributed keys MUST NOT be re-distributed to other

Top      Up      ToC       Page 24 
   In a many-to-many situation, where the group control functions are
   distributed (and/or where it is possible to delegate the group
   control function to others), a means of distributing authorization
   information about who may be added to the group MUST exist.  However,
   it is out of scope of this document to specify how this should be

   For any broader communication situation, an external authorization
   infrastructure may be used (following the assumptions of [GKMARCH]).

4.3.3.  Data Policies

   Included in the message exchange, policies (i.e., security
   parameters) for the Data security protocol are transmitted.  The
   policies are defined in a separate payload and are specific to the
   security protocol (see also Section 6.10).  Together with the keys,
   the validity period of these can also be specified.  For example,
   this can be done with an SPI (or SRTP MKI) or with an Interval (e.g.,
   a sequence number interval for SRTP), depending on the security

   New parameters can be added to a policy by documenting how they
   should be interpreted by MIKEY and by also registering new values in
   the appropriate name space in IANA.  If a completely new policy is
   needed, see Section 4.2.9 for guidelines.

4.4.  Retrieving the Data SA

   The retrieval of a Data SA will depend on the security protocol, as
   different security protocols will have different characteristics.
   When adding support for a security protocol to MIKEY, some interface
   of how the security protocol retrieves the Data SA from MIKEY MUST be
   specified (together with policies that can be negotiated).

   For SRTP, the SSRC (see [SRTP]) is one of the parameters used to
   retrieve the Data SA (while the MKI may be used to indicate the
   TGK/TEK used for the Data SA).  However, the SSRC is not sufficient.
   For the retrieval of the Data SA from MIKEY, it is RECOMMENDED that
   the MIKEY implementation support a lookup using destination network
   address and port together with SSRC.  Note that MIKEY does not send
   network addresses or ports.  One reason for this is that they may not
   be known in advance.  Also, if a NAT exists in-between, problems may
   arise.  When SIP or RTSP is used, the local view of the destination
   address and port can be obtained from either SIP or RTSP.  MIKEY can
   then use these addresses as the index for the Data SA lookup.

Top      Up      ToC       Page 25 
4.5.  TGK re-keying and CSB updating

   MIKEY provides a means of updating the CSB (e.g., transporting a new
   TGK/TEK or adding a new Crypto Session to the CSB).  The updating of
   the CSB is done by executing MIKEY again, for example, before a TEK
   expires, or when a new Crypto Session is added to the CSB.  Note that
   MIKEY does not provide re-keying in the GKMARCH sense, only updating
   of the keys by normal unicast messages.

   When MIKEY is executed again to update the CSB, it is not necessary
   to include certificates and other information that was provided in
   the first exchange, for example, all payloads that are static or
   optionally included may be left out (see Figure 4.1).

   The new message exchange MUST use the same CSB ID as the initial
   exchange, but MUST use a new timestamp.  A new RAND MUST NOT be
   included in the message exchange (the RAND will only have effect in
   the Initial exchange).  If desired, new Crypto Sessions are added in
   the update message.  Note that a MIKEY update message does not need
   to contain new keying material (e.g., new TGK).  In this case, the
   crypto session continues to use the previously established keying
   material, while updating the new information.

   As explained in Section 3.2, the envelope key can be "cached" as a
   pre-shared key (this is indicated by the Initiator in the first
   message sent).  If so, the update message is a pre-shared key message
   with the cached envelope key as the pre-shared key; it MUST NOT be a
   public key message.  If the public key message is used, but the
   envelope key is not cached, the Initiator MUST provide a new
   encrypted envelope key that can be used in the verification message.
   However, the Initiator does not need to provide any other keys.

   Figure 4.1 visualizes the update messages that can be sent, including
   the optional parts.  The main difference from the original message is
   that it is optional to include TGKs (or DH values in the DH method).
   Also see Section 3 for more details on the specific methods.

   By definition, a CSB can contain several CSs.  A problem that then
   might occur is to synchronize the TGK re-keying if an SPI (or similar
   functionality, e.g., MKI in [SRTP]) is not used.  It is therefore
   RECOMMENDED that an SPI or MKI be used, if more than one CS is

Top      Up      ToC       Page 26 
     Initiator                                       Responder

     Pre-shared key method:

     I_MESSAGE =
     HDR, T, [IDi], [IDr], {SP}, KEMAC   --->
                                                    R_MESSAGE =
                                        [<---]     HDR, T, [IDr], V

     Public key method:

     I_MESSAGE =
     HDR, T, [IDi|CERTi], [IDr], {SP},
          [KEMAC], [CHASH], PKE, SIGNi   --->
                                                 R_MESSAGE =
                                        [<---]   HDR, T, [IDr], V

     DH method:

     I_MESSAGE =
     HDR, T, [IDi|CERTi], [IDr], {SP},
          [DHi], SIGNi                   --->
                                               R_MESSAGE =
                                         <---  HDR, T, [IDr|CERTr], IDi,
                                                   [DHr, DHi], SIGNr

   Figure 4.1: Update messages.

   Note that for the DH method, if the Initiator includes the DHi
   payload, then the Responder MUST include DHr and DHi.  If the
   Initiator does not include DHi, the Responder MUST NOT include DHr or

5.  Behavior and message handling

   Each message that is sent by the Initiator or the Responder is built
   by a set of payloads.  This section describes how messages are
   created and also when they can be used.

5.1.  General

5.1.1.  Capability Discovery

   The Initiator indicates the security policy to be used (i.e., in
   terms of security protocol algorithms).  If the Responder does not
   support it (for some reason), the Responder can together with an
   error message (indicating that it does not support the parameters),
   send back its own capabilities (negotiation) to let the Initiator

Top      Up      ToC       Page 27 
   choose a common set of parameters.  This is done by including one or
   more security policy payloads in the error message sent in response
   (see Section 5.1.2.).  Multiple attributes can be provided in
   sequence in the response.  This is done to reduce the number of
   roundtrips as much as possible (i.e., in most cases, where the policy
   is accepted the first time, one roundtrip is enough).  If the
   Responder does not accept the offer, the Initiator must go out with a
   new MIKEY message.

   If the Responder is not willing/capable of providing security or the
   parties simply cannot agree, it is up to the parties' policies how to
   behave, for example, accepting or rejecting an insecure

   Note that it is not the intention of this protocol to have a broad
   variety of options, as it is assumed that a denied offer should
   rarely occur.

   In the one-to-many and many-to-many scenarios using multicast
   communication, one issue is of course that there MUST be a common
   security policy for all the receivers.  This limits the possibility
   of negotiation.

5.1.2.  Error Handling

   Due to the key management protocol, all errors SHOULD be reported to
   the peer(s) by an error message.  The Initiator SHOULD therefore
   always be prepared to receive such a message from the Responder.

   If the Responder does not support the set of parameters suggested by
   the Initiator, the error message SHOULD include the supported
   parameters (see also Section 5.1.1).

   The error message is formed as:

   HDR, T, {ERR}, {SP}, [V|SIGNr]

   Note that if failure is due to the inability to authenticate the
   peer, the error message is OPTIONAL, and does not need to be
   authenticated.  It is up to local policy to determine how to treat
   this kind of message.  However, if in response to a failed
   authentication a signed error message is returned, this can be used
   for DoS purposes (against the Responder).  Similarly, an
   unauthenticated error message could be sent to the Initiator in order
   to fool the Initiator into tearing down the CSB.  It is highly
   RECOMMENDED that the local policy take this into consideration.
   Therefore, in case of authentication failure, one recommendation
   would be not to authenticate such an error message, and when

Top      Up      ToC       Page 28 
   receiving an unauthenticated error message view it only as a
   recommendation of what may have gone wrong.

5.2.  Creating a message

   To create a MIKEY message, a Common Header payload is first created.
   This payload is then followed, depending on the message type, by a
   set of information payloads (e.g., DH-value payload, Signature
   payload, Security Policy payload).  The defined payloads and the
   exact encoding of each payload are described in Section 6.

    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
   !  version      !  data type    ! next payload  !               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...            +
   ~                   Common Header...                            ~
   !                                                               !
   ! next payload  !   Payload 1 ...                               !
   +-+-+-+-+-+-+-+-+                                               +
   ~                                                               ~
   :                             :                                 :
   :                             :                                 :
   ! next payload  !   Payload x ...                               !
   +-+-+-+-+-+-+-+-+                                               +
   ~                                                               ~
   !                   MAC/Signature                               ~

   Figure 5.1. MIKEY payload message example.  Note that the payloads
   are byte aligned and not 32-bit aligned.

   The process of generating a MIKEY message consists of the following

   *  Create an initial MIKEY message starting with the Common Header

   *  Concatenate necessary payloads of the MIKEY message (see the
      exchange definitions for payloads that may be included, and the
      recommended order).

   *  As a last step (for messages that must be authenticated, this also
      includes the verification message), create and concatenate the
      MAC/signature payload without the MAC/signature field filled in

Top      Up      ToC       Page 29 
      (if a Next payload field is included in this payload, it is set to
      Last payload).

   *  Calculate the MAC/signature over the entire MIKEY message, except
      the MAC/Signature field, and add the MAC/signature in the field.
      In the case of the verification message, the Identity_i ||
      Identity_r || Timestamp MUST directly follow the MIKEY message in
      the Verification MAC calculation.  Note that the added identities
      and timestamp are identical to those transported in the ID and T

   In the public key case, the Key data transport payload is generated
   by concatenating the IDi with the TGKs.  This is then encrypted and
   placed in the data field.  The MAC is calculated over the entire Key
   data transport payload except the MAC field.  Before calculating the
   MAC, the Next payload field is set to zero.

   Note that all messages from the Initiator MUST use a unique
   timestamp.  The Responder does not create a new timestamp, but uses
   the timestamp used by the Initiator.

5.3.  Parsing a message

   In general, parsing of a MIKEY message is done by extracting payload
   by payload and checking that no errors occur.  The exact procedure is
   implementation specific; however, for the Responder, it is
   RECOMMENDED that the following procedure be followed:

   *  Extract the Timestamp and check that it is within the allowable
      clock skew (if not, discard the message).  Also check the replay
      cache (Section 5.4) so that the message is not replayed (see
      Section 5.4).  If the message is replayed, discard it.

   *  Extract the ID and authentication algorithm (if not included,
      assume the default).

   *  Verify the MAC/signature.

   *  If the authentication is not successful, an Auth failure Error
      message MAY be sent to the Initiator.  The message is then
      discarded from further processing.  See also Section 5.1.2 for
      treatment of errors.

   *  If the authentication is successful, the message is processed and
      also added to the replay cache; processing is implementation
      specific.  Note also that only successfully authenticated messages
      are stored in the replay cache.

Top      Up      ToC       Page 30 
   *  If any unsupported parameters or errors occur during the
      processing, these MAY be reported to the Initiator by sending an
      error message.  The processing is then aborted.  The error message
      can also include payloads to describe the supported parameters.

   *  If the processing was successful and in case the Initiator
      requested it, a verification/response message MAY be created and
      sent to the Initiator.

5.4.  Replay handling and timestamp usage

   MIKEY does not use a challenge-response mechanism for replay
   handling; instead, timestamps are used.  This requires that the
   clocks are synchronized.  The required synchronization is dependent
   on the number of messages that can be cached (note though, that the
   replay cache only contains messages that have been successfully
   authenticated).  If we could assume an unlimited cache, the terminals
   would not need to be synchronized at all (as the cache could then
   contain all previous messages).  However, if there are restrictions
   on the size of the replay cache, the clocks will need to be
   synchronized to some extent.  In short, one can in general say that
   it is a tradeoff between the size of the replay cache and the
   required synchronization.

   Timestamp usage prevents replay attacks under the following

   *  Each host has a clock which is at least "loosely synchronized"
      with the clocks of the other hosts.

   *  If the clocks are to be synchronized over the network, a secure
      network clock synchronization protocol SHOULD be used, e.g.,

   *  Each Responder utilizes a replay cache in order to remember the
      successfully authenticated messages presented within an allowable
      clock skew (which is set by the local policy).

   *  Replayed and outdated messages, for example, messages that can be
      found in the replay cache or which have an outdated timestamp are
      discarded and not processed.

   *  If the host loses track of the incoming requests (e.g., due to
      overload), it rejects all incoming requests until the clock skew
      interval has passed.

Top      Up      ToC       Page 31 
   In a client-server scenario, servers may encounter a high workload,
   especially if a replay cache is necessary.  However, servers that
   assume the role of MIKEY Initiators will not need to manage any
   significant replay cache as they will refuse all incoming messages
   that are not a response to a message previously sent by the server.

   In general, a client may not expect a very high load of incoming
   messages and may therefore allow the degree of looseness to be on the
   order of several minutes to hours.  If a (D)DoS attack is launched
   and the replay cache grows too large, MIKEY MAY dynamically decrease
   the looseness so that the replay cache becomes manageable.  However,
   note that such (D)DoS attacks can only be performed by peers that can
   authenticate themselves.  Hence, such an attack is very easy to trace
   and mitigate.

   The maximum number of messages that a client will need to cache may
   vary depending on the capacity of the client itself and the network.
   The number of expected messages should be taken into account.

   For example, assume that we can at most spend 6kB on a replay cache.
   Assume further that we need to store 30 bytes for each incoming
   authenticated message (the hash of the message is 20 bytes).  This
   implies that it is possible to cache approximately 204 messages.  If
   the expected number of messages per minute can be estimated, the
   clock skew can easily be calculated.  For example, in a SIP scenario
   where the client is expected, in the most extreme case, to receive 10
   calls per minute, the clock skew needed is then approximately 20
   minutes.  In a not so extreme setting, where one could expect an
   incoming call every 5th minute, this would result in a clock skew on
   the order of 16.5 hours (approx 1000 minutes).

   Consider a very extreme case, where the maximum number of incoming
   messages are assumed to be on the order of 120 messages per minute,
   and a requirement that the clock skew is on the order of 10 minutes,
   a 48kB replay cache would be required.

   Hence, one can note that the required clock skew will depend largely
   on the setting in which MIKEY is used.  One recommendation is to fix
   a size for the replay cache, allowing the clock skew to be large (the
   initial clock skew can be set depending on the application in which
   it is used).  As the replay cache grows, the clock skew is decreased
   depending on the percentage of the used replay cache.  Note that this
   is locally handled, which will not require interaction with the peer
   (even though it may indirectly effect the peer).  However, exactly
   how to implement such functionality is out of the scope of this
   document and considered implementation specific.

Top      Up      ToC       Page 32 
   In case of a DoS attack, the client will most likely be able to
   handle the replay cache.  A more likely (and serious) DoS attack is a
   CPU DoS attack where the attacker sends messages to the peer, which
   then needs to expend resources on verifying the MACs/signatures of
   the incoming messages.

(page 32 continued on part 3)

Next RFC Part