groups, one may expect that each client will be in charge for setting
up the security for its outgoing streams. In these scenarios, the
pre-shared key or the public-key transport method is used.
++++ ++++
|A | -------> |B |
| | <------- | |
++++ ++++
^ | | ^
| | | |
| | ++++ | |
| --->|C |<--- |
------| |------
++++
Figure 8.2. Small-size group without a centralized controller.
One scenario may then be that the client sets up a three-part call,
using SIP. Due to the small size of the group, unicast SRTP is used
between the clients. Each client sets up the security for its
outgoing stream(s) to the others.
As for the simple one-to-many case, the streaming client specifies
the same CSB_ID and CS_ID(s) for its outgoing sessions if the same
TGK/TEK(s) is used for all the group members.
9. Security Considerations
9.1. General
Key management protocols based on timestamps/counters and one-
roundtrip key transport have previously been standardized, for
example ISO [ISO1, ISO2]. The general security of these types of
protocols can be found in various articles and literature, c.f. [HAC,
AKE, LOA].
No chain is stronger than its weakest link. If a given level of
protection is wanted, then the cryptographic functions protecting the
keys during transport/exchange MUST offer a security corresponding to
at least that level.
For instance, if a security against attacks with a complexity 2^96 is
wanted, then one should choose a secure symmetric cipher supporting
at least 96 bit keys (128 bits may be a practical choice) for the
actual media protection, and a key transport mechanism that provides
equivalent protection, e.g., MIKEY’s pre-shared key transport with
128 bit TGK, or RSA with 1024 bit keys (which according to [LV]
corresponds to the desired 96 bit level, with some margin).
In summary, key size for the key-exchange mechanism MUST be weighed
against the size of the exchanged TGK so that it at least offers the
required level. For efficiency reasons, one SHOULD also avoid a
security overkill, e.g., by not using a public key transport with
public keys giving a security level that is orders of magnitude
higher than length of the transported TGK. We refer to [LV] for
concrete key size recommendations.
Moreover, if the TGKs are not random (or pseudo-random), a brute
force search may be facilitated, again lowering the effective key
size. Therefore, care MUST be taken when designing the (pseudo-)
random generators for TGK generation, see [FIPS][RAND].
For the selection of the hash function, SHA-1 with 160-bit output is
the default one. In general, hash sizes should be twice the
"security level", indicating that SHA-1-256, [SHA256], should be used
for the default 128-bit level. However, due to the real-time aspects
in the scenarios we are treating, hash sizes slightly below 256 are
acceptable, as the normal "existential" collision probabilities would
be of secondary importance.
In a Crypto Session Bundle, the Crypto Sessions can share the same
TGK as discussed earlier. From a security point of view, to satisfy
the criterion in case the TGK is shared, the encryption of the
individual Crypto Sessions are performed "independently". In MIKEY,
this is accomplished by having unique Crypto Session identifiers (see
also Section 4.1) and a TEK derivation method that provides
cryptographically independent TEKs to distinct Crypto Sessions
(within the Crypto Session Bundle), regardless of the security
protocol used.
Specifically, the key derivations, as specified in Section 4.1, are
implemented by a pseudo-random function. The one used here is a
simplified version of that used in TLS [TLS]. Here, only one single
hash function is used, whereas TLS uses two different functions.
This choice is motivated by the high confidence in the SHA-1 hash
function, and by efficiency and simplicity of design (complexity does
not imply security). Indeed, as shown in [DBJ], if one of the two
hashes is severely broken, the TLS PRF is actually less secure than
as if a single hash had been used on the whole key, as is done in
MIKEY.
In the pre-shared key and public-key schemes, the TGK is generated by
a single party (Initiator). This makes MIKEY somewhat more sensitive
if the Initiator uses a bad random number generator. It should also
be noted that neither the pre-shared nor the public-key scheme
provides perfect forward secrecy. If mutual contribution or perfect
forward secrecy is desired, the Diffie-Hellman method is to be used.
Authentication (e.g., signatures) in the Diffie-Hellman method is
required to prevent man-in-the-middle attacks.
Forward/backward security: if the TGK is exposed, all generated TEKs
are compromised. However, under the assumption that the derivation
function is a pseudo-random function, disclosure of an individual TEK
does not compromise other (previous or later) TEKs derived from the
same TGK. The Diffie-Hellman mode can be considered by cautious
users, as it is the only one that supports so called perfect forward
secrecy (PFS). This is in contrast to a compromise of the pre-shared
key (or the secret key of the public key mode), where future sessions
and recorded sessions from the past are then also compromised.
The use of random nonces (RANDs) in the key derivation is of utmost
importance to counter off-line pre-computation attacks. Note however
that update messages re-use the old RAND. This means that the total
effective key entropy (relative to pre-computation attacks) for k
consecutive key updates, assuming the TGKs and RAND are each n bits
long, is about L = n*(k+1)/2 bits, compared to the theoretical
maximum of n*k bits. In other words, a 2^L work effort MAY enable an
attacker to get all k n-bit keys, which is better than brute force
(except when k = 1). While this might seem like a defect, first note
that for a proper choice of n, the 2^L complexity of the attack is
way out of reach. Moreover, the fact that more than one key can be
compromised in a single attack is inherent to the key exchange
problem. Consider for instance a user who, using a fixed 1024-bit
RSA key, exchanges keys and communicates during a one or two year
lifetime of the public key. Breaking this single RSA key will enable
access to all exchanged keys and consequently the entire
communication of that user over the whole period.
All the pre-defined transforms in MIKEY use state-of-the-art
algorithms that have undergone large amounts of public evaluation.
One of the reasons for using the AES-CM from SRTP [SRTP], is to have
the possibility of limiting the overall number of different
encryption modes and algorithms, while offering a high level of
security at the same time.
9.2. Key lifetime
Even if the lifetime of a TGK (or TEK) is not specified, it MUST be
taken into account that the encryption transform in the underlying
security protocol can in some way degenerate after a certain amount
of encrypted data. It is not possible to here state universally
applicable, general key lifetime bounds; each security protocol
should define such maximum amount and trigger a re-keying procedure
before the "exhaustion" of the key. For example, according to SRTP
[SRTP] the TEK, together with the corresponding TGK, MUST be changed
at least every 2^48 SRTP packet.
Still, the following can be said as a rule of thumb. If the security
protocol uses an "ideal" b-bit block cipher (in CBC mode, counter
mode, or a feedback mode, e.g., OFB, with full b-bit feedback),
degenerate behavior in the crypto stream, possibly useful for an
attacker, is (with constant probability) expected to occur after a
total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs).
For security margin, re-keying MUST be triggered well in advance
compared to the above bound. See [BDJR] for more details.
For use of a dedicated stream cipher, we refer to the analysis and
documentation of said cipher in each specific case.
9.3. Timestamps
The use of timestamps, instead of challenge-responses, requires the
systems to have synchronized clocks. Of course, if two clients are
not synchronized, they will have difficulties in setting up the
security. The current timestamp based solution has been selected to
allow a maximum of one roundtrip (i.e., two messages), but still
provide a reasonable replay protection. A (secure) challenge-
response based version would require at least three messages. For a
detailed description of the timestamp and replay handling in MIKEY,
see Section 5.4.
Practical experiences of Kerberos and other timestamp-based systems
indicate that it is not always necessary to synchronize the terminals
over the network. Manual configuration could be a feasible
alternative in many cases (especially in scenarios where the degree
of looseness is high). However, the choice must be made carefully
with respect to the usage scenario.
9.4. Identity Protection
User privacy is a complex matter that to some extent can be enforced
by cryptographic mechanisms, but also requires policy enforcement and
various other functionalities. One particular facet of privacy is
user identity protection. However, identity protection was not a
main design goal for MIKEY. Such a feature will add more complexity
to the protocol and was therefore not chosen to be included. As
MIKEY is anyway proposed to be transported over, e.g., SIP, the
identity may be exposed by this. However, if the transporting
protocol is secured and also provides identity protection, MIKEY
might inherit the same feature. How this should be done is for
future study.
9.5. Denial of Service
This protocol is resistant to Denial of Service attacks in the sense
that a Responder does not construct any state (at the key management
protocol level) before it has authenticated the Initiator. However,
this protocol, like many others, is open to attacks that use spoofed
IP addresses to create a large number of fake requests. This may for
example, be solved by letting the protocol transporting MIKEY do an
IP address validity test. The SIP protocol can provide this using
the anonymous authentication challenge mechanism (specified in
Section 22.1 of [SIP]).
It is highly RECOMMENDED to include IDr in the Initiator’s message.
If not included, its absence can be used for DoS purposes (the
largest DoS-impact being on the public key and DH methods), where a
message intended for other entities is sent to the target. In fact,
the target may verify the signature correctly due to the fact that
the Initiator’s ID is correct and the message is actually signed by
the claimed Initiator (e.g., by re-directing traffic from another
session).
However, in the public key method, the envelop key and the MAC will
ensure that the message is not accepted (still, compared to a normal
faked message, where the signature verification would detect the
problem, one extra public key decryption is needed to detect the
problem in this case).
In the DH method, a message would be accepted (without detecting the
error) and a response (and state) would be created for the malicious
request.
As also discussed in Section 5.4, the tradeoff between time
synchronization and the size of the replay cache may be affected in
case of for example, a flooding DoS attack. However, if the
recommendations of using a dynamic size of the replay cache are
followed, it is believed that the client will in most cases be able
to handle the replay cache. Of course, as the replay cache decreases
in size, the required time synchronization is more restricted.
However, a bigger problem during such an attack would probably be to
process the messages (e.g., verify signatures/MACs) due to the
computational workload this implies.
9.6. Session Establishment
It should be noted that if the session establishment protocol is
insecure, there may be attacks on this that will have indirect
security implications on the secured media streams. This however
only applies to groups (and is not specific to MIKEY). The threat is
that one group member may re-direct a stream from one group member to
another. This will have the same implication as when a member tries
to impersonate another member, e.g., by changing its IP address. If
this is seen as a problem, it is RECOMMENDED that a Data Origin
Authentication (DOA) scheme (e.g., digital signatures) be applied to
the security protocol.
Re-direction of streams can of course be done even if it is not a
group. However, the effect will not be the same as compared to a
group where impersonation can be done if DOA is not used. Instead,
re-direction will only deny the receiver the possibility of receiving
(or just delay) the data.
10. IANA Considerations
This document defines several new name spaces associated with the
MIKEY payloads. This section summarizes the name spaces for which
IANA is requested to manage the allocation of values. IANA is
requested to record the pre-defined values defined in the given
sections for each name space. IANA is also requested to manage the
definition of additional values in the future. Unless explicitly
stated otherwise, values in the range 0-240 for each name space
SHOULD be approved by the process of IETF consensus and values in the
range 241-255 are reserved for Private Use, according to [RFC2434].
The name spaces for the following fields in the Common header payload
(from Section 6.1) are requested to be managed by IANA (in bracket is
the reference to the table with the initially registered values):
* version
* data type (Table 6.1.a)
* Next payload (Table 6.1.b)
* PRF func (Table 6.1.c). This name space is between 0-127, where
values between 0-111 should be approved by the process of IETF
consensus and values between 112-127 are reserved for Private Use.
* CS ID map type (Table 6.1.d)
The name spaces for the following fields in the Key data transport
payload (from Section 6.2) are requested to be managed by IANA:
* Encr alg (Table 6.2.a)
* MAC alg (Table 6.2.b)
The name spaces for the following fields in the Envelope data payload
(from Section 6.3) are requested to be managed by IANA:
* C (Table 6.3)
The name spaces for the following fields in the DH data payload (from
Section 6.4) are requested to be managed by IANA:
* DH-Group (Table 6.4)
The name spaces for the following fields in the Signature payload
(from Section 6.5) are requested to be managed by IANA:
* S type (Table 6.5)
The name spaces for the following fields in the Timestamp payload
(from Section 6.6) are requested to be managed by IANA:
* TS type (Table 6.6)
The name spaces for the following fields in the ID payload and the
Certificate payload (from Section 6.7) are requested to be managed by
IANA:
* ID type (Table 6.7.a)
* Cert type (Table 6.7.b)
The name spaces for the following fields in the Cert hash payload
(from Section 6.8) are requested to be managed by IANA:
* Hash func (Table 6.8)
The name spaces for the following fields in the Security policy
payload (from Section 6.10) are requested to be managed by IANA:
* Prot type (Table 6.10)
For each security protocol that uses MIKEY, a set of unique
parameters MAY be registered.
From Section 6.10.1.
* SRTP Type (Table 6.10.1.a)
* SRTP encr alg (Table 6.10.1.b)
* SRTP auth alg (Table 6.10.1.c)
* SRTP PRF (Table 6.10.1.d)
* FEC order (Table 6.10.1.e)
The name spaces for the following fields in the Error payload (from
Section 6.12) are requested to be managed by IANA:
* Error no (Table 6.12)
The name spaces for the following fields in the Key data payload
(from Section 6.13) are requested to be managed by IANA:
* Type (Table 6.13.a). This name space is between 0-16, which
should be approved by the process of IETF consensus.
* KV (Table 6.13.b). This name space is between 0-16, which should
be approved by the process of IETF consensus.
The name spaces for the following fields in the General Extensions
payload (from Section 6.15) are requested to be managed by IANA:
* Type (Table 6.15).
10.1. MIME Registration
This section gives instructions to IANA to register the
application/mikey MIME media type. This registration is as follows:
MIME media type name : application
MIME subtype name : mikey
Required parameters : none
Optional parameters : version
version: The MIKEY version number of the enclosed message
(e.g., 1). If not present, the version defaults to 1.
Encoding Considerations : binary, base64 encoded
Security Considerations : see section 9 in this memo
Interoperability considerations : none
Published specification : this memo
11. Acknowledgments
The authors would like to thank Mark Baugher, Ran Canetti, Martin
Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with
his group), Rolf Blom, Magnus Westerlund, Johan Bilien, Jon-Olov
Vatn, Erik Eliasson, and Gerhard Strangar for their valuable
feedback.
12. References
12.1. Normative References
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[PSS] PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories,
June 14, 2002, www.rsalabs.com
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[SHA-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real Time Transport Protocol", RFC
3711, March 2004.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[X.509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[AESKW] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
12.2. Informative References
[AKE] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange
Protocols and their use for Building Secure Channels",
Eurocrypt 2001, LNCS 2054, pp. 453-474, 2001.
[BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A
Concrete Analysis of Symmetric Encryption: Analysis of the
DES Modes of Operation", in Proceedings of the 38th
Symposium on Foundations of Computer Science, IEEE, 1997,
pp. 394-403.
[BMGL] Hastad, J. and M. Naslund: "Practical Construction and
Analysis of Pseduo-randomness Primitives", Proceedings of
Asiacrypt 2001, LNCS. vol 2248, pp. 442-459, 2001.
[DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use
of MD5", Contribution to ANSI X9F1 WG, 2001.
[FIPS] "Security Requirements for Cryptographic Modules", Federal
Information Processing Standard Publications (FIPS PUBS)
140-2, December 2002.
[GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Group Key Management Architecture", Work in Progress.
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., and R.
Fleischer, "Group Secure Association Key Management
Protocol", Work in Progress.
[HAC] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
of Applied Cryptography", CRC press, 1996.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[ISO1] ISO/IEC 9798-3: 1997, Information technology - Security
techniques - Entity authentication - Part 3: Mechanisms
using digital signature techniques.
[ISO2] ISO/IEC 11770-3: 1997, Information technology - Security
techniques - Key management - Part 3: Mechanisms using
digital signature techniques.
[ISO3] ISO/IEC 18014 Information technology - Security techniques
- Time-stamping services, Part 1-3.
[KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "Key Management Extensions for SDP and RTSP", Work
in Progress.
[LOA] Burrows, Abadi, and Needham, "A logic of authentication",
ACM Transactions on Computer Systems 8 No.1 (Feb. 1990),
18-36.
[LV] Lenstra, A. K. and E. R. Verheul, "Suggesting Key Sizes for
Cryptosystems", http://www.cryptosavvy.com/suggestions.htm
[NTP] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RAND] Eastlake, 3rd, D., Crocker, S., and J. Schiller,
"Randomness Requirements for Security", RFC 1750, December
1994.
[RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512",
http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf