GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc5479

Network Working Group D. Wing, Ed. Request for Comments: 5479 Cisco Category: Informational S. Fries

                                                            Siemens AG
                                                         H. Tschofenig
                                                Nokia Siemens Networks
                                                              F. Audet
                                                                Nortel
                                                            April 2009
  Requirements and Analysis of Media Security Management Protocols

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (c) 2009 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents in effect on the date of
 publication of this document (http://trustee.ietf.org/license-info).
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.

Abstract

 This document describes requirements for a protocol to negotiate a
 security context for SIP-signaled Secure RTP (SRTP) media.  In
 addition to the natural security requirements, this negotiation
 protocol must interoperate well with SIP in certain ways.  A number
 of proposals have been published and a summary of these proposals is
 in the appendix of this document.

Wing, et al. Informational [Page 1] RFC 5479 Media Security Requirements April 2009

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
 3.  Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . .  5
 4.  Call Scenarios and Requirements Considerations . . . . . . . .  7
   4.1.  Clipping Media before Signaling Answer . . . . . . . . . .  7
   4.2.  Retargeting and Forking  . . . . . . . . . . . . . . . . .  8
   4.3.  Recording  . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.4.  PSTN Gateway . . . . . . . . . . . . . . . . . . . . . . . 12
   4.5.  Call Setup Performance . . . . . . . . . . . . . . . . . . 12
   4.6.  Transcoding  . . . . . . . . . . . . . . . . . . . . . . . 13
   4.7.  Upgrading to SRTP  . . . . . . . . . . . . . . . . . . . . 13
   4.8.  Interworking with Other Signaling Protocols  . . . . . . . 14
   4.9.  Certificates . . . . . . . . . . . . . . . . . . . . . . . 14
 5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.1.  Key Management Protocol Requirements . . . . . . . . . . . 15
   5.2.  Security Requirements  . . . . . . . . . . . . . . . . . . 16
   5.3.  Requirements outside of the Key Management Protocol  . . . 19
 6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
 7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
 8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
   8.2.  Informative References . . . . . . . . . . . . . . . . . . 21
 Appendix A.  Overview and Evaluation of Existing Keying
              Mechanisms  . . . . . . . . . . . . . . . . . . . . . 24
   A.1.  Signaling Path Keying Techniques . . . . . . . . . . . . . 25
     A.1.1.  MIKEY-NULL . . . . . . . . . . . . . . . . . . . . . . 25
     A.1.2.  MIKEY-PSK  . . . . . . . . . . . . . . . . . . . . . . 25
     A.1.3.  MIKEY-RSA  . . . . . . . . . . . . . . . . . . . . . . 25
     A.1.4.  MIKEY-RSA-R  . . . . . . . . . . . . . . . . . . . . . 25
     A.1.5.  MIKEY-DHSIGN . . . . . . . . . . . . . . . . . . . . . 26
     A.1.6.  MIKEY-DHHMAC . . . . . . . . . . . . . . . . . . . . . 26
     A.1.7.  MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC)  . . . . . . . 26
     A.1.8.  SDP Security Descriptions with SIPS  . . . . . . . . . 26
     A.1.9.  SDP Security Descriptions with S/MIME  . . . . . . . . 27
     A.1.10. SDP-DH (Expired) . . . . . . . . . . . . . . . . . . . 27
     A.1.11. MIKEYv2 in SDP (Expired) . . . . . . . . . . . . . . . 27
   A.2.  Media Path Keying Technique  . . . . . . . . . . . . . . . 27
     A.2.1.  ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 27
   A.3.  Signaling and Media Path Keying Techniques . . . . . . . . 28
     A.3.1.  EKT  . . . . . . . . . . . . . . . . . . . . . . . . . 28
     A.3.2.  DTLS-SRTP  . . . . . . . . . . . . . . . . . . . . . . 28
     A.3.3.  MIKEYv2 Inband (Expired) . . . . . . . . . . . . . . . 29
   A.4.  Evaluation Criteria - SIP  . . . . . . . . . . . . . . . . 29
     A.4.1.  Secure Retargeting and Secure Forking  . . . . . . . . 29
     A.4.2.  Clipping Media before SDP Answer . . . . . . . . . . . 31
     A.4.3.  SSRC and ROC . . . . . . . . . . . . . . . . . . . . . 33

Wing, et al. Informational [Page 2] RFC 5479 Media Security Requirements April 2009

   A.5.  Evaluation Criteria - Security . . . . . . . . . . . . . . 35
     A.5.1.  Distribution and Validation of Persistent Public
             Keys and Certificates  . . . . . . . . . . . . . . . . 35
     A.5.2.  Perfect Forward Secrecy  . . . . . . . . . . . . . . . 38
     A.5.3.  Best Effort Encryption . . . . . . . . . . . . . . . . 39
     A.5.4.  Upgrading Algorithms . . . . . . . . . . . . . . . . . 40
 Appendix B.  Out-of-Scope  . . . . . . . . . . . . . . . . . . . . 42
   B.1.  Shared Key Conferencing  . . . . . . . . . . . . . . . . . 42

1. Introduction

 The work on media security started when the Session Initiation
 Protocol (SIP) was still in its infancy.  With the increased SIP
 deployment and the availability of new SIP extensions and related
 protocols, the need for end-to-end security was re-evaluated.  The
 procedure of re-evaluating prior protocol work and design decisions
 is not an uncommon strategy and, to some extent, considered necessary
 to ensure that the developed protocols indeed meet the previously
 envisioned needs for the users on the Internet.
 This document summarizes media security requirements, i.e.,
 requirements for mechanisms that negotiate security context such as
 cryptographic keys and parameters for SRTP.
 The organization of this document is as follows: Section 2 introduces
 terminology, Section 3 describes various attack scenarios against the
 signaling path and media path, Section 4 provides an overview about
 possible call scenarios, and Section 5 lists requirements for media
 security.  The main part of the document concludes with the security
 considerations Section 6, and acknowledgements in Section 7.
 Appendix A lists and compares available solution proposals.  The
 following Appendix A.4 compares the different approaches regarding
 their suitability for the SIP signaling scenarios described in
 Appendix A, while Appendix A.5 provides a comparison regarding
 security aspects.  Appendix B lists non-goals for this document.

2. Terminology

 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 [RFC2119], with the
 important qualification that, unless otherwise stated, these terms
 apply to the design of the media security key management protocol,
 not its implementation or application.
 Furthermore, the terminology described in SIP [RFC3261] regarding
 functions and components are used throughout the document.

Wing, et al. Informational [Page 3] RFC 5479 Media Security Requirements April 2009

 Additionally, the following items are used in this document:
 AOR (Address-of-Record):   A SIP or SIPS URI that points to a domain
    with a location service that can map the URI to another URI where
    the user might be available.  Typically, the location service is
    populated through registrations.  An AOR is frequently thought of
    as the "public address" of the user.
 SSRC:  The 32-bit value that defines the synchronization source, used
    in RTP.  These are generally unique, but collisions can occur.
 two-time pad:  The use of the same key and the same keystream to
    encrypt different data.  For SRTP, a two-time pad occurs if two
    senders are using the same key and the same RTP SSRC value.
 Perfect Forward Secrecy (PFS):  The property that disclosure of the
    long-term secret keying material that is used to derive an agreed
    ephemeral key does not compromise the secrecy of agreed keys from
    earlier runs.
 active adversary:  An active adversary is able to alter data
    communication to affect its operation (see also [RFC4949]).
 passive adversary:  A passive adversary is able to learn information
    from data communication, but not alter that data communication
    (see also [RFC4949]).
 signaling path:  The signaling path is the route taken by SIP
    signaling messages transmitted between the calling and called user
    agents.  This can be either direct signaling between the calling
    and called user agents or, more commonly, involves the SIP proxy
    servers that were involved in the call setup.
 media path:  The media path is the route taken by media packets
    exchanged by the endpoints.  In the simplest case, the endpoints
    exchange media directly, and the "media path" is defined by a
    quartet of IP addresses and TCP/UDP ports, along with an IP route.
    In other cases, this path may include RTP relays, mixers,
    transcoders, session border controllers, NATs, or media gateways.
 Moreover, as this document discusses requirements for media security,
 the nomenclature R-XXX is used to mark requirements, where XXX is the
 requirement, which needs to be met.

Wing, et al. Informational [Page 4] RFC 5479 Media Security Requirements April 2009

3. Attack Scenarios

 The discussion in this section relates to requirements R-ASSOC
 (specified in Section 5.1) R-PASS-MEDIA, R-PASS-SIG, R-SIG-MEDIA,
 R-ACT-ACT, and R-ID-BINDING (specified in Section 5.2).
 This document classifies adversaries according to their access and
 their capabilities.  An adversary might have access:
 1.  only to the media path,
 2.  only to the signaling path,
 3.  to the media path and to the signaling path.
 An attacker that can solely be located along the signaling path, and
 does not have access to media (item 2), is not considered in this
 document.
 There are two different types of adversaries: active and passive.  An
 active adversary may need to be active with regard to the key
 exchange relevant information traveling along the media path or
 traveling along the signaling path.
 Based on their robustness against the adversary capabilities
 described above, we can group security mechanisms using the following
 labels.  This list is generally ordered from easiest to compromise
 (at the top) to more difficult to compromise:
  +---------------+---------+--------------------------------------+
  | SIP signaling |  media  |             abbreviation             |
  +---------------+---------+--------------------------------------+
  |      none     | passive |      no-signaling-passive-media      |
  |      none     |  active |       no-signaling-active-media      |
  |    passive    | passive |    passive-signaling-passive-media   |
  |    passive    |  active |    passive-signaling-active-media    |
  |     active    | passive |    active-signaling-passive-media    |
  |     active    |  active |     active-signaling-active-media    |
  |     active    |  active | active-signaling-active-media-detect |
  +---------------+---------+--------------------------------------+
 no-signaling-passive-media:
    Access only to the media path is sufficient to reveal the content
    of the media traffic.
 passive-signaling-passive-media:
    Passive attack on the signaling and passive attack on the media
    path is necessary to reveal the content of the media traffic.

Wing, et al. Informational [Page 5] RFC 5479 Media Security Requirements April 2009

 passive-signaling-active-media:
    Passive attack on the signaling and active attack on the media
    path is necessary to reveal the content of the media traffic.
 active-signaling-passive-media:
    Active attack on the signaling path and passive attack on the
    media path is necessary to reveal the content of the media
    traffic.
 no-signaling-active-media:
    Active attack on the media path is sufficient to reveal the
    content of the media traffic.
 active-signaling-active-media:
    Active attack on both the signaling path and the media path is
    necessary to reveal the content of the media traffic.
 active-signaling-active-media-detect:
    Active attack on both signaling and media path is necessary to
    reveal the content of the media traffic (as with active-signaling-
    active-media), and the attack is detectable by protocol messages
    exchanged between the endpoints.
 For example, unencrypted RTP is vulnerable to no-signaling-passive-
 media.
 As another example, SDP Security Descriptions [RFC4568], when
 protected by TLS (as it is commonly implemented and deployed), belong
 in the passive-signaling-passive-media category since the adversary
 needs to learn the SDP Security Descriptions key by seeing the SIP
 signaling message at a SIP proxy (assuming that the adversary is in
 control of the SIP proxy).  The media traffic can be decrypted using
 that learned key.
 As another example, DTLS-SRTP (Datagram Transport Layer Security
 Extension for SRTP) falls into active-signaling-active-media category
 when DTLS-SRTP is used with a public-key-based ciphersuite with self-
 signed certificates and without SIP Identity [RFC4474].  An adversary
 would have to modify the fingerprint that is sent along the signaling
 path and subsequently to modify the certificates carried in the DTLS
 handshake that travel along the media path.  If DTLS-SRTP is used
 with both SIP Identity [RFC4474] and SIP Connected Identity
 [RFC4916], the RFC-4474 signature protects both the offer and the
 answer, and such a system would then belong to the active-signaling-
 active-media-detect category (provided, of course, the signaling path
 to the RFC-4474 authenticator and verifier is secured as per RFC
 4474, and the RFC-4474 authenticator and verifier are behaving as per
 RFC 4474).

Wing, et al. Informational [Page 6] RFC 5479 Media Security Requirements April 2009

 The above discussion of DTLS-SRTP demonstrates how a single security
 protocol can be in different classes depending on the mode in which
 it is operated.  Other protocols can achieve a similar effect by
 adding functions outside of the on-the-wire key management protocol
 itself.  Although it may be appropriate to deploy lower-classed
 mechanisms in some cases, the ultimate security requirement for a
 media security negotiation protocol is that it have a mode of
 operation available in which is detect-attack, which provides
 protection against the passive and active attacks and provides
 detection of such attacks.  That is, there must be a way to use the
 protocol so that an active attack is required against both the
 signaling and media paths, and so that such attacks are detectable by
 the endpoints.

4. Call Scenarios and Requirements Considerations

 The following subsections describe call scenarios that pose the most
 challenge to the key management system for media data in cooperation
 with SIP signaling.
 Throughout the subsections, requirements are stated by using the
 nomenclature R- to state an explicit requirement.  All of the stated
 requirements are explained in detail in Section 5.  They are listed
 according to their association to the key management protocol, to
 attack scenarios, and requirements that can be met inside the key
 management protocol or outside of the key management protocol.

4.1. Clipping Media before Signaling Answer

 The discussion in this section relates to requirements R-AVOID-
 CLIPPING and R-ALLOW-RTP.
 Per the Session Description Protocol (SDP) Offer/Answer Model
 [RFC3264]:
    Once the offerer has sent the offer, it MUST be prepared to
    receive media for any recvonly streams described by that offer.
    It MUST be prepared to send and receive media for any sendrecv
    streams in the offer, and send media for any sendonly streams in
    the offer (of course, it cannot actually send until the peer
    provides an answer with the needed address and port information).
 To meet this requirement with SRTP, the offerer needs to know the
 SRTP key for arriving media.  If either endpoint receives encrypted
 media before it has access to the associated SRTP key, it cannot play
 the media -- causing clipping.

Wing, et al. Informational [Page 7] RFC 5479 Media Security Requirements April 2009

 For key exchange mechanisms that send the answerer's key in SDP, a
 SIP provisional response [RFC3261], such as 183 (session progress),
 is useful.  However, the 183 messages are not reliable unless both
 the calling and called endpoint support Provisional Response
 ACKnowledgement (PRACK) [RFC3262], use TCP across all SIP proxies,
 implement Security Preconditions [RFC5027], or both ends implement
 Interactive Connectivity Establishment [ICE] and the answerer
 implements the reliable provisional response mechanism described in
 ICE.  Unfortunately, there is not wide deployment of any of these
 techniques and there is industry reluctance to require these
 techniques to avoid the problems described in this section.
 Note that the receipt of an SDP answer is not always sufficient to
 allow media to be played to the offerer.  Sometimes, the offerer must
 send media in order to open up firewall holes or NAT bindings before
 media can be received (for details, see [MIDDLEBOX]).  In this case,
 even a solution that makes the key available before the SDP answer
 arrives will not help.
 Preventing the arrival of early media (i.e., media that arrives at
 the SDP offerer before the SDP answer arrives) might obsolete the
 R-AVOID-CLIPPING requirement, but at the time of writing such early
 media exists in many normal call scenarios.

4.2. Retargeting and Forking

 The discussion in this section relates to requirements R-FORK-
 RETARGET, R-DISTINCT, R-HERFP, and R-BEST-SECURE.
 In SIP, a request sent to a specific AOR but delivered to a different
 AOR is called a "retarget".  A typical scenario is a "call
 forwarding" feature.  In Figure 1, Alice sends an INVITE in step 1
 that is sent to Bob in step 2.  Bob responds with a redirect (SIP
 response code 3xx) pointing to Carol in step 3.  This redirect
 typically does not propagate back to Alice but only goes to a proxy
 (i.e., the retargeting proxy) that sends the original INVITE to Carol
 in step 4.

Wing, et al. Informational [Page 8] RFC 5479 Media Security Requirements April 2009

                              +-----+
                              |Alice|
                              +--+--+
                                 |
                                 | INVITE (1)
                                 V
                            +----+----+
                            |  proxy  |
                            ++-+-----++
                             | ^     |
                  INVITE (2) | |     | INVITE (4)
              & redirect (3) | |     |
                             V |     V
                            ++-++   ++----+
                            |Bob|   |Carol|
                            +---+   +-----+
                         Figure 1: Retargeting
 Using retargeting might lead to situations where the User Agent
 Client (UAC) does not know where its request will be going.  This
 might not immediately seem like a serious problem; after all, when
 one places a telephone call on the Public Switched Telephone Network
 (PSTN), one never really knows if it will be forwarded to a different
 number, who will pick up the line when it rings, and so on.  However,
 when considering SIP mechanisms for authenticating the called party,
 this function can also make it difficult to differentiate an
 intermediary that is behaving legitimately from an attacker.  From
 this perspective, the main problems with retargeting are:
 Not detectable by the caller:   The originating user agent has no
    means of anticipating that the condition will arise, nor any means
    of determining that it has occurred until the call has already
    been set up.
 Not preventable by the caller:  There is no existing mechanism that
    might be employed by the originating user agent in order to
    guarantee that the call will not be retargeted.
 The mechanism used by SIP for identifying the calling party is SIP
 Identity [RFC4474].  However, due to the nature of retargeting, SIP
 Identity can only identify the calling party (that is, the party that
 initiated the SIP request).  Some key exchange mechanisms predate SIP
 Identity and include their own identity mechanism (e.g., Multimedia
 Internet KEYing (MIKEY)).  However, those built-in identity mechanism
 also suffer from the SIP retargeting problem.  While Connected
 Identity [RFC4916] allows positive identification of the called
 party, the primary difficulty still remains that the calling party

Wing, et al. Informational [Page 9] RFC 5479 Media Security Requirements April 2009

 does not know if a mismatched called party is legitimate (i.e., due
 to authorized retargeting) or illegitimate (i.e., due to unauthorized
 retargeting by an attacker above to modify SIP signaling).
 In SIP, 'forking' is the delivery of a request to multiple locations.
 This happens when a single AOR is registered more than once.  An
 example of forking is when a user has a desk phone, PC client, and
 mobile handset all registered with the same AOR.
                             +-----+
                             |Alice|
                             +--+--+
                                |
                                | INVITE
                                V
                          +-----+-----+
                          |   proxy   |
                          ++---------++
                           |         |
                    INVITE |         | INVITE
                           V         V
                        +--+--+   +--+--+
                        |Bob-1|   |Bob-2|
                        +-----+   +-----+
                       Figure 2: Forking
 With forking, both Bob-1 and Bob-2 might send back SDP answers in SIP
 responses.  Alice will see those intermediate (18x) and final (200)
 responses.  It is useful for Alice to be able to associate the SIP
 response with the incoming media stream.  Although this association
 can be done with ICE [ICE], and ICE is useful to make this
 association with RTP, it is not desirable to require ICE to
 accomplish this association.
 Forking and retargeting are often used together.  For example, a boss
 and secretary might have both phones ring (forking) and rollover to
 voice mail if neither phone is answered (retargeting).
 To maintain the security of the media traffic, only the endpoint that
 answers the call should know the SRTP keys for the session.  Forked
 and retargeted calls only reveal sensitive information to non-
 responders when the signaling messages contain sensitive information
 (e.g., SRTP keys) that is accessible by parties that receive the
 offer, but may not respond (i.e., the original recipients in a
 retargeted call, or non-answering endpoints in a forked call).  For
 key exchange mechanisms that do not provide secure forking or secure
 retargeting, one workaround is to rekey immediately after forking or

Wing, et al. Informational [Page 10] RFC 5479 Media Security Requirements April 2009

 retargeting.  However, because the originator may not be aware that
 the call forked this mechanism requires rekeying immediately after
 every session is established.  This doubles the number of messages
 processed by the network.
 Further compounding this problem is a unique feature of SIP that,
 when forking is used, there is always only one final error response
 delivered to the sender of the request: the forking proxy is
 responsible for choosing which final response to choose in the event
 where forking results in multiple final error responses being
 received by the forking proxy.  This means that if a request is
 rejected, say with information that the keying information was
 rejected and providing the far end's credentials, it is very possible
 that the rejection will never reach the sender.  This problem, called
 the Heterogeneous Error Response Forking Problem (HERFP) [RFC3326],
 is difficult to solve in SIP.  Because we expect the HERFP to
 continue to be a problem in SIP for the foreseeable future, a media
 security system should function even in the presence of HERFP
 behavior.

4.3. Recording

 The discussion in this section relates to requirement R-RECORDING.
 Some business environments, such as stock brokerages, banks, and
 catalog call centers, require recording calls with customers.  This
 is the familiar "this call is being recorded for quality purposes"
 heard during calls to these sorts of businesses.  In these
 environments, media recording is typically performed by an
 intermediate device (with RTP, this is typically implemented in a
 'sniffer').
 When performing such call recording with SRTP, the end-to-end
 security is compromised.  This is unavoidable, but necessary because
 the operation of the business requires such recording.  It is
 desirable that the media security is not unduly compromised by the
 media recording.  The endpoint within the organization needs to be
 informed that there is an intermediate device and needs to cooperate
 with that intermediate device.
 This scenario does not place a requirement directly on the key
 management protocol.  The requirement could be met directly by the
 key management protocol (e.g., MIKEY-NULL or [RFC4568]) or through an
 external out-of-band mechanism (e.g., [SRTP-KEY]).

Wing, et al. Informational [Page 11] RFC 5479 Media Security Requirements April 2009

4.4. PSTN Gateway

 The discussion in this section relates to requirement R-PSTN.
 It is desirable, even when one leg of a call is on the PSTN, that the
 IP leg of the call be protected with SRTP.
 A typical case of using media security where two entities are having
 a Voice over IP (VoIP) conversation over IP-capable networks.
 However, there are cases where the other end of the communication is
 not connected to an IP-capable network.  In this kind of setting,
 there needs to be some kind of gateway at the edge of the IP network
 that converts the VoIP conversation to a format understood by the
 other network.  An example of such a gateway is a PSTN gateway
 sitting at the edge of IP and PSTN networks (such as the architecture
 described in [RFC3372]).
 If media security (e.g., SRTP protection) is employed in this kind of
 gateway-setting, then media security and the related key management
 is terminated at the PSTN gateway.  The other network (e.g., PSTN)
 may have its own measures to protect the communication, but this
 means that from media security point of view the media security is
 not employed truly end-to-end between the communicating entities.

4.5. Call Setup Performance

 The discussion in this section relates to requirement R-REUSE.
 Some devices lack sufficient processing power to perform public key
 operations or Diffie-Hellman operations for each call, or prefer to
 avoid performing those operations on every call.  The ability to
 reuse previous public key or Diffie-Hellman operations can vastly
 decrease the call setup delay and processing requirements for such
 devices.
 In certain devices, it can take a second or two to perform a Diffie-
 Hellman operation.  Examples of these devices include handsets, IP
 Multimedia Services Identity Modules (ISIMs), and PSTN gateways.
 PSTN gateways typically utilize a Digital Signal Processor (DSP) that
 is not yet involved with typical DSP operations at the beginning of a
 call; thus, the DSP could be used to perform the calculation, so as
 to avoid having the central host processor perform the calculation.
 However, not all PSTN gateways use DSPs (some have only central
 processors or their DSPs are incapable of performing the necessary
 public key or Diffie-Hellman operation), and handsets lack a
 separate, unused processor to perform these operations.

Wing, et al. Informational [Page 12] RFC 5479 Media Security Requirements April 2009

 Two scenarios where R-REUSE is useful are calls between an endpoint
 and its voicemail server or its PSTN gateway.  In those scenarios,
 calls are made relatively often and it can be useful for the
 voicemail server or PSTN gateway to avoid public key operations for
 subsequent calls.
 Storing keys across sessions often interferes with perfect forward
 secrecy (R-PFS).

4.6. Transcoding

 The discussion in this section relates to requirement R-TRANSCODER.
 In some environments, it is necessary for network equipment to
 transcode from one codec (e.g., a highly compressed codec that makes
 efficient use of wireless bandwidth) to another codec (e.g., a
 standardized codec to a SIP peering interface).  With RTP, a
 transcoding function can be performed with the combination of a SIP
 back-to-back user agent (B2BUA) to modify the SDP and a processor to
 perform the transcoding between the codecs.  However, with end-to-end
 secured SRTP, a transcoding function implemented the same way is a
 man-in-the-middle attack, and the key management system prevents its
 use.
 However, such a network-based transcoder can still be realized with
 the cooperation and approval of the endpoint, and can provide end-to-
 transcoder and transcoder-to-end security.

4.7. Upgrading to SRTP

 The discussion in this section relates to the requirement R-ALLOW-
 RTP.
 Legitimate RTP media can be sent to an endpoint for announcements,
 colorful ringback tones (e.g., music), advertising, or normal call
 progress tones.  The RTP may be received before an associated SDP
 answer.  For details on various scenarios, see [EARLY-MEDIA].
 While receiving such RTP exposes the calling party to a risk of
 receiving malicious RTP from an attacker, SRTP endpoints will need to
 receive and play out RTP media in order to be compatible with
 deployed systems that send RTP to calling parties.

Wing, et al. Informational [Page 13] RFC 5479 Media Security Requirements April 2009

4.8. Interworking with Other Signaling Protocols

 The discussion in this section relates to the requirement R-OTHER-
 SIGNALING.
 In many environments, some devices are signaled with protocols other
 than SIP that do not share SIP's offer/answer model (e.g., [H.248.1]
 or do not utilize SDP (e.g., H.323).  In other environments, both
 endpoints may be SIP, but may use different key management systems
 (e.g., one uses MIKEY-RSA, the other MIKEY-RSA-R).
 In these environments, it is desirable to have SRTP -- rather than
 RTP -- between the two endpoints.  It is always possible, although
 undesirable, to interwork those disparate signaling systems or
 disparate key management systems by decrypting and re-encrypting each
 SRTP packet in a device in the middle of the network (often the same
 device performing the signaling interworking).  This is undesirable
 due to the cost and increased attack area, as such an SRTP/SRTP
 interworking device is a valuable attack target.
 At the time of this writing, interworking is considered important.
 Interworking without decryption/encryption of the SRTP, while useful,
 is not yet deemed critical because the scale of such SRTP deployments
 is, to date, relatively small.

4.9. Certificates

 The discussion in this section relates to R-CERTS.
 On the Internet and on some private networks, validating another
 peer's certificate is often done through a trust anchor -- a list of
 Certificate Authorities that are trusted.  It can be difficult or
 expensive for a peer to obtain these certificates.  In all cases,
 both parties to the call would need to trust the same trust anchor
 (i.e., "certificate authority").  For these reasons, it is important
 that the media plane key management protocol offer a mechanism that
 allows end-users who have no prior association to authenticate to
 each other without acquiring credentials from a third-party trust
 point.  Note that this does not rule out mechanisms in which servers
 have certificates and attest to the identities of end-users.

5. Requirements

 This section is divided into several parts: requirements specific to
 the key management protocol (Section 5.1), attack scenarios
 (Section 5.2), and requirements that can be met inside the key
 management protocol or outside of the key management protocol
 (Section 5.3).

Wing, et al. Informational [Page 14] RFC 5479 Media Security Requirements April 2009

5.1. Key Management Protocol Requirements

 SIP Forking and Retargeting, from Section 4.2:
 R-FORK-RETARGET:
                   The media security key management protocol MUST
                   securely support forking and retargeting when all
                   endpoints are willing to use SRTP without causing
                   the call setup to fail.  This requirement means the
                   endpoints that did not answer the call MUST NOT
                   learn the SRTP keys (in either direction) used by
                   the answering endpoint.
 R-DISTINCT:
              The media security key management protocol MUST be
              capable of creating distinct, independent cryptographic
              contexts for each endpoint in a forked session.
 R-HERFP:
           The media security key management protocol MUST function
           securely even in the presence of HERFP behavior, i.e., the
           rejection of key information does not reach the sender.
 Performance considerations:
 R-REUSE:
           The media security key management protocol MAY support the
           reuse of a previously established security context.
       Note: reuse of the security context does not imply reuse of RTP
             parameters (e.g., payload type or SSRC).
 Media considerations:
 R-AVOID-CLIPPING:
                    The media security key management protocol SHOULD
                    avoid clipping media before SDP answer without
                    requiring Security Preconditions [RFC5027].  This
                    requirement comes from Section 4.1.
 R-RTP-CHECK:
               If SRTP key negotiation is performed over the media
               path (i.e., using the same UDP/TCP ports as media
               packets), the key negotiation packets MUST NOT pass the
               RTP validity check defined in Appendix A.1 of
               [RFC3550], so that SRTP negotiation packets can be
               differentiated from RTP packets.

Wing, et al. Informational [Page 15] RFC 5479 Media Security Requirements April 2009

 R-ASSOC:
           The media security key management protocol SHOULD include a
           mechanism for associating key management messages with both
           the signaling traffic that initiated the session and with
           protected media traffic.  It is useful to associate key
           management messages with call signaling messages, as this
           allows the SDP offerer to avoid performing CPU-consuming
           operations (e.g., Diffie-Hellman or public key operations)
           with attackers that have not seen the signaling messages.
           For example, if using a Diffie-Hellman keying technique
           with security preconditions that forks to 20 endpoints, the
           call initiator would get 20 provisional responses
           containing 20 signed Diffie-Hellman key pairs.  Calculating
           20 Diffie-Hellman secrets and validating signatures can be
           a difficult task for some devices.  Hence, in the case of
           forking, it is not desirable to perform a Diffie-Hellman
           operation with every party, but rather only with the party
           that answers the call (and incur some media clipping).  To
           do this, the signaling and media need to be associated so
           the calling party knows which key management exchange needs
           to be completed.  This might be done by using the transport
           address indicated in the SDP, although NATs can complicate
           this association.
       Note: due to RTP's design requirements, it is expected that
             SRTP receivers will have to perform authentication of any
             received SRTP packets.
 R-NEGOTIATE:
               The media security key management protocol MUST allow a
               SIP User Agent to negotiate media security parameters
               for each individual session.  Such negotiation MUST NOT
               cause a two-time pad (Section 9.1 of [RFC3711]).
 R-PSTN:
          The media security key management protocol MUST support
          termination of media security in a PSTN gateway.  This
          requirement is from Section 4.4.

5.2. Security Requirements

 This section describes overall security requirements and specific
 requirements from the attack scenarios (Section 3).

Wing, et al. Informational [Page 16] RFC 5479 Media Security Requirements April 2009

 Overall security requirements:
 R-PFS:
         The media security key management protocol MUST be able to
         support perfect forward secrecy.
 R-COMPUTE:
             The media security key management protocol MUST support
             offering additional SRTP cipher suites without incurring
             significant computational expense.
 R-CERTS:
           The key management protocol MUST NOT require that end-users
           obtain credentials (certificates or private keys) from a
           third- party trust anchor.
 R-FIPS:
          The media security key management protocol SHOULD use
          algorithms that allow FIPS 140-2 [FIPS-140-2] certification
          or similar country-specific certification (e.g.,
          [AISITSEC]).
          The United States Government can only purchase and use
          crypto implementations that have been validated by the
          FIPS-140 [FIPS-140-2] process:
       The FIPS-140 standard is applicable to all Federal agencies
             that use cryptographic-based security systems to protect
             sensitive information in computer and telecommunication
             systems, including voice systems.  The adoption and use
             of this standard is available to private and commercial
             organizations.
       Some commercial organizations, such as banks and defense
       contractors, require or prefer equipment that has received the
       same validation.
 R-DOS:
         The media security key management protocol MUST NOT introduce
         any new significant denial-of-service vulnerabilities (e.g.,
         the protocol should not request the endpoint to perform CPU-
         intensive operations without the client being able to
         validate or authorize the request).

Wing, et al. Informational [Page 17] RFC 5479 Media Security Requirements April 2009

 R-EXISTING:
              The media security key management protocol SHOULD allow
              endpoints to authenticate using pre-existing
              cryptographic credentials, e.g., certificates or
              pre-shared keys.
 R-AGILITY:
             The media security key management protocol MUST provide
             crypto- agility, i.e., the ability to adapt to evolving
             cryptography and security requirements (update of
             cryptographic algorithms without substantial disruption
             to deployed implementations).
 R-DOWNGRADE:
               The media security key management protocol MUST protect
               cipher suite negotiation against downgrading attacks.
 R-PASS-MEDIA:
                The media security key management protocol MUST have a
                mode that prevents a passive adversary with access to
                the media path from gaining access to keying material
                used to protect SRTP media packets.
 R-PASS-SIG:
              The media security key management protocol MUST have a
              mode in which it prevents a passive adversary with
              access to the signaling path from gaining access to
              keying material used to protect SRTP media packets.
 R-SIG-MEDIA:
               The media security key management protocol MUST have a
               mode in which it defends itself from an attacker that
               is solely on the media path and from an attacker that
               is solely on the signaling path.  A successful attack
               refers to the ability for the adversary to obtain
               keying material to decrypt the SRTP encrypted media
               traffic.
 R-ID-BINDING:
                The media security key management protocol MUST enable
                the media security keys to be cryptographically bound
                to an identity of the endpoint.
       Note: This allows domains to deploy SIP Identity [RFC4474].

Wing, et al. Informational [Page 18] RFC 5479 Media Security Requirements April 2009

 R-ACT-ACT:
             The media security key management protocol MUST support a
             mode of operation that provides
             active-signaling-active-media-detect robustness, and MAY
             support modes of operation that provide lower levels of
             robustness (as described in Section 3).
       Note: Failing to meet R-ACT-ACT indicates the protocol cannot
             provide secure end-to-end media.

5.3. Requirements outside of the Key Management Protocol

 The requirements in this section are for an overall VoIP security
 system.  These requirements can be met within the key management
 protocol itself, or can be solved outside of the key management
 protocol itself (e.g., solved in SIP or in SDP).
 R-BEST-SECURE:
                 Even when some endpoints of a forked or retargeted
                 call are incapable of using SRTP, a solution MUST be
                 described that allows the establishment of SRTP
                 associations with SRTP-capable endpoints and/or RTP
                 associations with non-SRTP-capable endpoints.
 R-OTHER-SIGNALING:
                     A solution SHOULD be able to negotiate keys for
                     SRTP sessions created via different call
                     signaling protocols (e.g., between Jabber, SIP,
                     H.323, Media Gateway Control Protocol (MGCP).
 R-RECORDING:
               A solution SHOULD be described that supports recording
               of decrypted media.  This requirement comes from
               Section 4.3.
 R-TRANSCODER:
                A solution SHOULD be described that supports
                intermediate nodes (e.g., transcoders), terminating or
                processing media, between the endpoints.
 R-ALLOW-RTP:  A solution SHOULD be described that allows RTP media to
               be received by the calling party until SRTP has been
               negotiated with the answerer, after which SRTP is
               preferred over RTP.

Wing, et al. Informational [Page 19] RFC 5479 Media Security Requirements April 2009

6. Security Considerations

 This document lists requirements for securing media traffic.  As
 such, it addresses security throughout the document.

7. Acknowledgements

 For contributions to the requirements portion of this document, the
 authors would like to thank the active participants of the RTPSEC BoF
 and on the RTPSEC mailing list, and a special thanks to Steffen Fries
 and Dragan Ignjatic for their excellent MIKEY comparison [RFC5197]
 document.
 The authors would furthermore like to thank the following people for
 their review, suggestions, and comments: Flemming Andreasen, Richard
 Barnes, Mark Baugher, Wolfgang Buecker, Werner Dittmann, Lakshminath
 Dondeti, John Elwell, Martin Euchner, Hans-Heinrich Grusdt, Christer
 Holmberg, Guenther Horn, Peter Howard, Leo Huang, Dragan Ignjatic,
 Cullen Jennings, Alan Johnston, Vesa Lehtovirta, Matt Lepinski, David
 McGrew, David Oran, Colin Perkins, Eric Raymond, Eric Rescorla, Peter
 Schneider, Frank Shearar, Srinath Thiruvengadam, Dave Ward, Dan York,
 and Phil Zimmermann.

8. References

8.1. Normative References

 [FIPS-140-2]   NIST, "Security Requirements for Cryptographic
                Modules", June 2005, <http://csrc.nist.gov/
                publications/fips/fips140-2/fips1402.pdf>.
 [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3261]      Rosenberg, J., Schulzrinne, H., Camarillo, G.,
                Johnston, A., Peterson, J., Sparks, R., Handley, M.,
                and E. Schooler, "SIP: Session Initiation Protocol",
                RFC 3261, June 2002.
 [RFC3262]      Rosenberg, J. and H. Schulzrinne, "Reliability of
                Provisional Responses in Session Initiation Protocol
                (SIP)", RFC 3262, June 2002.
 [RFC3264]      Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
                Model with Session Description Protocol (SDP)",
                RFC 3264, June 2002.

Wing, et al. Informational [Page 20] RFC 5479 Media Security Requirements April 2009

 [RFC3711]      Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
                K. Norrman, "The Secure Real-time Transport Protocol
                (SRTP)", RFC 3711, March 2004.

8.2. Informative References

 [AISITSEC]     Bundesamt fuer Sicherheit in der Informationstechnik
                [Federal Office of Information Security - Germany],
                "Anwendungshinweise und Interpretationen (AIS) zu
                ITSEC", January 2002,
                <http://www.bsi.de/zertifiz/zert/interpr/
                aisitsec.htm>.
 [DTLS-SRTP]    McGrew, D. and E. Rescorla, "Datagram Transport Layer
                Security (DTLS) Extension to Establish Keys for Secure
                Real-time Transport Protocol (SRTP)", Work
                in Progress, October 2008.
 [EARLY-MEDIA]  Stucker, B., "Coping with Early Media in the Session
                Initiation Protocol (SIP)", Work in Progress,
                October 2006.
 [EKT]          McGrew, D., "Encrypted Key Transport for Secure RTP",
                Work in Progress, July 2007.
 [H.248.1]      ITU, "Gateway control protocol", Recommendation H.248,
                June 2000, <http://www.itu.int/rec/T-REC-H.248/e>.
 [ICE]          Rosenberg, J., "Interactive Connectivity Establishment
                (ICE): A Protocol for Network Address  Translator
                (NAT) Traversal for Offer/Answer Protocols", Work
                in Progress, October 2007.
 [MIDDLEBOX]    Stucker, B. and H. Tschofenig, "Analysis of Middlebox
                Interactions for Signaling Protocol Communication
                along the Media Path", Work in Progress, July 2008.
 [MIKEY-ECC]    Milne, A., "ECC Algorithms for MIKEY", Work
                in Progress, June 2007.
 [MIKEYv2]      Dondeti, L., "MIKEYv2: SRTP Key Management using
                MIKEY, revisited", Work in Progress, March 2007.
 [MULTIPART]    Wing, D. and C. Jennings, "Session Initiation Protocol
                (SIP) Offer/Answer with Multipart Alternative", Work
                in Progress, March 2006.

Wing, et al. Informational [Page 21] RFC 5479 Media Security Requirements April 2009

 [RFC3326]      Schulzrinne, H., Oran, D., and G. Camarillo, "The
                Reason Header Field for the Session Initiation
                Protocol (SIP)", RFC 3326, December 2002.
 [RFC3372]      Vemuri, A. and J. Peterson, "Session Initiation
                Protocol for Telephones (SIP-T): Context and
                Architectures", BCP 63, RFC 3372, September 2002.
 [RFC3550]      Schulzrinne, H., Casner, S., Frederick, R., and V.
                Jacobson, "RTP: A Transport Protocol for Real-Time
                Applications", STD 64, RFC 3550, July 2003.
 [RFC3830]      Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
                K. Norrman, "MIKEY: Multimedia Internet KEYing",
                RFC 3830, August 2004.
 [RFC4474]      Peterson, J. and C. Jennings, "Enhancements for
                Authenticated Identity Management in the Session
                Initiation Protocol (SIP)", RFC 4474, August 2006.
 [RFC4492]      Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,
                and B. Moeller, "Elliptic Curve Cryptography (ECC)
                Cipher Suites for Transport Layer Security (TLS)",
                RFC 4492, May 2006.
 [RFC4568]      Andreasen, F., Baugher, M., and D. Wing, "Session
                Description Protocol (SDP) Security Descriptions for
                Media Streams", RFC 4568, July 2006.
 [RFC4650]      Euchner, M., "HMAC-Authenticated Diffie-Hellman for
                Multimedia Internet KEYing (MIKEY)", RFC 4650,
                September 2006.
 [RFC4738]      Ignjatic, D., Dondeti, L., Audet, F., and P. Lin,
                "MIKEY-RSA-R: An Additional Mode of Key Distribution
                in Multimedia Internet KEYing (MIKEY)", RFC 4738,
                November 2006.
 [RFC4771]      Lehtovirta, V., Naslund, M., and K. Norrman,
                "Integrity Transform Carrying Roll-Over Counter for
                the Secure Real-time Transport Protocol (SRTP)",
                RFC 4771, January 2007.
 [RFC4916]      Elwell, J., "Connected Identity in the Session
                Initiation Protocol (SIP)", RFC 4916, June 2007.

Wing, et al. Informational [Page 22] RFC 5479 Media Security Requirements April 2009

 [RFC4949]      Shirey, R., "Internet Security Glossary, Version 2",
                FYI 36, RFC 4949, August 2007.
 [RFC5027]      Andreasen, F. and D. Wing, "Security Preconditions for
                Session Description Protocol (SDP) Media Streams",
                RFC 5027, October 2007.
 [RFC5197]      Fries, S. and D. Ignjatic, "On the Applicability of
                Various Multimedia Internet KEYing (MIKEY) Modes and
                Extensions", RFC 5197, June 2008.
 [RFC5246]      Dierks, T. and E. Rescorla, "The Transport Layer
                Security (TLS) Protocol Version 1.2", RFC 5246,
                August 2008.
 [SDP-CAP]      Andreasen, F., "SDP Capability Negotiation", Work
                in Progress, July 2008.
 [SDP-DH]       Baugher, M. and D. McGrew, "Diffie-Hellman Exchanges
                for Multimedia Sessions", Work in Progress,
                February 2006.
 [SIP-CERTS]    Jennings, C. and J. Fischl, "Certificate Management
                Service for The Session Initiation Protocol (SIP)",
                Work in Progress, November 2008.
 [SIP-DTLS]     Fischl, J., "Datagram Transport Layer Security (DTLS)
                Protocol for Protection of Media Traffic Established
                with the Session Initiation Protocol", Work
                in Progress, July 2007.
 [SRTP-KEY]     Wing, D., Audet, F., Fries, S., Tschofenig, H., and A.
                Johnston, "Secure Media Recording and Transcoding with
                the Session Initiation Protocol", Work in Progress,
                October 2008.
 [ZRTP]         Zimmermann, P., Johnston, A., and J. Callas, "ZRTP:
                Media Path Key Agreement for Secure RTP", Work
                in Progress, February 2009.

Wing, et al. Informational [Page 23] RFC 5479 Media Security Requirements April 2009

Appendix A. Overview and Evaluation of Existing Keying Mechanisms

 Based on how the SRTP keys are exchanged, each SRTP key exchange
 mechanism belongs to one general category:
 signaling path:
                  All the keying is carried in the call signaling (SIP
                  or SDP) path.
 media path:
              All the keying is carried in the SRTP/SRTCP media path,
              and no signaling whatsoever is carried in the call
              signaling path.
 signaling and media path:
                            Parts of the keying are carried in the
                            SRTP/SRTCP media path, and parts are
                            carried in the call signaling (SIP or SDP)
                            path.
 One of the significant benefits of SRTP over other end-to-end
 encryption mechanisms, such as for example IPsec, is that SRTP is
 bandwidth efficient and SRTP retains the header of RTP packets.
 Bandwidth efficiency is vital for VoIP in many scenarios where access
 bandwidth is limited or expensive, and retaining the RTP header is
 important for troubleshooting packet loss, delay, and jitter.
 Related to SRTP's characteristics is a goal that any SRTP keying
 mechanism to also be efficient and not cause additional call setup
 delay.  Contributors to additional call setup delay include network
 or database operations: retrieval of certificates and additional SIP
 or media path messages, and computational overhead of establishing
 keys or validating certificates.
 When examining the choice between keying in the signaling path,
 keying in the media path, or keying in both paths, it is important to
 realize the media path is generally "faster" than the SIP signaling
 path.  The SIP signaling path has computational elements involved
 that parse and route SIP messages.  The media path, on the other
 hand, does not normally have computational elements involved, and
 even when computational elements such as firewalls are involved, they
 cause very little additional delay.  Thus, the media path can be
 useful for exchanging several messages to establish SRTP keys.  A
 disadvantage of keying over the media path is that interworking
 different key exchange requires the interworking function be in the
 media path, rather than just in the signaling path; in practice, this
 involvement is probably unavoidable anyway.

Wing, et al. Informational [Page 24] RFC 5479 Media Security Requirements April 2009

A.1. Signaling Path Keying Techniques

A.1.1. MIKEY-NULL

 MIKEY-NULL [RFC3830] has the offerer indicate the SRTP keys for both
 directions.  The key is sent unencrypted in SDP, which means the SDP
 must be encrypted hop-by-hop (e.g., by using TLS (SIPS)) or end-to-
 end (e.g., by using Secure/Multipurpose Internet Mail Extensions
 (S/MIME)).
 MIKEY-NULL requires one message from offerer to answerer (half a
 round trip), and does not add additional media path messages.

A.1.2. MIKEY-PSK

 MIKEY-PSK (pre-shared key) [RFC3830] requires that all endpoints
 share one common key.  MIKEY-PSK has the offerer encrypt the SRTP
 keys for both directions using this pre-shared key.
 MIKEY-PSK requires one message from offerer to answerer (half a round
 trip), and does not add additional media path messages.

A.1.3. MIKEY-RSA

 MIKEY-RSA [RFC3830] has the offerer encrypt the keys for both
 directions using the intended answerer's public key, which is
 obtained from a mechanism outside of MIKEY.
 MIKEY-RSA requires one message from offerer to answerer (half a round
 trip), and does not add additional media path messages.  MIKEY-RSA
 requires the offerer to obtain the intended answerer's certificate.

A.1.4. MIKEY-RSA-R

 MIKEY-RSA-R [RFC4738] is essentially the same as MIKEY-RSA but
 reverses the role of the offerer and the answerer with regards to
 providing the keys.  That is, the answerer encrypts the keys for both
 directions using the offerer's public key.  Both the offerer and
 answerer validate each other's public keys using a standard X.509
 validation techniques.  MIKEY-RSA-R also enables sending certificates
 in the MIKEY message.
 MIKEY-RSA-R requires one message from offerer to answer, and one
 message from answerer to offerer (full round trip), and does not add
 additional media path messages.  MIKEY-RSA-R requires the offerer
 validate the answerer's certificate.

Wing, et al. Informational [Page 25] RFC 5479 Media Security Requirements April 2009

A.1.5. MIKEY-DHSIGN

 In MIKEY-DHSIGN [RFC3830], the offerer and answerer derive the key
 from a Diffie-Hellman (DH) exchange.  In order to prevent an active
 man-in-the-middle, the DH exchange itself is signed using each
 endpoint's private key and the associated public keys are validated
 using standard X.509 validation techniques.
 MIKEY-DHSIGN requires one message from offerer to answerer, and one
 message from answerer to offerer (full round trip), and does not add
 additional media path messages.  MIKEY-DHSIGN requires the offerer
 and answerer to validate each other's certificates.  MIKEY-DHSIGN
 also enables sending the answerer's certificate in the MIKEY message.

A.1.6. MIKEY-DHHMAC

 MIKEY-DHHMAC [RFC4650] uses a pre-shared secret to HMAC the Diffie-
 Hellman exchange, essentially combining aspects of MIKEY-PSK with
 MIKEY-DHSIGN, but without MIKEY-DHSIGN's need for certificate
 authentication.
 MIKEY-DHHMAC requires one message from offerer to answerer, and one
 message from answerer to offerer (full round trip), and does not add
 additional media path messages.

A.1.7. MIKEY-ECIES and MIKEY-ECMQV (MIKEY-ECC)

 ECC Algorithms For MIKEY [MIKEY-ECC] describes how ECC can be used
 with MIKEY-RSA (using Elliptic Curve Digital Signature Algorithm
 (ECDSA) signature) and with MIKEY-DHSIGN (using a new DH-Group code),
 and also defines two new ECC-based algorithms, Elliptic Curve
 Integrated Encryption Scheme (ECIES) and Elliptic Curve Menezes-Qu-
 Vanstone (ECMQV) .
 With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV
 function exactly like MIKEY-RSA, and the new DH-Group code function
 exactly like MIKEY-DHSIGN.  Therefore, these ECC mechanisms are not
 discussed separately in this document.

A.1.8. SDP Security Descriptions with SIPS

 SDP Security Descriptions [RFC4568] have each side indicate the key
 they will use for transmitting SRTP media, and the keys are sent in
 the clear in SDP.  SDP Security Descriptions rely on hop-by-hop (TLS
 via "SIPS:") encryption to protect the keys exchanged in signaling.

Wing, et al. Informational [Page 26] RFC 5479 Media Security Requirements April 2009

 SDP Security Descriptions requires one message from offerer to
 answerer, and one message from answerer to offerer (full round trip),
 and does not add additional media path messages.

A.1.9. SDP Security Descriptions with S/MIME

 This keying mechanism is identical to Appendix A.1.8 except that,
 rather than protecting the signaling with TLS, the entire SDP is
 encrypted with S/MIME.

A.1.10. SDP-DH (Expired)

 SDP Diffie-Hellman [SDP-DH] exchanges Diffie-Hellman messages in the
 signaling path to establish session keys.  To protect against active
 man-in-the-middle attacks, the Diffie-Hellman exchange needs to be
 protected with S/MIME, SIPS, or SIP Identity [RFC4474] and SIP
 Connected Identity [RFC4916].
 SDP-DH requires one message from offerer to answerer, and one message
 from answerer to offerer (full round trip), and does not add
 additional media path messages.

A.1.11. MIKEYv2 in SDP (Expired)

 MIKEYv2 [MIKEYv2] adds mode negotiation to MIKEYv1 and removes the
 time synchronization requirement.  It therefore now takes 2 round
 trips to complete.  In the first round trip, the communicating
 parties learn each other's identities, agree on a MIKEY mode, crypto
 algorithm, SRTP policy, and exchanges nonces for replay protection.
 In the second round trip, they negotiate unicast and/or group SRTP
 context for SRTP and/or SRTCP.
 Furthermore, MIKEYv2 also defines an in-band negotiation mode as an
 alternative to SDP (see Appendix A.3.3).

A.2. Media Path Keying Technique

A.2.1. ZRTP

 ZRTP [ZRTP] does not exchange information in the signaling path
 (although it's possible for endpoints to exchange a hash of the ZRTP
 Hello message with "a=zrtp-hash" in the initial offer if sent over an
 integrity-protected signaling channel.  This provides some useful
 correlation between the signaling and media layers).  In ZRTP, the
 keys are exchanged entirely in the media path using a Diffie-Hellman
 exchange.  The advantage to this mechanism is that the signaling
 channel is used only for call setup and the media channel is used to
 establish an encrypted channel -- much like encryption devices on the

Wing, et al. Informational [Page 27] RFC 5479 Media Security Requirements April 2009

 PSTN.  ZRTP uses voice authentication of its Diffie-Hellman exchange
 by having each person read digits or words to the other person.
 Subsequent sessions with the same ZRTP endpoint can be authenticated
 using the stored hash of the previously negotiated key rather than
 voice authentication.  ZRTP uses four media path messages (Hello,
 Commit, DHPart1, and DHPart2) to establish the SRTP key, and three
 media path confirmation messages.  These initial messages are all
 sent as non-RTP packets.
    Note: that when ZRTP probing is used, unencrypted RTP can be
    exchanged until the SRTP keys are established.

A.3. Signaling and Media Path Keying Techniques

A.3.1. EKT

 EKT [EKT] relies on another SRTP key exchange protocol, such as SDP
 Security Descriptions or MIKEY, for bootstrapping.  In the initial
 phase, each member of a conference uses an SRTP key exchange protocol
 to establish a common key encryption key (KEK).  Each member may use
 the KEK to securely transport its SRTP master key and current SRTP
 rollover counter (ROC), via RTCP, to the other participants in the
 session.
 EKT requires the offerer to send some parameters (EKT_Cipher, KEK,
 and security parameter index (SPI)) via the bootstrapping protocol
 such as SDP Security Descriptions or MIKEY.  Each answerer sends an
 SRTCP message that contains the answerer's SRTP Master Key, rollover
 counter, and the SRTP sequence number.  Rekeying is done by sending a
 new SRTCP message.  For reliable transport, multiple RTCP messages
 need to be sent.

A.3.2. DTLS-SRTP

 DTLS-SRTP [DTLS-SRTP] exchanges public key fingerprints in SDP
 [SIP-DTLS] and then establishes a DTLS session over the media
 channel.  The endpoints use the DTLS handshake to agree on crypto
 suites and establish SRTP session keys.  SRTP packets are then
 exchanged between the endpoints.
 DTLS-SRTP requires one message from offerer to answerer (half round
 trip), and one message from the answerer to offerer (full round trip)
 so the offerer can correlate the SDP answer with the answering
 endpoint.  DTLS-SRTP uses four media path messages to establish the
 SRTP key.

Wing, et al. Informational [Page 28] RFC 5479 Media Security Requirements April 2009

 This document assumes DTLS will use TLS_RSA_WITH_AES_128_CBC_SHA as
 its cipher suite, which is the mandatory-to-implement cipher suite in
 TLS [RFC5246].

A.3.3. MIKEYv2 Inband (Expired)

 As defined in Appendix A.1.11, MIKEYv2 also defines an in-band
 negotiation mode as an alternative to SDP (see Appendix A.3.3).  The
 details are not sorted out in the document yet on what in-band
 actually means (i.e., UDP, RTP, RTCP, etc.).

A.4. Evaluation Criteria - SIP

 This section considers how each keying mechanism interacts with SIP
 features.

A.4.1. Secure Retargeting and Secure Forking

 Retargeting and forking of signaling requests is described within
 Section 4.2.  The following builds upon this description.
 The following list compares the behavior of secure forking, answering
 association, two-time pads, and secure retargeting for each keying
 mechanism.
    MIKEY-NULL
       Secure Forking: No, all AORs see offerer's and answerer's keys.
       Answer is associated with media by the SSRC in MIKEY.
       Additionally, a two-time pad occurs if two branches choose the
       same 32-bit SSRC and transmit SRTP packets.
       Secure Retargeting: No, all targets see offerer's and
       answerer's keys.  Suffers from retargeting identity problem.
    MIKEY-PSK
       Secure Forking: No, all AORs see offerer's and answerer's keys.
       Answer is associated with media by the SSRC in MIKEY.  Note
       that all AORs must share the same pre-shared key in order for
       forking to work at all with MIKEY-PSK.  Additionally, a two-
       time pad occurs if two branches choose the same 32-bit SSRC and
       transmit SRTP packets.
       Secure Retargeting: Not secure.  For retargeting to work, the
       final target must possess the correct PSK.  As this is likely
       in scenarios where the call is targeted to another device
       belonging to the same user (forking), it is very unlikely that
       other users will possess that PSK and be able to successfully
       answer that call.

Wing, et al. Informational [Page 29] RFC 5479 Media Security Requirements April 2009

    MIKEY-RSA
       Secure Forking: No, all AORs see offerer's and answerer's keys.
       Answer is associated with media by the SSRC in MIKEY.  Note
       that all AORs must share the same private key in order for
       forking to work at all with MIKEY-RSA.  Additionally, a two-
       time pad occurs if two branches choose the same 32-bit SSRC and
       transmit SRTP packets.
       Secure Retargeting: No.
    MIKEY-RSA-R
       Secure Forking: Yes, answer is associated with media by the
       SSRC in MIKEY.
       Secure Retargeting: Yes.
    MIKEY-DHSIGN
       Secure Forking: Yes, each forked endpoint negotiates unique
       keys with the offerer for both directions.  Answer is
       associated with media by the SSRC in MIKEY.
       Secure Retargeting: Yes, each target negotiates unique keys
       with the offerer for both directions.
    MIKEYv2 in SDP
       The behavior will depend on which mode is picked.
    MIKEY-DHHMAC
       Secure Forking: Yes, each forked endpoint negotiates unique
       keys with the offerer for both directions.  Answer is
       associated with media by the SSRC in MIKEY.
       Secure Retargeting: Yes, each target negotiates unique keys
       with the offerer for both directions.  Note that for the keys
       to be meaningful, it would require the PSK to be the same for
       all the potential intermediaries, which would only happen
       within a single domain.
    SDP Security Descriptions with SIPS
       Secure Forking: No, each forked endpoint sees the offerer's
       key.  Answer is not associated with media.
       Secure Retargeting: No, each target sees the offerer's key.
    SDP Security Descriptions with S/MIME
       Secure Forking: No, each forked endpoint sees the offerer's
       key.  Answer is not associated with media.

Wing, et al. Informational [Page 30] RFC 5479 Media Security Requirements April 2009

       Secure Retargeting: No, each target sees the offerer's key.
       Suffers from retargeting identity problem.
    SDP-DH
       Secure Forking: Yes, each forked endpoint calculates a unique
       SRTP key.  Answer is not associated with media.
       Secure Retargeting: Yes, the final target calculates a unique
       SRTP key.
    ZRTP
       Secure Forking: Yes, each forked endpoint calculates a unique
       SRTP key.  With the "a=zrtp-hash" attribute, the media can be
       associated with an answer.
       Secure Retargeting: Yes, the final target calculates a unique
       SRTP key.
    EKT
       Secure Forking: Inherited from the bootstrapping mechanism (the
       specific MIKEY mode or SDP Security Descriptions).  Answer is
       associated with media by the SPI in the EKT protocol.  Answer
       is associated with media by the SPI in the EKT protocol.
       Secure Retargeting: Inherited from the bootstrapping mechanism
       (the specific MIKEY mode or SDP Security Descriptions).
    DTLS-SRTP
       Secure Forking: Yes, each forked endpoint calculates a unique
       SRTP key.  Answer is associated with media by the certificate
       fingerprint in signaling and certificate in the media path.
       Secure Retargeting: Yes, the final target calculates a unique
       SRTP key.
    MIKEYv2 Inband
       The behavior will depend on which mode is picked.

A.4.2. Clipping Media before SDP Answer

 Clipping media before receiving the signaling answer is described
 within Section 4.1.  The following builds upon this description.
 Furthermore, the problem of clipping gets compounded when forking is
 used.  For example, if using a Diffie-Hellman keying technique with
 security preconditions that forks to 20 endpoints, the call initiator
 would get 20 provisional responses containing 20 signed Diffie-
 Hellman half keys.  Calculating 20 DH secrets and validating

Wing, et al. Informational [Page 31] RFC 5479 Media Security Requirements April 2009

 signatures can be a difficult task depending on the device
 capabilities.
 The following list compares the behavior of clipping before SDP
 answer for each keying mechanism.
    MIKEY-NULL
       Not clipped.  The offerer provides the answerer's keys.
    MIKEY-PSK
       Not clipped.  The offerer provides the answerer's keys.
    MIKEY-RSA
       Not clipped.  The offerer provides the answerer's keys.
    MIKEY-RSA-R
       Clipped.  The answer contains the answerer's encryption key.
    MIKEY-DHSIGN
       Clipped.  The answer contains the answerer's Diffie-Hellman
       response.
    MIKEY-DHHMAC
       Clipped.  The answer contains the answerer's Diffie-Hellman
       response.
    MIKEYv2 in SDP
       The behavior will depend on which mode is picked.
    SDP Security Descriptions with SIPS
       Clipped.  The answer contains the answerer's encryption key.
    SDP Security Descriptions with S/MIME
       Clipped.  The answer contains the answerer's encryption key.
    SDP-DH
       Clipped.  The answer contains the answerer's Diffie-Hellman
       response.
    ZRTP
       Not clipped because the session initially uses RTP.  While RTP
       is flowing, both ends negotiate SRTP keys in the media path and
       then switch to using SRTP.

Wing, et al. Informational [Page 32] RFC 5479 Media Security Requirements April 2009

    EKT
       Not clipped, as long as the first RTCP packet (containing the
       answerer's key) is not lost in transit.  The answerer sends its
       encryption key in RTCP, which arrives at the same time (or
       before) the first SRTP packet encrypted with that key.
          Note: RTCP needs to work, in the answerer-to-offerer
          direction, before the offerer can decrypt SRTP media.
    DTLS-SRTP
       No clipping after the DTLS-SRTP handshake has completed.  SRTP
       keys are exchanged in the media path.  Need to wait for SDP
       answer to ensure DTLS-SRTP handshake was done with an
       authorized party.
          If a middlebox interferes with the media path, there can be
          clipping [MIDDLEBOX].
    MIKEYv2 Inband
       Not clipped.  Keys are exchanged in the media path without
       relying on the signaling path.

A.4.3. SSRC and ROC

 In SRTP, a cryptographic context is defined as the SSRC, destination
 network address, and destination transport port number.  Whereas RTP,
 a flow is defined as the destination network address and destination
 transport port number.  This results in a problem -- how to
 communicate the SSRC so that the SSRC can be used for the
 cryptographic context.
 Two approaches have emerged for this communication.  One, used by all
 MIKEY modes, is to communicate the SSRCs to the peer in the MIKEY
 exchange.  Another, used by SDP Security Descriptions, is to apply
 "late binding" -- that is, any new packet containing a previously
 unseen SSRC (which arrives at the same destination network address
 and destination transport port number) will create a new
 cryptographic context.  Another approach, common amongst techniques
 with media-path SRTP key establishment, is to require a handshake
 over that media path before SRTP packets are sent.  MIKEY's approach
 changes RTP's SSRC collision detection behavior by requiring RTP to
 pre-establish the SSRC values for each session.
 Another related issue is that SRTP introduces a rollover counter
 (ROC), which records how many times the SRTP sequence number has
 rolled over.  As the sequence number is used for SRTP's default
 ciphers, it is important that all endpoints know the value of the
 ROC.  The ROC starts at 0 at the beginning of a session.

Wing, et al. Informational [Page 33] RFC 5479 Media Security Requirements April 2009

 Some keying mechanisms cause a two-time pad to occur if two endpoints
 of a forked call have an SSRC collision.
 Note: A proposal has been made to send the ROC value on every Nth
 SRTP packet[RFC4771].  This proposal has not yet been incorporated
 into this document.
 The following list examines handling of SSRC and ROC:
    MIKEY-NULL
       Each endpoint indicates a set of SSRCs and the ROC for SRTP
       packets it transmits.
    MIKEY-PSK
       Each endpoint indicates a set of SSRCs and the ROC for SRTP
       packets it transmits.
    MIKEY-RSA
       Each endpoint indicates a set of SSRCs and the ROC for SRTP
       packets it transmits.
    MIKEY-RSA-R
       Each endpoint indicates a set of SSRCs and the ROC for SRTP
       packets it transmits.
    MIKEY-DHSIGN
       Each endpoint indicates a set of SSRCs and the ROC for SRTP
       packets it transmits.
    MIKEY-DHHMAC
       Each endpoint indicates a set of SSRCs and the ROC for SRTP
       packets it transmits.
    MIKEYv2 in SDP
       Each endpoint indicates a set of SSRCs and the ROC for SRTP
       packets it transmits.
    SDP Security Descriptions with SIPS
       Neither SSRC nor ROC are signaled.  SSRC "late binding" is
       used.
    SDP Security Descriptions with S/MIME
       Neither SSRC nor ROC are signaled.  SSRC "late binding" is
       used.
    SDP-DH
       Neither SSRC nor ROC are signaled.  SSRC "late binding" is
       used.

Wing, et al. Informational [Page 34] RFC 5479 Media Security Requirements April 2009

    ZRTP
       Neither SSRC nor ROC are signaled.  SSRC "late binding" is
       used.
    EKT
       The SSRC of the SRTCP packet containing an EKT update
       corresponds to the SRTP master key and other parameters within
       that packet.
    DTLS-SRTP
       Neither SSRC nor ROC are signaled.  SSRC "late binding" is
       used.
    MIKEYv2 Inband
       Each endpoint indicates a set of SSRCs and the ROC for SRTP
       packets it transmits.

A.5. Evaluation Criteria - Security

 This section evaluates each keying mechanism on the basis of their
 security properties.

A.5.1. Distribution and Validation of Persistent Public Keys and

      Certificates
 Using persistent public keys for confidentiality and authentication
 can introduce requirements for two types of systems, often
 implemented using certificates: (1) a system to distribute those
 persistent public keys certificates, and (2) a system for validating
 those persistent public keys.  We refer to the former as a key
 distribution system and the latter as an authentication
 infrastructure.  In many cases, a monolithic public key
 infrastructure (PKI) is used to fulfill both of these roles.
 However, these functions can be provided by many other systems.  For
 instance, key distribution may be accomplished by any public
 repository of keys.  Any system in which the two endpoints have
 access to trust anchors and intermediate CA certificates that can be
 used to validate other endpoints' certificates (including a system of
 self-signed certificates) can be used to support certificate
 validation in the below schemes.
 With real-time communications, it is desirable to avoid fetching or
 validating certificates that delay call setup.  Rather, it is
 preferable to fetch or validate certificates in such a way that call
 setup is not delayed.  For example, a certificate can be validated
 while the phone is ringing or can be validated while ring-back tones
 are being played or even while the called party is answering the

Wing, et al. Informational [Page 35] RFC 5479 Media Security Requirements April 2009

 phone and saying "hello".  Even better is to avoid fetching or
 validating persistent public keys at all.
 SRTP key exchange mechanisms that require a particular authentication
 infrastructure to operate (whether for distribution or validation)
 are gated on the deployment of a such an infrastructure available to
 both endpoints.  This means that no media security is achievable
 until such an infrastructure exists.  For SIP, something like sip-
 certs [SIP-CERTS] might be used to obtain the certificate of a peer.
    Note: Even if sip-certs [SIP-CERTS] were deployed, the retargeting
    problem (Appendix A.4.1) would still prevent successful deployment
    of keying techniques which require the offerer to obtain the
    actual target's public key.
 The following list compares the requirements introduced by the use of
 public-key cryptography in each keying mechanism, both for public key
 distribution and for certificate validation.
    MIKEY-NULL
       Public-key cryptography is not used.
    MIKEY-PSK
       Public-key cryptography is not used.  Rather, all endpoints
       must have some way to exchange per-endpoint or per-system
       pre-shared keys.
    MIKEY-RSA
       The offerer obtains the intended answerer's public key before
       initiating the call.  This public key is used to encrypt the
       SRTP keys.  There is no defined mechanism for the offerer to
       obtain the answerer's public key, although [SIP-CERTS] might be
       viable in the future.
       The offer may also contain a certificate for the offerer, which
       would require an authentication infrastructure in order to be
       validated by the receiver.
    MIKEY-RSA-R
       The offer contains the offerer's certificate, and the answer
       contains the answerer's certificate.  The answerer uses the
       public key in the certificate to encrypt the SRTP keys that
       will be used by the offerer and the answerer.  An
       authentication infrastructure is necessary to validate the
       certificates.

Wing, et al. Informational [Page 36] RFC 5479 Media Security Requirements April 2009

    MIKEY-DHSIGN
       An authentication infrastructure is used to authenticate the
       public key that is included in the MIKEY message.
    MIKEY-DHHMAC
       Public-key cryptography is not used.  Rather, all endpoints
       must have some way to exchange per-endpoint or per-system
       pre-shared keys.
    MIKEYv2 in SDP
       The behavior will depend on which mode is picked.
    SDP Security Descriptions with SIPS
       Public-key cryptography is not used.
    SDP Security Descriptions with S/MIME
       Use of S/MIME requires that the endpoints be able to fetch and
       validate certificates for each other.  The offerer must obtain
       the intended target's certificate and encrypts the SDP offer
       with the public key contained in target's certificate.  The
       answerer must obtain the offerer's certificate and encrypt the
       SDP answer with the public key contained in the offerer's
       certificate.
    SDP-DH
       Public-key cryptography is not used.
    ZRTP
       Public-key cryptography is used (Diffie-Hellman), but without
       dependence on persistent public keys.  Thus, certificates are
       not fetched or validated.
    EKT
       Public-key cryptography is not used by itself, but might be
       used by the EKT bootstrapping keying mechanism (such as certain
       MIKEY modes).
    DTLS-SRTP
       Remote party's certificate is sent in media path, and a
       fingerprint of the same certificate is sent in the signaling
       path.
    MIKEYv2 Inband
       The behavior will depend on which mode is picked.

Wing, et al. Informational [Page 37] RFC 5479 Media Security Requirements April 2009

A.5.2. Perfect Forward Secrecy

 In the context of SRTP, Perfect Forward Secrecy is the property that
 SRTP session keys that protected a previous session are not
 compromised if the static keys belonging to the endpoints are
 compromised.  That is, if someone were to record your encrypted
 session content and later acquires either party's private key, that
 encrypted session content would be safe from decryption if your key
 exchange mechanism had perfect forward secrecy.
 The following list describes how each key exchange mechanism provides
 PFS.
    MIKEY-NULL
       Not applicable; MIKEY-NULL does not have a long-term secret.
    MIKEY-PSK
       No PFS.
    MIKEY-RSA
       No PFS.
    MIKEY-RSA-R
       No PFS.
    MIKEY-DHSIGN
       PFS is provided with the Diffie-Hellman exchange.
    MIKEY-DHHMAC
       PFS is provided with the Diffie-Hellman exchange.
    MIKEYv2 in SDP
       The behavior will depend on which mode is picked.
    SDP Security Descriptions with SIPS
       Not applicable; SDP Security Descriptions does not have a long-
       term secret.
    SDP Security Descriptions with S/MIME
       Not applicable; SDP Security Descriptions does not have a long-
       term secret.
    SDP-DH
       PFS is provided with the Diffie-Hellman exchange.
    ZRTP
       PFS is provided with the Diffie-Hellman exchange.

Wing, et al. Informational [Page 38] RFC 5479 Media Security Requirements April 2009

    EKT
       No PFS.
    DTLS-SRTP
       PFS is provided if the negotiated cipher suite uses ephemeral
       keys (e.g., Diffie-Hellman (DHE_RSA [RFC5246]) or Elliptic
       Curve Diffie-Hellman [RFC4492]).
    MIKEYv2 Inband
       The behavior will depend on which mode is picked.

A.5.3. Best Effort Encryption

 With best effort encryption, SRTP is used with endpoints that support
 SRTP, otherwise RTP is used.
 SIP needs a backwards-compatible best effort encryption in order for
 SRTP to work successfully with SIP retargeting and forking when there
 is a mix of forked or retargeted devices that support SRTP and don't
 support SRTP.
    Consider the case of Bob, with a phone that only does RTP and a
    voice mail system that supports SRTP and RTP.  If Alice calls Bob
    with an SRTP offer, Bob's RTP-only phone will reject the media
    stream (with an empty "m=" line) because Bob's phone doesn't
    understand SRTP (RTP/SAVP).  Alice's phone will see this rejected
    media stream and may terminate the entire call (BYE) and
    re-initiate the call as RTP-only, or Alice's phone may decide to
    continue with call setup with the SRTP-capable leg (the voice mail
    system).  If Alice's phone decided to re-initiate the call as RTP-
    only, and Bob doesn't answer his phone, Alice will then leave
    voice mail using only RTP, rather than SRTP as expected.
 Currently, several techniques are commonly considered as candidates
 to provide opportunistic encryption:
 multipart/alternative
    [MULTIPART] describes how to form a multipart/alternative body
    part in SIP.  The significant issues with this technique are (1)
    that multipart MIME is incompatible with existing SIP proxies,
    firewalls, Session Border Controllers, and endpoints and (2) when
    forking, the Heterogeneous Error Response Forking Problem (HERFP)
    [RFC3326] causes problems if such non-multipart-capable endpoints
    were involved in the forking.

Wing, et al. Informational [Page 39] RFC 5479 Media Security Requirements April 2009

 session attribute
    With this technique, the endpoints signal their desire to do SRTP
    by signaling RTP (RTP/AVP), and using an attribute ("a=") in the
    SDP.  This technique is entirely backwards compatible with
    non-SRT-aware endpoints, but doesn't use the RTP/SAVP protocol
    registered by SRTP [RFC3711].
 SDP Capability Negotiation
    SDP Capability Negotiation [SDP-CAP] provides a backwards-
    compatible mechanism to allow offering both SRTP and RTP in a
    single offer.  This is the preferred technique.
 Probing
    With this technique, the endpoints first establish an RTP session
    using RTP (RTP/AVP).  The endpoints send probe messages, over the
    media path, to determine if the remote endpoint supports their
    keying technique.  A disadvantage of probing is an active attacker
    can interfere with probes, and until probing completes (and SRTP
    is established) the media is in the clear.
 The preferred technique, SDP Capability Negotiation [SDP-CAP], can be
 used with all key exchange mechanisms.  What remains unique is ZRTP,
 which can also accomplish its best effort encryption by probing
 (sending ZRTP messages over the media path) or by session attribute
 (see "a=zrtp-hash" in [ZRTP]).  Current implementations of ZRTP use
 probing.

A.5.4. Upgrading Algorithms

 It is necessary to allow upgrading SRTP encryption and hash
 algorithms, as well as upgrading the cryptographic functions used for
 the key exchange mechanism.  With SIP's offer/answer model, this can
 be computationally expensive because the offer needs to contain all
 combinations of the key exchange mechanisms (all MIKEY modes, SDP
 Security Descriptions), all SRTP cryptographic suites (AES-128,
 AES-256) and all SRTP cryptographic hash functions (SHA-1, SHA-256)
 that the offerer supports.  In order to do this, the offerer has to
 expend CPU resources to build an offer containing all of this
 information that becomes computationally prohibitive.
 Thus, it is important to keep the offerer's CPU impact fixed so that
 offering multiple new SRTP encryption and hash functions incurs no
 additional expense.

Wing, et al. Informational [Page 40] RFC 5479 Media Security Requirements April 2009

 The following list describes the CPU effort involved in using each
 key exchange technique.
    MIKEY-NULL
       No significant computational expense.
    MIKEY-PSK
       No significant computational expense.
    MIKEY-RSA
       For each offered SRTP crypto suite, the offerer has to perform
       RSA operation to encrypt the TGK (TEK Generation Key).
    MIKEY-RSA-R
       For each offered SRTP crypto suite, the offerer has to perform
       public key operation to sign the MIKEY message.
    MIKEY-DHSIGN
       For each offered SRTP crypto suite, the offerer has to perform
       Diffie-Hellman operation, and a public key operation to sign
       the Diffie-Hellman output.
    MIKEY-DHHMAC
       For each offered SRTP crypto suite, the offerer has to perform
       Diffie-Hellman operation.
    MIKEYv2 in SDP
       The behavior will depend on which mode is picked.
    SDP Security Descriptions with SIPS
       No significant computational expense.
    SDP Security Descriptions with S/MIME
       S/MIME requires the offerer and the answerer to encrypt the SDP
       with the other's public key, and to decrypt the received SDP
       with their own private key.
    SDP-DH
       For each offered SRTP crypto suite, the offerer has to perform
       a Diffie-Hellman operation.
    ZRTP
       The offerer has no additional computational expense at all, as
       the offer contains no information about ZRTP or might contain
       "a=zrtp-hash".

Wing, et al. Informational [Page 41] RFC 5479 Media Security Requirements April 2009

    EKT
       The offerer's computational expense depends entirely on the EKT
       bootstrapping mechanism selected (one or more MIKEY modes or
       SDP Security Descriptions).
    DTLS-SRTP
       The offerer has no additional computational expense at all, as
       the offer contains only a fingerprint of the certificate that
       will be presented in the DTLS exchange.
    MIKEYv2 Inband
       The behavior will depend on which mode is picked.

Appendix B. Out-of-Scope

 The compromise of an endpoint that has access to decrypted media
 (e.g., SIP user agent, transcoder, recorder) is out of scope of this
 document.  Such a compromise might be via privilege escalation,
 installation of a virus or trojan horse, or similar attacks.

B.1. Shared Key Conferencing

 The consensus on the RTPSEC mailing list was to concentrate on
 unicast, point-to-point sessions.  Thus, there are no requirements
 related to shared key conferencing.  This section is retained for
 informational purposes.
 For efficient scaling, large audio and video conference bridges
 operate most efficiently by encrypting the current speaker once and
 distributing that stream to the conference attendees.  Typically,
 inactive participants receive the same streams -- they hear (or see)
 the active speaker(s), and the active speakers receive distinct
 streams that don't include themselves.  In order to maintain the
 confidentiality of such conferences where listeners share a common
 key, all listeners must rekeyed when a listener joins or leaves a
 conference.

Wing, et al. Informational [Page 42] RFC 5479 Media Security Requirements April 2009

 An important use case for mixers/translators is a conference bridge:
                                       +----+
                           A --- 1 --->|    |
                             <-- 2 ----| M  |
                                       | I  |
                           B --- 3 --->| X  |
                             <-- 4 ----| E  |
                                       | R  |
                           C --- 5 --->|    |
                             <-- 6 ----|    |
                                       +----+
                     Figure 3: Centralized Keying
 In the figure above, 1, 3, and 5 are RTP media contributions from
 Alice, Bob, and Carol, and 2, 4, and 6 are the RTP flows to those
 devices carrying the "mixed" media.
 Several scenarios are possible:
 a.  Multiple inbound sessions: 1, 3, and 5 are distinct RTP sessions,
 b.  Multiple outbound sessions: 2, 4, and 6 are distinct RTP
     sessions,
 c.  Single inbound session: 1, 3, and 5 are just different sources
     within the same RTP session,
 d.  Single outbound session: 2, 4, and 6 are different flows of the
     same (multi-unicast) RTP session.
 If there are multiple inbound sessions and multiple outbound sessions
 (scenarios a and b), then every keying mechanism behaves as if the
 mixer were an endpoint and can set up a point-to-point secure session
 between the participant and the mixer.  This is the simplest
 situation, but is computationally wasteful, since SRTP processing has
 to be done independently for each participant.  The use of multiple
 inbound sessions (scenario a) doesn't waste computational resources,
 though it does consume additional cryptographic context on the mixer
 for each participant and has the advantage of data origin
 authentication.
 To support a single outbound session (scenario d), the mixer has to
 dictate its encryption key to the participants.  Some keying
 mechanisms allow the transmitter to determine its own key, and others
 allow the offerer to determine the key for the offerer and answerer.
 Depending on how the call is established, the offerer might be a

Wing, et al. Informational [Page 43] RFC 5479 Media Security Requirements April 2009

 participant (such as a participant dialing into a conference bridge)
 or the offerer might be the mixer (such as a conference bridge
 calling a participant).  The use of offerless INVITEs may help some
 keying mechanisms reverse the role of offerer/answerer.  A
 difficulty, however, is knowing a priori if the role should be
 reversed for a particular call.  The significant advantage of a
 single outbound session is the number of SRTP encryption operations
 remains constant even as the number of participants increases.
 However, a disadvantage is that data origin authentication is lost,
 allowing any participant to spoof the sender (because all
 participants know the sender's SRTP key).

Wing, et al. Informational [Page 44] RFC 5479 Media Security Requirements April 2009

Authors' Addresses

 Dan Wing (editor)
 Cisco Systems, Inc.
 170 West Tasman Drive
 San Jose, CA  95134
 USA
 EMail: dwing@cisco.com
 Steffen Fries
 Siemens AG
 Otto-Hahn-Ring 6
 Munich, Bavaria  81739
 Germany
 EMail: steffen.fries@siemens.com
 Hannes Tschofenig
 Nokia Siemens Networks
 Linnoitustie 6
 Espoo,   02600
 Finland
 Phone: +358 (50) 4871445
 EMail: Hannes.Tschofenig@nsn.com
 URI:   http://www.tschofenig.priv.at
 Francois Audet
 Nortel
 4655 Great America Parkway
 Santa Clara, CA  95054
 USA
 EMail: audet@nortel.com

Wing, et al. Informational [Page 45]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5479.txt · Last modified: 2009/04/03 22:48 (external edit)