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.
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
values.
* 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
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
parties.
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
done.
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
protocol.
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.
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
present.
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
DHi.
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
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
communication.
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
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
steps:
* Create an initial MIKEY message starting with the Common Header
payload.
* 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
(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
payloads.
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.
* 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
assumptions:
* 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.,
[ISO3].
* 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.
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