One document matched: draft-mccarthy-smug-rtp-profile-src-auth-00.txt
RTP Profile for Source Authentication and Non-Repudiation
of Audio and Video Conferences
<draft-mccarthy-smug-rtp-profile-src-auth-00.txt>
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]
| PAFTECH AB 2003-2026 | 2026-04-22 22:47:54 |