Internet DRAFT - draft-blom-mm-kmgt
draft-blom-mm-kmgt
Network Working Group R. Blom
INTERNET-DRAFT E. Carrara
Expires: December 2001 F. Lindholm
J. Arkko
Ericsson
July, 2001
Design Criteria for Multimedia Session Key Management
in Heterogeneous Networks
<draft-blom-mm-kmgt-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
For conversational multimedia to take off, many important aspects
have still to be fully investigated. The security framework is one of
them. While some proposals on how to secure the media traffic have
appeared, a key management solution has still to be developed. It
should take into account the conversational multimedia type of
scenario and an heterogeneous communication environment, in which
thin clients are used. Such a scenario will result in a number of
challenging requirements. The purpose of this document is to describe
the scenario and to list constraints and requirements on a key
management scheme for media traffic in conversational multimedia.
Blom, et al. [Page 1]
INTERNET-DRAFT mm-kmgt July 2001
TABLE OF CONTENTS
1. Introduction....................................................2
1.1. Outline.......................................................3
1.2. Notational Conventions........................................3
2. Network Architecture............................................3
3. Call control Security...........................................4
4. Security of the Media Session...................................5
5. Basic Requirements..............................................5
5.1. General.......................................................5
5.2. Authentication................................................6
5.3. Key Derivation, Refresh and Re-keying.........................6
5.4. Negotiation and Efficiency....................................7
5.5. Groups .......................................................7
5.6. Denial of Service.............................................8
6. Service Requirements in heterogeneous environment...............9
7. Security Considerations........................................10
8. Conclusions....................................................11
9. Acknowledgments................................................11
10. Authors' addresses............................................11
11. References....................................................12
1. Introduction
Conversational multimedia is expected to become big business in the
near future. Solutions are on the way, but still, pieces are missing.
In particular, security is of concern; no security framework has yet
been clearly developed. Some work has been initiated with a security
scheme for RTP traffic [SRTP], but many aspects still need to be
investigated. One of them is how to make an initial agreement on the
security parameters (keys included) needed by the security scheme
employed, that is key management. It is of interest here to focus on
key management schemes addressing the specific requirements for
protection of media traffic. The expected environment is of
heterogeneous nature and therefore it is of great importance to
consider also wireless aspects.
This document contains a discussion about requirements that a key
management scheme for secure conversational multimedia has to fulfil.
There are indeed existing candidates for a key management solution;
however, the conversational multimedia applications and the
heterogeneous communications scenario, where thin clients are common,
put some special requirements on the solution. These requirements
have to be taken into account in the design of an efficient scheme,
which should work in a general scenario.
Blom, et al. [Page 2]
INTERNET-DRAFT mm-kmgt July 2001
1.1. Outline
Section 2 describes a simple case, which we use as a reference, and
it also lists some possible trust models. Section 3 briefly discusses
the security of the call control protocol. Section 4 lists some
general requirements, while Section 5 lists more specific
requirements for the applications and scenarios that we are dealing
with. In Section 6 service requirements are derived and Section 7
describes when and how to run the key management protocol.
1.2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
2. Network Architecture
The scenarios we are considering are conversational multimedia
sessions. A typical example may be two or more users involved in a
"phone call" with both audio and video sessions between them. Here
real-time is a must. Moreover, it is necessary to investigate an
heterogeneous environment, due to the expected convergence of the
cellular networks and the Internet. We emphasize that a solution,
which works in a very constrained environment, as e.g. the cellular
environment, in general also works in a more relaxed environment.
Hence, cellular aspects will be considered from the very beginning in
order to end up with a general solution.
|A's SIP| <.......> |B's SIP|
|Server | SIP |Server |
--------- ---------
^ ^
. .
++++ SIP . . SIP ++++
|A | <............. .............> |B |
| | | |
++++ <-------------------------------------------> ++++
SRTP
Fig 1: SIP-based call example. The two parties uses SIP to setup SRTP
streams between A and B.
Blom, et al. [Page 3]
INTERNET-DRAFT mm-kmgt July 2001
We base our discussion for simplicity on a SIP-based call between two
users, where SIP [SIP] is the call control protocol, and the media is
protected by SRTP. The basic architecture is shown in Fig 1. Another
example may be a streaming application.
The SIP proxies may belong to the transport network or may be e.g.
standalone ASPs.
The security of the media streams may in general be independent of
the security used to protect the call control itself. The users are
likely to desire end-to-end protection for their media traffic.
3. Call Control Security
For simplicity, let us consider the very simple but essential
scenario showed in Fig 1. The discussion can easily be extended to
other situations. Hence, the example we use has SIP [SIP] as call
control protocol.
Integrity protection and authentication of SIP messages are regarded
as essential functions, while confidentiality is recommended when
possible.
In general, network or transport security protocols are applicable on
a hop-by-hop basis between the involved entities (e.g., IPsec
[IPSEC], TLS [TLS]). Pre-existing secure tunnels may be in place
between the SIP proxies, hence leading to a transitive chain of
trust.
The most distinguishing feature shown by a call control protocol like
SIP with respect to security is the fact that entities in the path
between the endpoints (e.g., SIP proxies) need access to the SIP
message to read/modify/add some of its fields.
End-to-end (e2e) security (e.g., PGP [PGP]) may therefore be
applicable only to limited parts of the SIP messages, e.g. some
headers which are not changed by intermediate proxies and possibly
the SDP part [SDP], if no nodes in the path need access to them
(e.g., Network Address Translators [NAT]).
If parts of the call control protocol are e2e protected, it may be
possible for them to carry the sensible parameters (e.g., keys)
needed by the media traffic security protocol. In this way, untrusted
proxies will have no access to such parameters.
There are basically two trust models that are applicable:
- only the endpoints of the media are trusted. The key management has
then a true 'end-to-end' nature.
Blom, et al. [Page 4]
INTERNET-DRAFT mm-kmgt July 2001
- a third party is trusted, e.g. the KDC in Kerberos [KBRS], or an
AAA infrastructure.
The end-to-end protection of the media traffic is by necessity broken
in case, for example, a transcoder is needed. In this case, the
transcoder becomes a legitimate endpoint for the encrypted traffic.
The third-party trust model offers more lightweight solutions for the
key management, with the obvious drawback of placing trust in a third
party. In the following we concentrate on the first trust model.
4. Security of the Media Session
It is of interest here how to protect the media session (e.g., RTP
traffic [RTP]) following the call set-up phase. Unless by necessity
(e.g., the existence of transcoders), only the media endpoints should
be recipients of the encrypting/authenticating keys.
>> Req 4.1: the key management protocol MUST support e2e protection.
Multimedia applications often use broadcast or multicast (e.g., net
radio/TV, videoconferences, etc). Therefore, it is also necessary to
support multi-party and multicast sessions:
>> Req 4.2: the key management solution MUST support multi-party and
multicast sessions.
5. Basic Requirements
Typically, existing key management protocols handle authentication
(including relationships to a trust infrastructure), negotiation of
the security protocol and algorithms to be used, generation of
session keys, and periodic refresh of the keys.
In this section, we list the basic requirements for the key
management scheme.
5.1. General
The main task of the key management protocol is to securely exchange
master keys from which to derive session keys (see Section 5.3.). It
should be possible for just one party to generate the session key
since adding components from two parties would result in additional
round trips. Another case when this is desirable is when an
additional user/receiver joins an on-going multicast session.
>> Req 5.1: It SHOULD be possible for a single party to generate the
master key and transmit it securely to the other party (parties).
Blom, et al. [Page 5]
INTERNET-DRAFT mm-kmgt July 2001
The scenario we are describing here is intended for very large
networks, of the order of today's Public Switched Telephone Network
(PSTN) at least. Hence, scalability is a necessity. Scalability also
brings the necessity to manage the system and the user's keys in
different parts of the world, still enabling connectivity. This will
typically mean the need of a PKI infrastructure.
>> Req 5.2: the key management scheme MUST be at least scalable to a
size close to current PSTN.
>> Req 5.3: it MUST be possible to manage the users of the key
management scheme under different administrative domains.
>> Req 5.4: the key management scheme MUST allow users from different
administrative domains to communicate securely.
It can be assumed that different security protocols will be used
depending on situation. The key management protocol should therefore
be able to set up Security Associations (SAs) on behalf of several
different security protocols. The alternative is, of course, to
implement several key management schemes, if several security
protocols are to be used.
>> Req 5.5: The key management protocol SHOULD be adaptable to
support different security protocols.
Terminal mobility must be supported, as well as multi-homed
terminals.
>> Req 5.6: SAs SHOULD NOT be associated/indexed with IP addresses.
5.2. Authentication
Authentication is an important aspect for key management. It is
important that the authentication is as efficient as the key
exchange. Experiences from web security show that not just mutual
authentication, but also unidirectional authentication is useful in
certain situations.
>> Req 5.7: Both unidirectional and mutual authentication SHOULD be
possible.
5.3. Key Derivation, Refresh and Re-keying
Typically, a key exchange protocol allows the involved parties to
exchange and then share a "master key", or seed, from which "session
keys" are derived.
Blom, et al. [Page 6]
INTERNET-DRAFT mm-kmgt July 2001
Key refresh (deriving a new key from the previous one or from a
"seed" in the same session, mainly for security reasons) and re-
keying (creating a new master key, commonly used for access control)
are fundamental aspects of the key management. Therefore, it must be
clearly specified how this must be done.
>> Req 5.8: the key management scheme MUST specify how to derive
session keys from the master key.
>> Req 5.9: the key management scheme MUST specify re-keying
mechanisms and policies.
>> Req 5.10: the key management scheme MUST specify key refresh
mechanisms and policies.
5.4. Negotiation and Efficiency
The key management scheme will be used in conjunction with protection
of media traffic. The media traffic typically shows strict real-time
features and requirements. Hence, various kinds of efficient and
tailored protocols/algorithms have to be supported in the Security
Association (SA) definition, e.g., SRTP [SRTP].
>> Req 5.11: the key management scheme MUST support a selection of
efficient security protocols, algorithms, and parameters.
To avoid complexity in the key management protocol, only one single
key-exchange algorithm should be mandatory to implement. Thus, this
needs to be a widely available algorithm with high confidence in its
security, while at the same time, offering acceptable performance
also on relatively thin clients.
>> Req 5.12: The key management protocol SHOULD have one mandatory-
to-implement mode of operation and authentication. Efficient default
settings of algorithms and parameters SHOULD be assumed.
In case relatively computationally expensive key management schemes
are used, optimizations should be performed, e.g., using a key and
security parameters that have been used in a previous communications
session (key resuming). This has to be done in a way not to leak
information.
>> Req 5.13: key caching SHOULD be supported, according to specific
security policies.
5.5. Groups
The way new entities (servers, other callees) join an already
existing session has to be as convenient as possible. When a member
Blom, et al. [Page 7]
INTERNET-DRAFT mm-kmgt July 2001
joins or leaves the group, problems of forward/backward security have
to be solved. A natural consequence of the conversational multimedia
setting is that the sizes of the groups considered are limited.
>> Req 5.14: convenient keying and re-keying mechanisms suitable for
small groups MUST be provided.
Large scale groups might need additional requirement in order to be
able to handle key management in a convenient way (e.g. by
centralized key distribution servers). Therefore, large scale groups
are not considered here. There is current work in the MSEC WG [MSEC].
5.6. Denial of Service
Denial-of-Service (DoS) resistance is one of the features that a key
management scheme has to provide in the type of scenario we are
considering. There are various grades of DoS resistance, and their
performance implications should be carefully studied.
>> Req 5.15: the key management scheme SHOULD NOT create any state
(at the key management protocol level) at the responder side until a
positive authentication has been performed.
Statelessness is typically relatively easy to achieve. However, while
it is a necessary condition to prevent DoS attacks, it is not
sufficient. Typically, public-key based signature verification is an
expensive operation, and attackers may use this to send a flood of
fake connection requests. The victim has to verify all signatures,
which most likely exhausts available resources and prevents
legitimate requests from getting through. There is little that can be
done about this. However, the problem becomes worse if any host in
the Internet can easily perform such attacks without fear of getting
caught. Today, IP source address verification is not generally
applied on the Internet, and as a result hosts can often use faked
source addresses as to prevent tracing the attack to the correct
place. For this reason good protocols typically employ strategies to
ensure that the source address of the peer is routable before they
devote substantial resources to connection establishment, for
instance through requiring the peer to reply to a message containing
cookies.
>> Req 5.16: the key management scheme SHOULD NOT devote substantial
computation resources to peers whose claimed source address has not
been verified to be operational.
Fulfilling this requirement requires additional roundtrips in the
protocol. Since this may not be acceptable in all environments, the
above requirement is only a SHOULD NOT. We also note that it may
Blom, et al. [Page 8]
INTERNET-DRAFT mm-kmgt July 2001
be possible to separate the DoS protection and the key management
protocol from each other, or to make the DoS protection a
configurable option (as is the case between IKE Main and Aggressive
modes).
6. Service Requirements in heterogeneous environment
Conversational multimedia is a very strict real-time scenario. The
call set-up itself poses quite narrow time constraints for service
behavior reasons. Simply said, the user will not use the service if
placing a call takes too long. All of this becomes extremely
sensitive in cellular environments, where bandwidth, speed and use of
thin clients are preeminent factors.
>> Req 6.1: the key management scheme MUST fit the time constraints
posed by the service behavior requirements
Call control protocols, e.g., SIP, are often quite talkative and
rich, therefore they require time; moreover, QoS reservation is
likely to be used, which adds time consumption. Key management has
also to be performed before the media starts: this will add even more
time to the complete call set-up.
A protocol featured by several round trips is particularly painful in
time-constrained scenarios. Hence, it is a necessity to clarify the
functions needed by the system and then establish them with as few
exchanges as possible.
>> Req 6.2: the protocol design MUST strive to reduce the number of
round trips as much as possible.
In wireless networks, packet size often translates into delays. It is
also necessary to minimize excessive use of long messages. This is
however not as critical as the number of round trips.
>> Req 6.3: the protocol design SHOULD reduce the size of the
messages as much as possible.
This also means that negotiation of parameters should be minimized,
and default setting should be used as much as possible as already
stated (Req 5.12).
In addition, security operations, and especially public-key
operations, require much processing time. This is particularly true
in case of thin clients. Therefore, processing time and load should
be taken into account when designing a scheme.
>> Req 6.4: the protocol SHOULD reduce the number of expensive
cryptographic operations as much as possible.
Blom, et al. [Page 9]
INTERNET-DRAFT mm-kmgt July 2001
Schemes involving Diffie-Hellman are in general the most "secure",
however they are also computationally expensive. Lighter schemes may
be designed, e.g. when the session key is generated as a random
number by one of the parties.
A high number of round trips and expensive cryptographic operations
in a key management protocol are generally motivated by the
requirements of achieving a very high level of security and providing
several functions in one protocol. An example is IKE, which can
achieve Perfect Forward Secrecy (PFS) at the expense of a second
(heavy) Diffie-Hellman exchange. However, providing certain functions
may not be necessary in every situation. PFS is an example of
function to be provided only in case it is necessary. Hence, an
analysis of the necessary security functions required by the context
should be performed to avoid unnecessary load to the key management.
>> Req 6.5: in the protocol, only the minimal set of necessary
functions SHOULD be mandatory to implement.
Typically, security protocols become complex through the introduction
of various alternative schemes with varying properties. In an
environment with lightweight end-user equipment, it becomes necessary
to find a basic scheme due to complexity and interoperability
reasons.
7. Security Considerations
Though perhaps needless to say, we stress that the key management
scheme to be employed MUST be designed according to protocol and
cryptographic strong security criteria.
>> Req 7.1: the key management protocol MUST be secure.
No chain is stronger than its weakest link. For instance, with
current state of the art [LV], protecting a 128-bit AES key by a 512-
bit RSA [RSA] key offers an overall security well below 64-bits. On
the other hand, protecting a 64-bit symmetric key by a 2048-bit RSA
key appears to be an overkill, leading to unnecessary time delays.
Therefore, key size for the key-exchange mechanism MUST be weighed
against the size of the exchanged key.
>> Req 7.2: The cryptographic functions protecting keys during
exchange and transport MUST be configurable to offer a security at
least corresponding to the (symmetric) keys they protect.
Moreover, if the session keys are not 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
master key generation. The same applies to re-keying and key-refresh
mechanisms. Policies for key-refresh rates MUST be set so as to avoid
Blom, et al. [Page 10]
INTERNET-DRAFT mm-kmgt July 2001
keystream re-use (for stream-ciphers) and to avoid "non-random"
behavior (e.g. for block-ciphers in feedback-type mode).
>> Req 7.3: good (pseudo) random generators MUST be employed.
DoS is of particular concern. The requirements stated in Section 5.6.
are highly recommended. However, there may be for example a tradeoff
between time saving and better DoS protection. In those cases, if
efficiency is the choice, there must be awareness that a way to
possible DoS attacks may be opened.
8. Conclusions
Key management is a crucial part in a security solution. The present
document has showed that the conversational multimedia scenario,
especially in heterogeneous environment, poses strict requirements to
be fulfilled. Among them, service behavior time restrictions seem to
be a prioritized requirement.
9. Acknowledgments
The authors would like to thank Mats Naslund, Magnus Westerlund, Karl
Norrman, Pasi Ahonen, and Ilkka Uusitalo for their reviews and
comments.
10. Author's Addresses
Rolf Blom
Ericsson Research
SE-16480 Stockholm Phone: +46 8 58531707
Sweden EMail: rolf.blom@era.ericsson.se
Elisabetta Carrara
Ericsson Research
SE-16480 Stockholm Phone: +46 8 50877040
Sweden EMail: elisabetta.carrara@era.ericsson.se
Fredrik Lindholm
Ericsson Research
SE-16480 Stockholm Phone: +46 8 58531705
Sweden EMail: fredrik.lindholm@era.ericsson.se
Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas Phone: +358 40 5079256
Finland Email: jari.arkko@ericsson.com
Blom, et al. [Page 11]
INTERNET-DRAFT mm-kmgt July 2001
11. References
[AES] Advanced Encryption Standard, www.nist.gov/aes
[HAC] Menezes, van Oorshot, and Vanstone, "Handbook of Applied
Cryptograhpy", CRC press 1997.
[IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)",
IETF, RFC 2409.
[IPSEC] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406,and "IP Authentication Header", RFC 2402, November
1998.
[KBRS] Kohl, J., and Neuman, C., "The Kerberos Network Authentication
Service (V5)", IETF, RFC 1510.
[LV] Lenstra, A. K. and Verheul, E. R., "Suggesting Key Sizes for
Cryptosystems", http://www.cryptosavvy.com/suggestions.htm
[MSEC] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group
Domain of Interpretation", Internet Draft, February 2001, and Harney,
H., Colegrove, A., Harder, E., Meth, U., Fleischer, R., "Group Secure
Association Key Management Protocol", Internet Draft, March 2001.
[NAT] Srisuresh, P. and Egevang, K., "Traditional IP Network Address
Translator (Traditional NAT)", IETF, RFC 3022, January 2001.
[PGP] Atkins, D., Stallings, W., and Zimmermann, P., "PGP message
exchange format", IETF, RFC 1991, August 1996.
[RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining
Digital Signatures and Public-Key Cryptosystems". Communications of
the ACM. Vol.21. No.2. pp.120-126. 1978.
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V.,
"RTP: A Transport Protocol for Real-Time Applications", IETF, RFC
1889.
[SDP] Handley, M. and Jacobson, V., "Session Description Protocol
(SDP)", IETF, RFC 2327.
[SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J.,
"SIP: Session Initiation Protocol", IETF, RFC2543.
[SRTP] Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K.,
and Oran, D., "The Secure Real Time Transport Protocol (SRTP),
Internet Draft, February 2001.
Blom, et al. [Page 12]
INTERNET-DRAFT mm-kmgt July 2001
[TLS] Dierks, T. and Allen, C., "The TLS Protocol Version 1.0", IETF,
RFC 2246.
This Internet-Draft expires in December 2001.
Blom, et al. [Page 13]
