INTERNET-DRAFT L. McCarthy draft-mccarthy-smug-rtp-profile-src-auth-00.txt UMass-Amherst Expires November 1999 May 1999 RTP Profile for Source Authentication and Non-Repudiation of Audio and Video Conferences Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. ABSTRACT This document describes a mechanism for authentication of the source of a stream of Real-Time Transport Protocol (RTP) packets. The mechanism provides sender-specific authentication, non-repudiation, and replay protection services for both unicast and multicast RTP streams. This mechanism is based upon the stream signing scheme of Wong and Lam [WL]. These authentication services extend the RTP profile for audio and video conferences with minimal control [Schulzrinne96, Schulzrinne99]. Authentication covers all RTP payload types, and may be applied in conjunction with the RTP confidentiality service. Key management and negotiation of the authentication mechanism parameters are not addressed in this document. McCarthy [Page 1] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Profile-Specific Packet Formats and Processing. . . . . . . . . . 3 2.1 RTP Data Header Additions. . . . . . . . . . . . . . . . . . 3 2.2 RTP Data Header Extensions . . . . . . . . . . . . . . . . . 4 2.3 RTCP Packet Types. . . . . . . . . . . . . . . . . . . . . . 4 2.4 SR/RR Extension. . . . . . . . . . . . . . . . . . . . . . . 4 2.5 Security Services. . . . . . . . . . . . . . . . . . . . . . 4 2.6 String-to-key Mapping. . . . . . . . . . . . . . . . . . . . 4 2.7 Underlying Protocol. . . . . . . . . . . . . . . . . . . . . 4 2.8 Other Formats and Processing . . . . . . . . . . . . . . . . 5 3. Format of RTP Data Header Additions . . . . . . . . . . . . . . . 5 3.1 Packet Length. . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Hash Tree Degree ("HT Deg"). . . . . . . . . . . . . . . . . 5 3.3 Signature Input Length ("SI Len"). . . . . . . . . . . . . . 6 3.3.1 Blocks with Multiple Hash Tree Roots . . . . . . . . . 6 3.4 Block Size . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5 Block Index. . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6 Security Parameters Index (SPI). . . . . . . . . . . . . . . 6 3.7 Sequence Number. . . . . . . . . . . . . . . . . . . . . . . 6 3.8 Block Hashes . . . . . . . . . . . . . . . . . . . . . . . . 7 3.9 Block Signature. . . . . . . . . . . . . . . . . . . . . . . 7 4. Processing of RTP Data Header Additions . . . . . . . . . . . . . 7 4.1 Authentication Algorithms. . . . . . . . . . . . . . . . . . 7 4.1.1 Public-Key Signature Schemes . . . . . . . . . . . . . 8 4.1.2 Hash Functions . . . . . . . . . . . . . . . . . . . . 8 4.2 Outbound Packet Processing . . . . . . . . . . . . . . . . . 8 4.2.1 (Group) Security Association Lookup. . . . . . . . . . 8 4.2.2 Blocks of Packets. . . . . . . . . . . . . . . . . . . 8 4.2.3 Packet Length. . . . . . . . . . . . . . . . . . . . . 9 4.2.4 Hash Tree Deg, Signature Input Len, and Block Size . . 9 4.2.5 Block Index. . . . . . . . . . . . . . . . . . . . . . 9 4.2.6 Sequence Number Generation . . . . . . . . . . . . . .10 4.2.7 Hash Tree Construction . . . . . . . . . . . . . . . .10 4.2.7.1 Packet Hash Computation. . . . . . . . . . . . .10 4.2.7.2 Non-Leaf Nodes . . . . . . . . . . . . . . . . .11 4.2.8 Block Hashes . . . . . . . . . . . . . . . . . . . . .11 4.2.9 Block Signature. . . . . . . . . . . . . . . . . . . .12 4.2.9.1 Direct Signing of Hash Root(s) . . . . . . . . .12 4.2.9.2 Probabilistic Omission of Block Signatures . . .12 4.3 Inbound Packet Processing. . . . . . . . . . . . . . . . . .12 4.3.1 (Group) Security Association Lookup. . . . . . . . . .12 4.3.2 Sequence Number Verification . . . . . . . . . . . . .13 4.3.3 Validation of Fixed Header Additions . . . . . . . . .13 4.3.3.1 Packet Length Validation . . . . . . . . . . . .14 4.3.3.2 Hash Tree Parameter Validation . . . . . . . . .14 4.3.3.3 Block Index Validation . . . . . . . . . . . . .14 4.3.4 Block Signature Verification . . . . . . . . . . . . .15 5. Security Considerations . . . . . . . . . . . . . . . . . . . . .15 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .16 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . . .16 8. Author Contact Information. . . . . . . . . . . . . . . . . . . .17 McCarthy [Page 2] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 1. Introduction The Real-Time Transport Protocol (RTP) [SCFJ96, SCFJ99] provides data transport services for real-time data streams such as audio and video transmissions. RTP already features a confidentiality service but does not offer any means of authenticating the source of an RTP stream. This document describes a profile for RTP conferencing applications that require sender-specific authentication, non- repudiation, and replay protection services for unicast or multicast RTP streams. This profile extends the RTP profile for audio and video conferences with minimal control [Schulzrinne96, Schulzrinne99]. Authentication covers all RTP payload types, and may be applied in conjunction with the RTP confidentiality service. For real-time multicast streams of data, ordinary secret-key or public-key source authentication techniques may not be efficient enough for practical applications. Naive use of symmetrically-keyed message authentication codes (MACs), with one MAC per packet per receiver, scales poorly for large multicast receiver groups. Existing public-key (asymmetric) signature schemes are deemed too slow for per-packet signing of real-time traffic. The authentication mechanism specified by this profile is based upon the Wong and Lam tree chaining scheme for stream signing [WL]. The WL scheme is designed to run at sufficient speed for real-time applications, add a bearable level of packet overhead from authentication data, and tolerate packet loss gracefully. Non-repudiation of the sender is assured even against attacks by arbitrary coalitions of members in an RTP multicast conference. This profile employs several optimizations of the pure WL scheme, most notably in Sections 3.3.1 and 4.2.9.2. For future study: Should we define source authentication services for RTCP packets? 2. Profile-Specific Packet Formats and Processing This section addresses the possibilities for profile-specific packet formats and processing suggested in Section 12 of [SCFJ99]. For the most part this profile defaults to the formats and processing specified in [Schulzrinne96, Schulzrinne99]. 2.1 RTP Data Header Additions Several additional fields are appended to the fixed RTP header. Section 3 describes the format of these fields and Section 4 describes the processing of these fields. McCarthy [Page 3] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 2.2 RTP Data Header Extensions No specific RTP data header extensions are defined. Applications following this profile may use header extensions, as specified in Section 2 of [Schulzrinne96, Schulzrinne99]. Authentication coverage of an RTP data header extension, if present, is discussed in Section 4.2.8. For future work: Should we define an RTP header extension for experimentation with this source authentication service? (i.e. as a provisional alternative to making profile-specific modifications to the RTP header) 2.3 RTCP Packet Types Additional RTCP packet types are as specified in Section 2 of [Schulzrinne96, Schulzrinne99]. (At this writing, no new RTCP packet types are defined in those documents.) For future study: Should we add verification success/failure indication packet type(s) to RTCP? See discussion in Section 4.2.8. 2.4 SR/RR Extension SR and RR packet extensions are as specified in Section 2 of [Schulzrinne96, Schulzrinne99]. (At this writing, no SR or RR extensions are defined in those documents.) For future study: Should we add verification success/failure indications to sender and receiver reports? See discussion in Section 4.2.8. 2.5 Security Services This document describes an authentication service for RTP applications. The native RTP confidentiality service may be used in conjunction with this authentication service. 2.6 String-to-key Mapping No mapping from a passphrase string to a cryptographic key is specified herein. 2.7 Underlying Protocol This authentication service is intended for use where RTP is transported over unicast or multicast UDP. The authentication service may be used over a reliable data transport protocol such as TCP. However, different source authentication mechanisms would be better suited for use over a reliable transport protocol (see [CP]). McCarthy [Page 4] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 2.8 Other Formats and Processing All of the following are as specified in [Schulzrinne96, Schulzrinne99]: o marker bit and payload type field in the RTP data header o payload types o RTCP report interval calculation o use of SDES items o mapping from RTP/RTCP to transport-layer addresses o encapsulation of multiple RTP packets in a single lower layer packet 3. Format of RTP Data Header Additions As recommended in Section 5.3 of [SCFJ96, SCFJ99], the profile- specific fixed fields are located immediately after the SSRC field of the base RTP fixed header. The diagram below depicts the layout of the RTP data header additions for source authentication. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Length |HT Deg |SI Len | Block Size | Block Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Block Hashes (variable length) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Block Signature (variable length) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1 Packet Length This 8-bit field specifies the length, in 32-bit words, of the RTP packet. 3.2 Hash Tree Degree ("HT Deg") This 4-bit field specifies the degree of the hash trees used to authenticate this block of packets. The degree of a hash tree is the number of children belonging to each non-leaf node of the tree. McCarthy [Page 5] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 3.3 Signature Input Length ("SI Len") This 4-bit field specifies the number of hash tree roots covered by the Block Signature. 3.3.1 Blocks with Multiple Hash Tree Roots In the scheme described in [WL], a single public-key signature always covers a single hash tree root. However optimizations are possible in some circumstances. When the maximum message input size of the chosen public-key signature algorithm is at least twice the digest size of the chosen hash function, the signature can be computed over multiple concatenated hash tree roots. For example, this optimization is possible when the chosen public-key signature scheme (Section 4.1.1) is RSA (using a 1024-bit modulus) and the chosen hash function is SHA-1. Note this implies direct application of the public-key signing operation to the input message -- the concatenated hash tree root values -- instead of the common application of the signing operation to a hash of the input message. 3.4 Block Size This 8-bit field specifies the number of packets in this block. 3.5 Block Index This 8-bit field specifies the index of this packet in this block. 3.6 Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (RTP-src-auth), uniquely identifies the Security Association for this datagram. When the RTP packet is destined for a multicast group address, the SPI -- together with the source IP address and security protocol -- uniquely identifies a Group Security Association (GSA) [MH] rather than a SA. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) is reserved for local, implementation- specific use. The SA (or GSA) includes the version number of the RTP source authentication mechanism. This document specifies version "0" of the RTP-src-auth profile. McCarthy [Page 6] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 3.7 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if a receiver does not elect to enable the anti- replay service for a specific SA or GSA. Processing of the Sequence Number field is at the discretion of the receivers, i.e., the sender always transmits this field, but the receiver(s) need not act upon it (see the discussion of Sequence Number Verification in Section 4.3.2). The sender's counter and the receiver's counter are initialized to "0" when an SA or GSA is established. (The first packet sent using a given SA or GSA will have a Sequence Number of 1; see Section 4.2.6 for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number is never allowed to cycle. Thus, the sender's counter and the receiver's counter are reset (by establishing a new SA or GSA and thus a new key) prior to the transmission of the 2^32nd packet on an SA or GSA. Note that the value of this field is independent of the value of the 16-bit Sequence Number field in the base RTP fixed header [SCFJ96, SCFJ99]. 3.8 Block Hashes This variable-length field contains zero or more hash tree node values. Together with the packet hash, these hash values are used to verify the Block Signature. The length of this field depends upon the choice of hash function (see Section 4.1.2), the hash tree degree, the signature input length, and the block size. 3.9 Block Signature This variable-length field contains exactly one public-key signature. Verification of this signature allows a receiver to authenticate the source of the RTP packet. The length of this field depends upon the choice of public-key signature scheme (see Section 4.1.1). 4. Processing of RTP Data Header Additions 4.1 Authentication Algorithms The contents of the Block Hashes and Block Signature fields are generated and verified with authentication algorithms determined by the SA or GSA. Two types of authentication algorithms are used in conjunction: public-key signature schemes and hash functions. McCarthy [Page 7] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 4.1.1 Public-Key Signature Schemes The SA or GSA identifies the public-key signature scheme used to create the block signature (Section 3.8). Currently suitable public-key signature schemes include DSA and RSA. Implementations are expected to rely upon existing PKI and signature scheme standards, e.g. [PKIX], to the extent possible. 4.1.2 Hash Functions The SA or GSA identifies the hash function used to generate the nodes of the hash tree (Section 3.9). Currently suitable hash functions include SHA-1 and RIPEMD-160. 4.2 Outbound Packet Processing 4.2.1 (Group) Security Association Lookup 4.2.2 Blocks of Packets A block signature authenticates a collection of RTP packets known as a block. A block consists of one or more packets with consecutive anti-replay Sequence Numbers. All packets in a block are protected with the same SA or GSA. Occasionally the chosen block size may exceed the number of remaining Sequence Number values before the Sequence Number cycles. However the Sequence Number cannot be cycled under the same SA or GSA (see Section 4.2.7). To resolve such a dilemma, the sender may choose a smaller block size that "fits" the unused Sequence Number space, or instead set up a new SA or GSA and key and reset the Sequence Number to zero. Within any given block, all packets in the block contain identical values in their respective Hash Tree Degree, Signature Input Length, Block Size, SPI, and Block Signature fields. Each packet in a block bears a unique Block Index with respect to that block. For future study: Should we permit a block to contain packets in multiple RTP streams? Perhaps this would be useful in applications where the sender produces multiple concurrent streams (e.g. audio + video). Handling of sequence numbers needs to be worked out for this. Would this raise other issues? McCarthy [Page 8] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 4.2.3 Packet Length The Packet Length is denumerated in 32-bit words. This length includes all RTP header fields, the RTP payload, and any explicit padding. Padding consisting of value "0" octets is appended to the RTP payload whenever necessary to ensure that the Packet Length is an integral multiple of 32 bits. The Packet Length is always greater than or equal to "6", because the fixed-length RTP data header and header additions for this profile always occupy a total of six 32-bit words. Note it is possible (and indeed necessary) for the sender to calculate the Packet Length before the value of the Block Signature field is known (see Section 3.9). 4.2.4 Hash Tree Degree, Signature Input Length, and Block Size These fields' values may be negotiated among the sender and receivers. Discovery of the receivers' capabilities to handle various values of these fields is outside the scope of this profile. The values of these fields satisfy the equation, Block Size = Signature Input Length * Hash Tree Degree^Height, where Height is the height of each hash tree in the block. The Hash Tree Degree, Signature Input Length, and Block Size fields are never "0". When hash trees of height one are used (i.e. each packet hash is a hash tree root), the tree contains only leaf nodes. In that case the value of the Hash Tree Degree field is set to "1". Otherwise the Hash Tree Degree is always greater than "1". In particular, hash trees of height greater than one with degree one non-leaf nodes are never used. Applications may adapt the Hash Tree Degree, Signature Input Length, and Block Size depending upon the resources of the sender and receiver(s) and the characteristics of the RTP application. Relevant considerations include the playback delay tolerance, payload generation rate, typical RTP payload size (if any), transmission buffer size, and playout buffer size. For example, applications that generate RTP packets relatively quickly and tolerate relatively long playback delays may elect to use relatively large authentication blocks. Details of the adaptation algorithm(s) are for future study. 4.2.5 Block Index The first packet in a block has Block Index "0". The last packet in a block has index Block Size - 1. Packets in a block are assigned Block Indices in the same order as Sequence Numbers. That is, the packet with lowest Sequence Number has index "0", the packet with second-lowest Sequence Number has index "1", etc. Note the value of this field is never 2^8 - 1 = "255", because the maximum legal Block Size is 2^8 - 1. McCarthy [Page 9] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 4.2.6 Sequence Number Generation The sender's counter is initialized to 0 when an SA or GSA is established. The sender increments the Sequence Number for this SA or GSA and inserts the new value into the Sequence Number Field. Thus the first packet sent using a given SA or GSA will have a Sequence Number of 1. If anti-replay is enabled (the default), the sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender does not send a packet on an SA or GSA if doing so would cause the Sequence Number to cycle. An attempt to transmit a packet that would result in Sequence Number overflow is an auditable event. (Note that this approach to Sequence Number management does not require use of modular arithmetic.) The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver(s). Thus, if the counter has cycled, the sender will set up a new SA or GSA and key (unless the SA or GSA was configured with manual key management). If anti-replay is disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management. However, the sender still increments the counter and rolls it over to zero when it reaches the maximum value. 4.2.7 Hash Tree Construction 4.2.7.1 Packet Hash Computation All portions of the RTP packet covered by the source authentication mechanism are input to the chosen hash function (see Section 4.1.2). The resulting packet hash forms part of the input to the block signature calculation (Section 4.2.9). Computation of the packet hash involves hashing the concatenation of RTP packet fields in the order presented below. The following fields in the RTP fixed header are included in the packet hash: Version, Padding bit, Extension bit, CSRC Count, Marker bit, Payload Type, 16-bit Sequence Number, Timestamp, SSRC The Padding bit is considered mutable and treated as having value "0" for the hash computation. (The Padding bit may be set by a separate network element that provides the RTP confidentiality service.) Note that unless the network element furnishing the RTP source authentication service is a mixer, the CSRC Count will be zero. The following fields in the RTP data header additions for this profile are included in the packet hash: Packet Length, Hash Tree Degree, Signature Input Length, Block Size, Block Index, SPI, 32-bit Sequence Number McCarthy [Page 10] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 The Block Hashes and Block Signature fields are NOT included in the packet hash. If present, the CSRC List is included in the packet hash. If present, an RTP data header extension is included in the packet hash. The RTP payload is included in the packet hash. Any explicit padding at the end of the RTP payload is included in the packet hash. Such padding may be due to this profile's 32-bit multiple length rule (Section 3.1) or confidentiality service requirements or packet compounding (see Section 5.1 of [SCFJ96, SCFJ99]). 4.2.7.2 Non-Leaf Nodes Each non-leaf node is computed by hashing the concatenation, in increasing Block Index order, of all the node's children. 4.2.8 Block Hashes Hash values appear in the following order in the Block Hashes field. Hash values in the lowest (deepest) level of the hash tree appear first, followed by hash values in the second-lowest level, etc. Hash values at the highest level -- hash tree roots -- appear last. Within each level, hash values appear in increasing order of Block Index. For purposes of determining this ordering, a non-leaf node is considered to have the lowest Block Index of all its descendants. At each level, only the sibling hashes of the current packet's ancestor at that level are included in this field. Note this field will be empty when the hash tree has height one. (The hash of the current packet, and its ancestors in the hash tree, are never explicitly sent.) For future study: Once the receiver verifies the Block Hashes and Block Signature for a particular block, that source authentication data need not accompany any additional packets in the block. Although RTP is not intended to provide reliable data transport, perhaps some limited form of signature verification ACKs could be sent with RTCP. These ACKs might take the form of SR/RR packet extensions or a new RTCP packet type. This could reduce the source authentication data overhead. For future work: Sender omission of redundant, previously acknowledged Block Hashes may be useful in some domains. See the related discussion in Section 4.2.9.2. McCarthy [Page 11] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 4.2.9 Block Signature The Block Signature is computed by applying the chosen public-key signature algorithm (Section 4.1.1) to the concatenation of all the hash tree roots in the block. The hash tree roots are concatenated in increasing order of Block Index. For purposes of determining this ordering, a hash tree root is considered to have the lowest Block Index of all its descendants. 4.2.9.1 Direct Signing of Hash Root(s) Typically public-key signatures are computed by applying a "raw" public-key signing operation to a hash of the input message to be signed. Thus the practice in [WL] of supplying a hash tree root as the input message to be signed potentially leads to a redundant hash computation (hash of a hash). Instead of hashing and signing hash tree root(s), this profile applies the raw public-key signature algorithm directly to the hash tree root(s) in the block. 4.2.9.2 Probabilistic Omission of Block Signatures It may be feasible in some application domains to exploit the loss characteristics of the underlying network to reduce authentication data overhead in packets. The signing schemes given in [WL] involve sending the Block Signature with every packet in the block. Under certain quality of service (QoS) commitments, however, it may be appropriate for the sender to omit the Block Signature (and possibly some Block Hashes) from some percentage of the packets in each block. In particular, receivers in a low-loss environment will be able to attain acceptable service quality in spite of Block Signature omissions by the sender. Details of the Block Signature omission rate calculation are for future study. 4.3 Inbound Packet Processing 4.3.1 (Group) Security Association Lookup Upon receipt of an RTP packet containing an source authentication header additions, the receiver determines the appropriate (unidirectional) SA or GSA. This determination is made on the basis of the destination IP address (or source IP address, in the case of a GSA), security protocol (RTP-src-auth), and the SPI. The SA or GSA indicates the RTP-src-auth version number and whether the Sequence Number field will be checked. The SA or GSA also specifies the algorithms employed for creating and signing the hash trees (see Section 4.1), and indicates the key(s) required to verify the Block Signature. If no valid Security Association or Group Security Association exists for this session (e.g., the receiver has no key), the receiver discards the packet; this is an auditable event. The audit log entry for this event includes the SPI value, date/ time, Source Address, and Destination Address. McCarthy [Page 12] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 4.3.2 Sequence Number Verification Use of the replay protection service may be enabled or disabled by the receiver(s) on a per-SA or per-GSA basis. (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA or GSA. Thus it is not appropriate to deploy the anti-replay service in a multi-sender environment that employs a single SA or GSA.) If the receiver does not enable anti-replay for an SA or GSA, no inbound checks are performed on the Sequence Number. However, from the perspective of the sender, the default is to assume that anti- replay is enabled at one or more receivers. If an automated SA or GSA establishment protocol is employed, the receiver(s) notify the sender -- during SA or GSA establishment -- if the receiver(s) will not provide anti-replay protection. This saves the sender from performing unnecessary sequence number monitoring and SA or GSA setup (see Section 4.2.6). If a receiver has enabled the anti-replay service for this SA or GSA, the receiver packet counter for the SA or GSA is initialized to zero when the SA or GSA is established. For each received packet, the receiver verifies that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received by this receiver during the life of this SA or GSA. Making this the first source authentication check applied to a packet after it has been matched to an SA or GSA will speed rejection of duplicate packets. Duplicates are rejected through the use of a sliding reception window. The "right" edge of the window represents the highest, validated Sequence Number value received on this SA or GSA. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in Appendix C of [KA98a]. If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to Block Signature verification. The reception window is updated only if the Block Signature verification succeeds. Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver authenticates the packet before updating the Sequence Number window data. 4.3.3 Validation of Fixed Header Additions The receiver uses the values of the Packet Length, Hash Tree Degree, Signature Input Length, Block Size, and Block Index fields to parse the fields beyond the fixed-length portion of the RTP data header additions. McCarthy [Page 13] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 The audit log entry for each of the auditable events enumerated in this section (4.3.3) includes the SPI, date, time, Source Address, Destination Address, and Sequence Number. 4.3.3.1 Packet Length Validation If the Packet Length is less than "6" a receiver discards the received RTP packet as invalid. If the value of the Packet Length field does not match the length (in 32-bit words) of the packet passed up to RTP from the lower-layer transport protocol then a receiver discards the packet as invalid. These are auditable events. 4.3.3.2 Hash Tree Parameter Validation If one or more of the Hash Tree Degree, Signature Input Length, and Block Size fields has value "0" a receiver discards the packet as invalid. This is an auditable event. If the values of the Hash Tree Degree, Signature Input Length, and Block Size fields do not satisfy the equation, Block Size = Signature Input Length * Hash Tree Degree^h, where h is a nonnegative integer, a receiver discards the packet as invalid. This is an auditable event. When this equation is satisfied by the received values, the receiver calculates the hash tree Height as the unique value of h satisfying the equation. If the Hash Tree Degree is "1" and the calculated Height is greater than "1", a receiver discards the packet as invalid. This is an auditable event. 4.3.3.3 Block Index Validation If the Block Index is greater than or equal to the Block Size, a receiver discards the packet as invalid. This is an auditable event. For each received packet, the receiver verifies that the packet contains a Block Index that does not duplicate the Block Index of any other packets in this block received by this receiver. Duplicates are rejected through the use of reception windows. Packets falling within a block's window are checked against a list of received and validated packets within the window. The reception window is updated only if the Block Signature verification succeeds. If no packets in the same block have previously been received and validated, the receiver opens a new reception window for that block. Note the receiver may have multiple block reception windows open simultaneously; the maximum number of such open windows will depend upon the Block Size(s) in use and the size of the anti-replay Sequence Number receive window. McCarthy [Page 14] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 The receiver closes a block reception window when the highest Sequence Number in that block reception window is to the "left" of the Sequence Number receive window (discussed in Section 4.3.2). The receiver closes all open block reception windows when the Sequence Number rolls over to "0" and a new SA or GSA is established. 4.3.4 Block Signature Verification To verify the Block Signature, the receiver first constructs the Packet Hash value for the received packet per Section 4.2.7.1. Then the receiver computes each of the hash tree roots of the current block. The receiver may cache and reuse hash tree node values computed from a previously received packet that was successfully verified. The length of the Block Hashes field (in bits) is given by the formula, Hash Length * (Height * (Hash Tree Degree - 1) + (Signature Input Length - 1)), where Hash Length is the output length (in bits) of the chosen hash algorithm (Section 4.1.2) and Height is the height of the hash tree calculated per Section 4.3.3.2. This length calculation allows the receiver to locate the start of the Block Signature, which immediately follows the Block Hashes field. The receiver uses the signature verification procedure of the chosen public-key signature algorithm (Section 4.1.1) to verify the Block Signature value with respect to the concatenated hash tree roots of the block. If the Block Signature verification fails, a receiver discards the packet as invalid; this is an auditable event. The audit log entry for this event includes the SPI, date, time, Source Address, Destination Address, and Sequence Number. The receiver may cache and reuse the results of previous Block Signature verifications. 5. Security Considerations This entire profile specifies security services for RTP packets, namely source authentication, non-repudiation, and replay protection. Cryptographic key management, including certification of signature verification keys, is not specified herein. It is anticipated that the work of [IPSEC, PKIX, SMUG] will provide these latter services. Guarantees of non-repudiation depend upon the properties of the particular public-key signature scheme(s) (Section 4.1.1) used with this profile. Privacy and confidentiality are not provided by this profile; however the RTP confidentiality service [SCFJ96, SCFJ99] may be used with this profile. McCarthy [Page 15] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 6. Acknowledgments The descriptions of the format and processing of the SPI and anti- replay sequence number fields are derived from text in the IP AH specification [KA98b]. Several other portions of the document structure are modelled after [KA98b]. The efforts of the IRTF Secure Multicast Research Group [SMUG] provided the impetus for drafting this profile. 7. References [CCPRRS] R. Canetti, P-C. Cheng, D. Pendarakis, J.R. Rao, P.Rohatgi and D. Saha, "An Architecture for Secure Internet Multicast", Internet Draft draft-irtf-smug-sec-mcast-arch-00.txt, work in progress, Feb. 1999. [CGIMNP] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B. Pinkas, "Multicast Security: A Taxonomy and Efficient Authentication", in Proc. IEEE INFOCOM '99, vol.2, pp. 708-716. [CP] R. Canetti and B. Pinkas, "A taxonomy of multicast security issues (updated version)", Internet Draft draft-irtf-smug-taxonomy-01.txt, work in progress, Apr. 1999. [IPSEC] IETF IP Security Protocol (ipsec) Working Group, http://www.ietf.org/html.charters/ipsec-charter.html [KA98a] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol", Internet RFC 2401, Nov. 1998. [KA98b] S. Kent and R. Atkinson, "IP Authentication Header", Internet RFC 2402, Nov. 1998. [MH] I. Monga and T. Hardjono, "Group Security Association (GSA) Definition for IP Multicast", Internet Draft draft-irtf-smug-gsadef-00.txt, work in progress, Feb. 1999. [PKIX] IETF Public-Key Infrastructure (X.509) (pkix) Working Group, http://www.ietf.org/html.charters/pkix-charter.html [Quinn] B. Quinn, "IP Multicast Applications: Challenges and Solutions", Internet Draft draft-quinn-multicast-apps-00.txt, work in progress, Nov. 1998. McCarthy [Page 16] INTERNET DRAFT draft-mccarthy-smug-rtp-profile-src-auth-00 May 1999 [Schulzrinne96] H. Schulzrinne, "RTP Profile for Audio and Video Conferences with Minimal Control", Internet RFC 1890, Jan. 1996. [Schulzrinne99] H. Schulzrinne, "RTP Profile for Audio and Video Conferences with Minimal Control", Internet Draft draft-ietf-avt-profile-new-05.txt, work in progress, Feb. 1999. [SCFJ96] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", Internet RFC 1889, Jan. 1996. [SCFJ99] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", Internet Draft draft-ietf-avt-rtp-new-03.txt, work in progress, Feb. 1999. [SMUG] IRTF Secure Multicast Research Group (smug), http://www.irtf.org/charters/secure-multicast.htm [WL] C-K. Wong and S. Lam, "Digital Signatures for Flows and Multicasts", in Proc. 6th IEEE Conference on Network Protocols (ICNP `98), Oct. 1998. 8. Author Contact Information Lewis McCarthy Department of Computer Science University of Massachusetts at Amherst Amherst, MA 01003, U.S.A. Tel: +1-413-545-2744 mailto:lmccarth@cs.umass.edu http://www.cs.umass.edu/~lmccarth/ McCarthy Expires November 1999 [Page 17]