draft-ietf-msec-srtp-tesla-05.txt   rfc4383.txt 
Internet Engineering Task Force Baugher (Cisco) Network Working Group M. Baugher
MSEC Working Group Carrara (Ericsson) Request for Comments: 4383 Cisco
INTERNET-DRAFT Category: Standards Track E. Carrara
EXPIRES: April 2006 October 2005 Royal Institute of Technology
February 2006
The Use of TESLA in SRTP
<draft-ietf-msec-srtp-tesla-05.txt>
Status of this memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, the authors accept the provisions
of BCP 78.
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 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
months and may be updated, replaced, or obsoleted by other documents in the Secure Real-time Transport Protocol (SRTP)
at any time. It is inappropriate to use Internet-Drafts as
reference material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo describes the use of the Timed Efficient Stream Loss- This memo describes the use of the Timed Efficient Stream Loss-
tolerant Authentication (RFC4082) transform within the Secure Real- tolerant Authentication (RFC4082) transform within the Secure Real-
time Transport Protocol (SRTP), to provide data origin time Transport Protocol (SRTP), to provide data origin authentication
authentication for multicast and broadcast data streams. for multicast and broadcast data streams.
TABLE OF CONTENTS Table of Contents
1. Introduction...................................................2 1. Introduction ....................................................2
1.1. Notational Conventions.......................................3 1.1. Notational Conventions .....................................3
2. SRTP...........................................................3 2. SRTP ............................................................3
3. TESLA..........................................................4 3. TESLA ...........................................................4
4. Usage of TESLA within SRTP.....................................4 4. Usage of TESLA within SRTP ......................................5
4.1. The TESLA extension..........................................4 4.1. The TESLA Extension ........................................5
4.2. SRTP Packet Format...........................................5 4.2. SRTP Packet Format .........................................6
4.3. Extension of the SRTP Cryptographic Context..................7 4.3. Extension of the SRTP Cryptographic Context ................7
4.4. SRTP Processing..............................................8 4.4. SRTP Processing ............................................8
4.4.1 Sender Processing...........................................9 4.4.1. Sender Processing ...................................9
4.4.2 Receiver Processing.........................................9 4.4.2. Receiver Processing .................................9
4.5. SRTCP Packet Format.........................................11 4.5. SRTCP Packet Format .......................................11
4.6. TESLA MAC...................................................13 4.6. TESLA MAC .................................................13
4.7. PRFs........................................................13 4.7. PRFs ......................................................13
5. TESLA Bootstrapping and Cleanup...............................14 5. TESLA Bootstrapping and Cleanup ................................14
6. SRTP TESLA Default parameters.................................14 6. SRTP TESLA Default Parameters ..................................14
7. Security Considerations.......................................15 7. Security Considerations ........................................15
8. IANA Considerations...........................................16 8. Acknowledgements ...............................................16
9. Acknowledgements..............................................16 9. References .....................................................17
10. Author's Addresses...........................................17 9.1. Normative References ......................................17
11. References...................................................17 9.2. Informative References ....................................17
1. Introduction 1. Introduction
Multicast and broadcast communications introduce some new security Multicast and broadcast communications introduce some new security
challenges compared to unicast communication. Many multicast and challenges compared to unicast communication. Many multicast and
broadcast applications need "data origin authentication" (DOA), or broadcast applications need "data origin authentication" (DOA), or
"source authentication", in order to guarantee that a received "source authentication", in order to guarantee that a received
message had originated from a given source, and was not manipulated message had originated from a given source, and was not manipulated
during the transmission. In unicast communication, a pairwise during the transmission. In unicast communication, a pairwise
security association between one sender and one receiver can provide security association between one sender and one receiver can provide
data origin authentication using symmetric-key cryptography (such as data origin authentication using symmetric-key cryptography (such as
a message authentication code, MAC). When the communication is a message authentication code, MAC). When the communication is
strictly pairwise, the sender and receiver agree upon a key that is strictly pairwise, the sender and receiver agree upon a key that is
known only to them. known only to them.
In groups, however, a key is shared among more than two members, and In groups, however, a key is shared among more than two members, and
this symmetric-key approach does not guarantee data origin this symmetric-key approach does not guarantee data origin
authentication. When there is a group security association authentication. When there is a group security association [RFC4046]
[RFC4046] instead of a pairwise security association, any of the instead of a pairwise security association, any of the members can
members can alter the packet and impersonate any other member. The alter the packet and impersonate any other member. The MAC in this
MAC in this case only guarantees that the packet was not manipulated case only guarantees that the packet was not manipulated by an
by an attacker outside the group (and hence not in possession of the attacker outside the group (and hence not in possession of the group
group key), and that the packet was sent by a source within the key), and that the packet was sent by a source within the group.
group.
Some applications cannot tolerate source ambiguity and need to Some applications cannot tolerate source ambiguity and need to
identify the true sender from any other group member. A common way identify the true sender from any other group member. A common way
to solve the problem is by use of asymmetric cryptography, such as to solve the problem is by use of asymmetric cryptography, such as
digital signatures. This method, unfortunately, suffers from high digital signatures. This method, unfortunately, suffers from high
overhead, in terms of time (to sign and verify) and bandwidth (to overhead in terms of time (to sign and verify) and bandwidth (to
convey the signature in the packet). convey the signature in the packet).
Several schemes have been proposed to provide efficient data origin Several schemes have been proposed to provide efficient data origin
authentication in multicast and broadcast scenarios. The Timed authentication in multicast and broadcast scenarios. The Timed
Efficient Stream Loss-tolerant Authentication (TESLA) is one such Efficient Stream Loss-tolerant Authentication (TESLA) is one such
scheme. scheme.
This memo specifies TESLA authentication for SRTP. SRTP TESLA can This memo specifies TESLA authentication for SRTP. SRTP TESLA can
provide data origin authentication to RTP applications that use provide data origin authentication to RTP applications that use group
group security associations (such as multicast RTP applications) so security associations (such as multicast RTP applications) so long as
long as receivers abide by the TESLA security invariants [RFC4082]. receivers abide by the TESLA security invariants [RFC4082].
1.1. Notational Conventions 1.1. Notational Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This specification assumes the reader is familiar with both SRTP and This specification assumes that the reader is familiar with both SRTP
TESLA. Few of their details are explained in this document, and the and TESLA. Few of their details are explained in this document, and
reader can find them in their respective specifications, [RFC3711] the reader can find them in their respective specifications,
and [RFC4082]. This specification uses the same definitions as [RFC3711] and [RFC4082]. This specification uses the same
TESLA for common terms and assumes that the reader is familiar with definitions as TESLA for common terms and assumes that the reader is
the TESLA algorithms and protocols [RFC4082]. familiar with the TESLA algorithms and protocols [RFC4082].
2. SRTP 2. SRTP
The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile
profile of RTP, which can provide confidentiality, message of RTP, which can provide confidentiality, message authentication,
authentication, and replay protection to the RTP traffic and to the and replay protection to the RTP traffic and to the RTP control
RTP control protocol, the Real-time Transport Control Protocol protocol, the Real-time Transport Control Protocol (RTCP). Note that
(RTCP). Note, the term "SRTP" may often be used to indicate SRTCP the term "SRTP" may often be used to indicate SRTCP as well.
as well.
SRTP is a framework that allows new security functions and new SRTP is a framework that allows new security functions and new
transforms to be added. SRTP currently does not define any transforms to be added. SRTP currently does not define any mechanism
mechanism to provide data origin authentication for group security to provide data origin authentication for group security
associations. Fortunately, it is straightforward to add TESLA to associations. Fortunately, it is straightforward to add TESLA to the
the SRTP cryptographic framework. SRTP cryptographic framework.
The TESLA extension to SRTP is defined in this specification, which The TESLA extension to SRTP is defined in this specification, which
assumes that the reader is familiar with the SRTP specification assumes that the reader is familiar with the SRTP specification
[RFC3711], its packet structure, and processing rules. TESLA is an [RFC3711], its packet structure, and its processing rules. TESLA is
alternative message-authentication algorithm that authenticates an alternative message-authentication algorithm that authenticates
messages from the source when a key is shared among two or more messages from the source when a key is shared among two or more
receivers. receivers.
3. TESLA 3. TESLA
TESLA provides delayed per-packet data authentication and is TESLA provides delayed per-packet data authentication and is
specified in [RFC4082]. specified in [RFC4082].
In addition to its SRTP data-packet definition given here, TESLA In addition to its SRTP data-packet definition given here, TESLA
needs an initial synchronization protocol and initial bootstrapping needs an initial synchronization protocol and initial bootstrapping
procedure. The synchronization protocol allows the sender and the procedure. The synchronization protocol allows the sender and the
receiver to compare their clocks and determine an upper bound of the receiver to compare their clocks and determine an upper bound of the
difference. The synchronization protocol is outside the scope of difference. The synchronization protocol is outside the scope of
this document. this document.
TESLA also requires an initial bootstrapping procedure to exchange TESLA also requires an initial bootstrapping procedure to exchange
needed parameters and the initial commitment to the key chain needed parameters and the initial commitment to the key chain
[RFC4082]. For SRTP, it is assumed that the bootstrapping is [RFC4082]. For SRTP, it is assumed that the bootstrapping is
performed out-of-band, possibly using the key management protocol performed out-of-band, possibly using the key management protocol
that is exchanging the security parameters for SRTP, e.g. [RFC3547, that is exchanging the security parameters for SRTP, e.g., [RFC3547,
RFC3830]. Initial bootstrapping of TESLA is outside the scope of RFC3830]. Initial bootstrapping of TESLA is outside the scope of
this document. this document.
4. Usage of TESLA within SRTP 4. Usage of TESLA within SRTP
The present specification is an extension to the SRTP specification The present specification is an extension to the SRTP specification
[RFC3711] and describes the use of TESLA with only a single key [RFC3711] and describes the use of TESLA with only a single key chain
chain and delayed-authentication [RFC4082]. and delayed-authentication [RFC4082].
4.1. The TESLA extension 4.1. The TESLA Extension
TESLA is an OPTIONAL authentication transform for SRTP. When used, TESLA is an OPTIONAL authentication transform for SRTP. When used,
TESLA adds the fields shown in Figure 1 per-packet. The fields TESLA adds the fields shown in Figure 1 per-packet. The fields added
added by TESLA are called "TESLA authentication extensions," whereas by TESLA are called "TESLA authentication extensions," whereas
"authentication tag" or "integrity protection tag" indicate the "authentication tag" or "integrity protection tag" indicate the
normal SRTP integrity protection tag, when the SRTP master key is normal SRTP integrity protection tag, when the SRTP master key is
shared by more than two endpoints [RFC3711]. shared by more than two endpoints [RFC3711].
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i | | i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Disclosed Key ~ ~ Disclosed Key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TESLA MAC ~ ~ TESLA MAC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The "TESLA authentication extension". Figure 1. The "TESLA authentication extension".
i: 32 bit, MANDATORY i: 32 bit, MANDATORY
Identifier of the time interval i, corresponding to the key K_i Identifier of the time interval i, corresponding to the key K_i,
that is used to calculate the TESLA MAC of the current packet which is used to calculate the TESLA MAC of the current packet
(and other packets sent in the current time interval i). (and other packets sent in the current time interval i).
Disclosed Key: variable length, MANDATORY Disclosed Key: variable length, MANDATORY
The disclosed key (K_(i-d)), that can be used to authenticate The disclosed key (K_(i-d)), which can be used to authenticate
previous packets from earlier time intervals [RFC4082]. A previous packets from earlier time intervals [RFC4082]. A
Section 4.3 parameter establishes the size of this field. Section 4.3 parameter establishes the size of this field.
TESLA MAC (Message Authentication Code): variable length, MANDATORY TESLA MAC (Message Authentication Code): variable length, MANDATORY
The MAC computed using the key K'_i (derived from K_i) The MAC computed using the key K'_i (derived from K_i)
[RFC4082], which is disclosed in a subsequent packet (in the [RFC4082], which is disclosed in a subsequent packet (in the
Disclosed Key field). The MAC coverage is defined in Section Disclosed Key field). The MAC coverage is defined in Section
4.6. A Section 4.3 parameter establishes the size of this 4.6. A Section 4.3 parameter establishes the size of this
field. field.
skipping to change at page 6, line 40 skipping to change at page 6, line 47
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ MAC ~ | | | ~ MAC ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | | | | |
+- Encrypted Portion TESLA Authenticated Portion ---+ | +- Encrypted Portion TESLA Authenticated Portion ---+ |
| |
Authenticated Portion ---+ Authenticated Portion ---+
Figure 2. The format of the SRTP packet when TESLA is applied. Figure 2. The format of the SRTP packet when TESLA is applied.
As in SRTP, the "Encrypted Portion" of an SRTP packet consists of As in SRTP, the "Encrypted Portion" of an SRTP packet consists of the
the encryption of the RTP payload (including RTP padding when encryption of the RTP payload (including RTP padding when present) of
present) of the equivalent RTP packet. the equivalent RTP packet.
The "Authenticated Portion" of an SRTP packet consists of the RTP The "Authenticated Portion" of an SRTP packet consists of the RTP
header, the Encrypted Portion of the SRTP packet, and the TESLA header, the Encrypted Portion of the SRTP packet, and the TESLA
authentication extension. Note that the definition is extended from authentication extension. Note that the definition is extended from
[RFC3711] by the inclusion of the TESLA authentication extension. [RFC3711] by the inclusion of the TESLA authentication extension.
The "TESLA Authenticated Portion" of an SRTP packet consists of the The "TESLA Authenticated Portion" of an SRTP packet consists of the
RTP header and the Encrypted Portion of the SRTP packet. As shown in RTP header and the Encrypted Portion of the SRTP packet. As shown in
Figure 2, SRTP HMAC-SHA1 covers up to the MKI field but does not Figure 2, the SRTP MAC covers up to the MKI field but does not
include the MKI. It is necessary for packet integrity that the include the MKI. It is necessary for packet integrity that the
SRTP-TESLA tag be covered by the SRTP integrity check. SRTP does SRTP-TESLA MAC tag be covered by the SRTP integrity check. SRTP does
not cover the MKI field (because it does not need to be covered for not cover the MKI field (because it does not need to be covered for
SRTP packet integrity). In order to make the two tags (SRTP-TESLA SRTP packet integrity). In order to make the two tags (SRTP-TESLA
and SRTP-HMAC_SHA1) contiguous, we would need to redefine the SRTP MAC and SRTP-MAC) contiguous, we would need to redefine the SRTP
specification to include the MKI in HMAC-SHA1 coverage. This change specification to include the MKI in SRTP-MAC coverage. This change
is impossible and so the MKI field separates the TESLA MAC from the is impossible, so the MKI field separates the TESLA MAC from the SRTP
SRTP MAC in the packet layout of Figure 2. This change to the MAC in the packet layout of Figure 2. This change to the packet
packet format presents no problem to an implementation that supports format presents no problem to an implementation that supports the new
the new SRTP-TESLA authentication transform. SRTP-TESLA authentication transform.
The lengths of the Disclosed Key and TELSA MAC fields are Section The lengths of the Disclosed Key and TESLA MAC fields are Section 4.3
4.3 parameters. As in SRTP, fields that follow the packet payload parameters. As in SRTP, fields that follow the packet payload are
are not necessarily aligned on 32-bit boundaries. not necessarily aligned on 32-bit boundaries.
4.3. Extension of the SRTP Cryptographic Context 4.3. Extension of the SRTP Cryptographic Context
When TESLA is used, the definition of cryptographic context in When TESLA is used, the definition of cryptographic context in
Section 3.2 of SRTP SHALL include the following extensions. Section 3.2 of SRTP SHALL include the following extensions.
Transform-dependent Parameters Transform-Dependent Parameters
1. an identifier for the PRF, f, implementing the one-way function 1. an identifier for the PRF (TESLA PRF), implementing the one-way
F(x) in TESLA (to derive the keys in the chain), e.g. to function F(x) in TESLA (to derive the keys in the chain), and
indicate HMAC-SHA1, see Section 6 for the default value. the one-way function F'(x) in TESLA (to derive the keys for the
TESLA MAC, from the keys in the chain), e.g., to indicate
HMAC-SHA1. See Section 6 for the default value.
2. a non-negative integer n_p, determining the length of the F 2. a non-negative integer, n_p, determining the length of the F
output, i.e. the length of the keys in the chain (that is also output; i.e., the length of the keys in the chain (that is also
the key disclosed in an SRTP packet), see Section 6 for the the key disclosed in an SRTP packet). See Section 6 for the
default value. default value.
3. an identifier for the PRF, f', implementing the one-way 3. a non-negative integer, n_f, determining the length of the
function F'(x) in TESLA (to derive the keys for the TESLA MAC, output of F', i.e., of the key for the TESLA MAC. See Section
from the keys in the chain), e.g. to indicate HMAC-SHA1, see 6 for the default value.
Section 6 for the default value.
4. a non-negative integer n_f, determining the length of the 4. an identifier for the TESLA MAC that accepts the output of
output of F', i.e. of the key for the TESLA MAC, see Section 6 F'(x) as its key, e.g., to indicate HMAC-SHA1. See Section 6
for the default value. for the default value.
5. an identifier for the TESLA MAC, that accepts the output of 5. a non-negative integer, n_m, determining the length of the
F'(x) as its key, e.g. to indicate HMAC-SHA1, see Section 6 for output of the TESLA MAC. See Section 6 for the default value.
the default value.
6. a non-negative integer n_m, determining the length of the
output of the TESLA MAC, see Section 6 for the default value.
7. the beginning of the session T_0, 6. the beginning of the session T_0.
8. the interval duration T_int (in msec), 7. the interval duration T_int (in msec).
9. the key disclosure delay d (in number of intervals) 8. the key disclosure delay d (in number of intervals).
10. the upper bound D_t (in sec) on the lag of the receiver clock 9. the upper bound D_t (in sec) on the lag of the receiver clock
relative to the sender clock (this quantity has to be relative to the sender clock (this quantity has to be
calculated by the peers out-of-band) calculated by the peers out-of-band).
11. non-negative integer n_c, determining the length of the key 10. a non-negative integer, n_c, determining the length of the key
chain, K_0...K_n-1 of [RFC4082] (see also Section 6 of this chain, K_0...K_n-1 of [RFC4082] (see also Section 6 of this
document), which is determined based upon the expected duration document), which is determined based upon the expected duration
of the stream. of the stream.
12. the initial key of the chain to which the sender has 11. the initial key of the chain to which the sender has committed
committed himself. himself.
F(x) is used to compute a keychain of keys in SRTP TESLA, as defined F(x) is used to compute a keychain of keys in SRTP TESLA, as defined
in Section 6. Also according to TESLA, F'(x) computes a TESLA MAC in Section 6. Also according to TESLA, F'(x) computes a TESLA MAC
key with inputs as defined in Section 6. key with inputs as defined in Section 6.
Section 6 of this document defines the default values for the Section 6 of this document defines the default values for the
transform-specific TESLA parameters. transform-specific TESLA parameters.
4.4. SRTP Processing 4.4. SRTP Processing
The SRTP packet processing is described in Section 3.3 of the SRTP The SRTP packet processing is described in Section 3.3 of the SRTP
specification [RFC3711]. The use of TESLA slightly changes the specification [RFC3711]. The use of TESLA slightly changes the
processing, as the SRTP MAC is checked upon packet arrival for DoS processing, as the SRTP MAC is checked upon packet arrival for DoS
prevention, but the current packet is not TESLA-authenticated. Each prevention, but the current packet is not TESLA-authenticated. Each
packet is buffered until a subsequent packet discloses its TESLA packet is buffered until a subsequent packet discloses its TESLA key.
key. The TESLA verification itself consists of some steps, such as The TESLA verification itself consists of some steps, such as tests
tests of TESLA security invariants, that are described in Section of TESLA security invariants, that are described in Sections 3.5-3.7
3.5-3.7 of [RFC4082]. The words "TESLA computation" and "TESLA of [RFC4082]. The words "TESLA computation" and "TESLA verification"
verification" hereby imply all those steps, which are not all hereby imply all those steps, which are not all spelled out in the
spelled out in the following. In particular, notice that the TESLA following. In particular, notice that the TESLA verification implies
verification implies checking the safety condition (Section 3.5 of checking the safety condition (Section 3.5 of [RFC4082]).
[RFC4082]).
As pointed out in [RFC4082], if the packet is deemed "unsafe", then As pointed out in [RFC4082], if the packet is deemed "unsafe", then
the receiver considers the packet unauthenticated. It should discard the receiver considers the packet unauthenticated. It should discard
unsafe packets but, at its own risk, it may choose to use them unsafe packets, but, at its own risk, it may choose to use them
unverified. Hence, if the safe condition does not hold, it is unverified. Hence, if the safe condition does not hold, it is
RECOMMENDED to discard the packet and log the event. RECOMMENDED to discard the packet and log the event.
4.4.1 Sender Processing 4.4.1. Sender Processing
The sender processing is as described in Section 3.3 of [RFC3711, up The sender processing is as described in Section 3.3 of [RFC3711], up
to step 5 inclusive. After that the following process is followed: to step 5, inclusive. After that, the following process is followed:
6. When TESLA is applied, identify the key in the TESLA chain to be 6. When TESLA is applied, identify the key in the TESLA chain to be
used in the current time interval, and the TESLA MAC key derived used in the current time interval, and the TESLA MAC key derived
from it. Execute the TESLA computation to obtain the TESLA from it. Execute the TESLA computation to obtain the TESLA
authentication extension for the current packet, by appending the authentication extension for the current packet, by appending the
current interval identifier (as i field), the disclosed key of the current interval identifier (as i field), the disclosed key of the
chain for the previous disclosure interval (i.e. the key for chain for the previous disclosure interval (i.e., the key for
interval i is disclosed in interval i+d), and the TESLA MAC under interval i is disclosed in interval i+d), and the TESLA MAC under
the current key from the chain. This step uses the related TESLA the current key from the chain. This step uses the related TESLA
parameters from the crypto context as for Step 4. parameters from the crypto context as for Step 4.
7. If the MKI indicator in the SRTP crypto context is set to one, 7. If the MKI indicator in the SRTP crypto context is set to one,
append the MKI to the packet. append the MKI to the packet.
8. When TESLA is applied, and if the SRTP authentication (external 8. When TESLA is applied, and if the SRTP authentication (external
tag) is required (for DoS), compute the authentication tag as tag) is required (for DoS), compute the authentication tag as
described in step 7 of Section 3.3 of the SRTP specification, but described in step 7 of Section 3.3 of the SRTP specification, but
with coverage as defined in this specification (see Section 4.6). with coverage as defined in this specification (see Section 4.6).
9. If necessary, update the rollover counter (step 8 in Section 3.3 9. If necessary, update the rollover counter (step 8 in Section 3.3
of [RFC3711]). of [RFC3711]).
4.4.2 Receiver Processing 4.4.2. Receiver Processing
The receiver processing is as described in Section 3.3 of [RFC3711], The receiver processing is as described in Section 3.3 of [RFC3711],
up to step 4 inclusive. up to step 4, inclusive.
To authenticate and replay-protect the current packet, the To authenticate and replay-protect the current packet, the processing
processing is as follows: is as follows:
First check if the packet has been replayed (as for Section 3.3 of First, check if the packet has been replayed (as per Section 3.3
[RFC3711]). Note however, the SRTP replay list contains SRTP of [RFC3711]). Note, however, that the SRTP replay list contains
indices of recently received packets that have been authenticated SRTP indices of recently received packets that have been
by TESLA (i.e. replay list updates MUST NOT be based on SRTP MAC). authenticated by TESLA (i.e., replay list updates MUST NOT be
If the packet is judged to be replayed, then the packet MUST be based on SRTP MAC). If the packet is judged to be replayed, then
discarded, and the event SHOULD be logged. the packet MUST be discarded, and the event SHOULD be logged.
Next, perform verification of the SRTP integrity protection tag Next, perform verification of the SRTP integrity protection tag
(note, not the TESLA MAC), if present, using the rollover counter (not the TESLA MAC), if present, using the rollover counter from
from the current packet, the authentication algorithm indicated in the current packet, the authentication algorithm indicated in the
the cryptographic context, and the session authentication key. If cryptographic context, and the session authentication key. If the
the verification is unsuccessful, the packet MUST be discarded verification is unsuccessful, the packet MUST be discarded from
from further processing and the event SHOULD be logged. further processing, and the event SHOULD be logged.
If the verification is successful, remove and store the MKI (if If the verification is successful, remove and store the MKI (if
present) and authentication tag fields from the packet. The packet present) and authentication tag fields from the packet. The
is buffered, awaiting disclosure of the TESLA key in a subsequent packet is buffered, awaiting disclosure of the TESLA key in a
packet. subsequent packet.
TESLA authentication is performed on a packet when the key is TESLA authentication is performed on a packet when the key is
disclosed in a subsequent packet. Recall that a key for interval i disclosed in a subsequent packet. Recall that a key for interval
is disclosed during interval i+d, i.e. the same key is disclosed i is disclosed during interval i+d, i.e., the same key is
in packets sent over d intervals of length t_int. If the interval disclosed in packets sent over d intervals of length t_int. If
identifier i from the packet (Section 4.1) has advanced more than the interval identifier i from the packet (Section 4.1) has
d intervals from the highest value of i that has been received, advanced more than d intervals from the highest value of i that
then packets have been lost and one or more keys MUST be computed has been received, then packets have been lost, and one or more
as described in Section 3.2, second paragraph, of the TESLA keys MUST be computed as described in Section 3.2, second
specification [RFC4082]. The computation is performed recursively paragraph, of the TESLA specification [RFC4082]. The computation
for all disclosed keys that have been lost, from the newly- is performed recursively for all disclosed keys that have been
received interval to the last-received interval. lost, from the newly-received interval to the last-received
interval.
When a newly-disclosed key is received or computed, perform the When a newly-disclosed key is received or computed, perform the
TESLA verification of the packet using the rollover counter from TESLA verification of the packet using the rollover counter from
the packet, the TESLA security parameters from the cryptographic the packet, the TESLA security parameters from the cryptographic
context, and the disclosed key. If the verification is context, and the disclosed key. If the verification is
unsuccessful, the packet MUST be discarded from further processing unsuccessful, the packet MUST be discarded from further
and the event SHOULD be logged. If the TESLA verification is processing, and the event SHOULD be logged. If the TESLA
successful, remove the TESLA authentication extension from the verification is successful, remove the TESLA authentication
packet. extension from the packet.
To decrypt the current packet, the processing is the following: To decrypt the current packet, the processing is as follows:
Decrypt the Encrypted Portion of the packet, using the decryption Decrypt the Encrypted Portion of the packet, using the decryption
algorithm indicated in the cryptographic context, the session algorithm indicated in the cryptographic context, the session
encryption key and salt (if used) found in Step 4 with the index encryption key, and salt (if used) found in Step 4 with the index
from Step 2. from Step 2.
(Note that the order of decryption and TESLA verification is not (Note that the order of decryption and TESLA verification is not
mandated. It is RECOMMENDED to perform the TESLA verification mandated. It is RECOMMENDED that the TESLA verification be performed
before decryption. TESLA application designers might choose to before decryption. TESLA application designers might choose to
implement optimistic processing techniques such as notification of implement optimistic processing techniques such as notification of
TESLA verification results after decryption or even after plaintext TESLA verification results after decryption or even after plaintext
processing. Optimistic verification is beyond the scope of this processing. Optimistic verification is beyond the scope of this
document.) document.)
Update the rollover counter and highest sequence number, s_l, in the Update the rollover counter and highest sequence number, s_l, in the
cryptographic context, using the packet index estimated in Step 2. cryptographic context, using the packet index estimated in Step 2.
If replay protection is provided, also update the Replay List (i.e., If replay protection is provided, also update the Replay List (i.e.,
the Replay List is updated after the TESLA authentication is the Replay List is updated after the TESLA authentication is
successfully verified). successfully verified).
4.5. SRTCP Packet Format 4.5. SRTCP Packet Format
Figure 3 illustrates the format of the SRTCP packet when TESLA is Figure 3 illustrates the format of the SRTCP packet when TESLA is
applied. The TESLA authentication extension SHALL be inserted applied. The TESLA authentication extension SHALL be inserted before
before the MKI and authentication tag. Recall from [RFC3711] that the MKI and authentication tag. Recall from [RFC3711] that in SRTCP
in SRTCP the MKI is OPTIONAL, while the E-bit, the SRTCP index, and the MKI is OPTIONAL, while the E-bit, the SRTCP index, and the
the authentication tag are MANDATORY. This means that the SRTP authentication tag are MANDATORY. This means that the SRTP
(external) MAC is MANDATORY also when TESLA is used. (external) MAC is MANDATORY also when TESLA is used.
As in SRTP, the "Encrypted Portion" of an SRTCP packet consists of As in SRTP, the "Encrypted Portion" of an SRTCP packet consists of
the encryption of the RTCP payload of the equivalent compound RTCP the encryption of the RTCP payload of the equivalent compound RTCP
packet, from the first RTCP packet, i.e., from the ninth (9) byte to packet, from the first RTCP packet, i.e., from the ninth (9) byte to
the end of the compound packet. the end of the compound packet.
The "Authenticated Portion" of an SRTCP packet consists of the The "Authenticated Portion" of an SRTCP packet consists of the entire
entire equivalent (eventually compound) RTCP packet, the E flag, the equivalent (eventually compound) RTCP packet, the E flag, the SRTCP
SRTCP index (after any encryption has been applied to the payload), index (after any encryption has been applied to the payload), and the
and the TESLA extension. Note that the definition is extended from TESLA extension. Note that the definition is extended from [RFC3711]
[RFC3711] by the inclusion of the TESLA authentication extension. by the inclusion of the TESLA authentication extension.
We define the "TESLA Authenticated Portion" of an SRTCP packet as We define the "TESLA Authenticated Portion" of an SRTCP packet as
consisting of the RTCP header (first 8 bytes) and the Encrypted consisting of the RTCP header (first 8 bytes) and the Encrypted
Portion of the SRTCP packet. Portion of the SRTCP packet.
Processing of an SRTCP packets is similar to the SRTP processing Processing of an SRTCP packets is similar to the SRTP processing
(Section 4.3), but there are SRTCP-specific changes described in (Section 4.3), but there are SRTCP-specific changes described in
Section 3.4 of the SRTP specification [RFC3711] and in Section 4.6 Section 3.4 of the SRTP specification [RFC3711] and in Section 4.6 of
of this memo. this memo.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+
|V=2|P| RC | PT=SR or RR | length | | | |V=2|P| RC | PT=SR or RR | length | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| SSRC of sender | | | | SSRC of sender | | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
| ~ sender info ~ | | | ~ sender info ~ | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
skipping to change at page 13, line 9 skipping to change at page 13, line 9
Figure 3. The format of the SRTCP packet when TESLA is applied. Figure 3. The format of the SRTCP packet when TESLA is applied.
Note that when additional fields are added to a packet, it will Note that when additional fields are added to a packet, it will
increase the packet size and thus the RTCP average packet size. increase the packet size and thus the RTCP average packet size.
4.6. TESLA MAC 4.6. TESLA MAC
Let M' denote packet data to be TESLA-authenticated. In the case of Let M' denote packet data to be TESLA-authenticated. In the case of
SRTP, M' SHALL consist of the SRTP TESLA Authenticated Portion (RTP SRTP, M' SHALL consist of the SRTP TESLA Authenticated Portion (RTP
header and SRTP Encrypted Portion, see Figure 2) of the packet header and SRTP Encrypted Portion; see Figure 2) of the packet
concatenated with the rollover counter (ROC) of the same packet: concatenated with the rollover counter (ROC) of the same packet:
M' = ROC || TESLA Authenticated Portion. M' = ROC || TESLA Authenticated Portion.
In the case of SRTCP, M' SHALL consist of the SRTCP TESLA In the case of SRTCP, M' SHALL consist of the SRTCP TESLA
Authenticated Portion only (RTCP header and SRTCP Encrypted Authenticated Portion only (RTCP header and SRTCP Encrypted Portion).
Portion).
The normal authentication tag (OPTIONAL for SRTP, MANDATORY for The normal authentication tag (OPTIONAL for SRTP, MANDATORY for
SRTCP) SHALL be applied with the same coverage as specified in SRTCP) SHALL be applied with the same coverage as specified in
[RFC3711], i.e.: [RFC3711]. That is:
- for SRTP: Authenticated Portion || ROC (with the extended - for SRTP: Authenticated Portion || ROC (with the extended
definition of SRTP Authentication Portion as in Section 4.2) definition of SRTP Authentication Portion as in Section 4.2).
- for SRTCP: Authenticated Portion (with the extended definition of - for SRTCP: Authenticated Portion (with the extended definition of
SRTCP Authentication Portion as in Section 4.2). SRTCP Authentication Portion as in Section 4.2).
The pre-defined authentication transform in SRTP, HMAC-SHA1 The predefined authentication transform in SRTP, HMAC-SHA1 [RFC2104],
[RFC2104], is also used to generate the TESLA MAC. For SRTP is also used to generate the TESLA MAC. For SRTP (and respectively
(respectively SRTCP), the HMAC SHALL be applied to the key in the for SRTCP), the HMAC SHALL be applied to the key in the TESLA chain
TESLA chain corresponding to a particular time interval, and M' as corresponding to a particular time interval, and to M' as specified
specified above. The HMAC output SHALL then be truncated to the n_m above. The HMAC output SHALL then be truncated to the n_m left-most
left-most bits. Default values are in Section 6. bits. Default values are in Section 6.
As with SRTP, the pre-defined HMAC-SHA1 authentication algorithm MAY As with SRTP, the predefined HMAC-SHA1 authentication algorithm MAY
be replaced with an alternative algorithm that is specified in a be replaced with an alternative algorithm that is specified in a
future Internet RFC. future Internet RFC.
4.7. PRFs 4.7. PRFs
TESLA requires two pseudo-random functions (PRFs), f and f', to TESLA requires a pseudo-random function (PRF) to implement
implement
* one one-way function F(x) to derive the key chain, and * one one-way function F(x) to derive the key chain, and
* one one-way function F'(x) to derive (from each key of the chain) * one one-way function F'(x) to derive (from each key of the chain)
the key that is actually used to calculate the TESLA MAC. the key that is actually used to calculate the TESLA MAC.
When TESLA is used within SRTP, the default choice of the two PRFs When TESLA is used within SRTP, the default choice of the PRF SHALL
SHALL be HMAC-SHA1. Default values are in Section 6. be HMAC-SHA1. Default values are in Section 6.
Other PRFs can be chosen, and their use SHALL follow the common Other PRFs can be chosen, and their use SHALL follow the common
guidelines in [RFC3711] when adding new security parameters. guidelines in [RFC3711] when adding new security parameters.
5. TESLA Bootstrapping and Cleanup 5. TESLA Bootstrapping and Cleanup
The extensions to the SRTP cryptographic context include a set of The extensions to the SRTP cryptographic context include a set of
TESLA parameters that are listed in section 4.3 of this document. TESLA parameters that are listed in Section 4.3 of this document.
Furthermore, TESLA MUST be bootstrapped at session set-up (for the Furthermore, TESLA MUST be bootstrapped at session setup (for the
parameter exchange and the initial key commitment) through a regular parameter exchange and the initial key commitment) through a regular
data authentication system (a digital signature algorithm is data authentication system (a digital signature algorithm is
RECOMMENDED). Key management procedures can take care of this RECOMMENDED). Key management procedures can take care of this
bootstrapping prior to the commencement of an SRTP session where bootstrapping prior to the commencement of an SRTP session where
TESLA authentication is used. The bootstrapping mechanism is out of TESLA authentication is used. The bootstrapping mechanism is out of
scope for this document (it could for example be part of the key scope for this document (it could, for example, be part of the key
management protocol). management protocol).
A critical factor for the security of TESLA is that the sender and A critical factor for the security of TESLA is that the sender and
receiver need to be loosely synchronized. TESLA requires a bound on receiver need to be loosely synchronized. TESLA requires a bound on
clock drift to be known (D_t). Use of TESLA in SRTP assumes that clock drift to be known (D_t). Use of TESLA in SRTP assumes that the
the time synchronization is guaranteed by out-of-band schemes (e.g. time synchronization is guaranteed by out-of-band schemes (e.g., key
key management), i.e. it is not in the scope of SRTP. management). That is, it is not in the scope of SRTP.
It also should be noted that TESLA has some reliability requirements It also should be noted that TESLA has some reliability requirements
in that a key is disclosed for a packet in a subsequent packet, in that a key is disclosed for a packet in a subsequent packet, which
which can get lost. Since a key in a lost packet can be derived from can get lost. Since a key in a lost packet can be derived from a
a future packet, TESLA is robust to packet loss. This key stream future packet, TESLA is robust to packet loss. This key stream
stops, however, when the key-bearing data stream packets stop at the stops, however, when the key-bearing data stream packets stop at the
conclusion of the RTP session. To avoid this nasty boundary conclusion of the RTP session. To avoid this nasty boundary
condition, send null packets with TESLA keys for one entire key- condition, send null packets with TESLA keys for one entire key-
disclosure period following the interval in which the stream ceases: disclosure period following the interval in which the stream ceases:
Null packets SHOULD be sent for d intervals of duration t_int (items Null packets SHOULD be sent for d intervals of duration t_int (items
8 and 9 of Section 4.3). The rate of null packets SHOULD be the 8 and 9 of Section 4.3). The rate of null packets SHOULD be the
average rate of the session media stream. average rate of the session media stream.
6. SRTP TESLA Default parameters 6. SRTP TESLA Default Parameters
Key management procedures establish SRTP TESLA operating parameters, Key management procedures establish SRTP TESLA operating parameters,
which are listed in section 4.3 of this document. The operating which are listed in Section 4.3 of this document. The operating
parameters appear in the SRTP cryptographic context and have the parameters appear in the SRTP cryptographic context and have the
default values that are described in this section. In the future, default values that are described in this section. In the future, an
an Internet RFC MAY define alternative settings for SRTP TESLA that Internet RFC MAY define alternative settings for SRTP TESLA that are
are different than those specified here. In particular, it should different than those specified here. In particular, note that the
be noted that the settings defined in this memo can have a large settings defined in this memo can have a large impact on bandwidth,
impact on bandwidth, as it adds 38 bytes to each packet (when the as they add 38 bytes to each packet (when the field length values are
field length values are the default ones). For certain the default ones). For certain applications, this overhead may
applications, this overhead may represent more than a 50% increase represent more than a 50% increase in packet size. Alternative
in packet size. Alternative settings might seek to reduce the settings might seek to reduce the number and length of various TESLA
number and length of various TESLA fields and outputs. No such fields and outputs. No such optimizations are considered in this
optimizations are considered in this memo. memo.
It is RECOMMENDED that the SRTP MAC be truncated to 32 bits since the It is RECOMMENDED that the SRTP MAC be truncated to 32 bits, since
SRTP MAC provides only group authentication and serves only as the SRTP MAC provides only group authentication and serves only as
protection against external DoS. protection against external DoS.
The default values for the security parameters are listed in the The default values for the security parameters are listed in the
following. "OWF" denotes a one-way function. following table.
Parameter Mandatory-to-support Default Parameter Mandatory-to-support Default
--------- -------------------- ------- --------- -------------------- -------
TESLA KEYCHAIN OWF (F(x)) HMAC-SHA1 HMAC-SHA1 TESLA PRF HMAC-SHA1 HMAC-SHA1
BIT-OUTPUT LENGTH n_p 160 160 BIT-OUTPUT LENGTH n_p 160 160
TESLA MAC KEY OWF (F'(F(x))) HMAC-SHA1 HMAC-SHA1
BIT-OUTPUT LENGTH n_f 160 160 BIT-OUTPUT LENGTH n_f 160 160
TESLA MAC HMAC-SHA1 HMAC-SHA1 TESLA MAC HMAC-SHA1 HMAC-SHA1
(TRUNCATED) BIT-OUTPUT LENGTH n_m 80 80 (TRUNCATED) BIT-OUTPUT LENGTH n_m 80 80
As shown above, TESLA implementations MUST support HMAC-SHA1 As shown above, TESLA implementations MUST support HMAC-SHA1
[RFC2104] for the TESLA MAC, the MAC key generator, and the TESLA [RFC2104] for the TESLA MAC and the TESLA PRF. The TESLA keychain
keychain generator one-way function. The TESLA keychain generator is generator is recursively defined as follows [RFC4082].
recursively defined as follows [RFC4082].
K_i=HMAC_SHA1(K_{i+1},0), i=0..N-1 K_i=HMAC_SHA1(K_{i+1},0), i=0..N-1
where N-1=n_c from the cryptographic context. where N-1=n_c from the cryptographic context.
The TESLA MAC key generator is defined as follows [RFC4082]. The TESLA MAC key generator is defined as follows [RFC4082].
K'_i=HMAC_SHA1(K_i,1) K'_i=HMAC_SHA1(K_i,1)
The TESLA MAC uses a truncated output of ten bytes [RFC2104] and is The TESLA MAC uses a truncated output of ten bytes [RFC2104] and is
defined as follows. defined as follows.
HMAC_SHA1(K'_i, M') HMAC_SHA1(K'_i, M')
where M' is as specified in Section 4.6. where M' is as specified in Section 4.6.
7. Security Considerations 7. Security Considerations
Denial of Service (DoS) attacks on delayed authentication are Denial of Service (DoS) attacks on delayed authentication are
discussed in [PCST]. TESLA requires receiver buffering before discussed in [PCST]. TESLA requires receiver buffering before
authentication, therefore the receiver can suffer a denial of authentication; therefore, the receiver can suffer a denial of
service attack due to a flood of bogus packets. To address this service attack due to a flood of bogus packets. To address this
problem, the external SRTP MAC, based on the group key, MAY be used problem, the external SRTP MAC, based on the group key, MAY be used
in addition to the TESLA MAC. The short size of the SRTP MAC in addition to the TESLA MAC. The short size of the SRTP MAC
(default 32 bits) is motivated by the fact that that MAC is purely (default 32 bits) is motivated because that MAC is purely for DoS
for DoS prevention from attackers external to the group. The shorter prevention from attackers external to the group. The shorter output
output tag means that an attacker has a better chance of getting a tag means that an attacker has a better chance of getting a forged
forged packet accepted, which is about 2^31 attempts on average. As packet accepted, which is about 2^31 attempts on average. As a first
a first line of defense against a denial of service attack, a short line of defense against a denial of service attack, a short tag is
tag is probably adequate; a victim will likely have ample evidence probably adequate; a victim will likely have ample evidence that it
that it is under attack before accepting a forged packet, which will is under attack before accepting a forged packet, which will
subsequently fail the TESLA check. [RFC4082] describes other subsequently fail the TESLA check. [RFC4082] describes other
mechanisms that can be used to prevent DoS, in place of the external mechanisms that can be used to prevent DoS, in place of the external
group-key MAC. If used, they need to be added as processing steps group-key MAC. If used, they need to be added as processing steps
(following the guidelines of [RFC4082]). (following the guidelines of [RFC4082]).
The use of TESLA in SRTP defined in this specification is subject to The use of TESLA in SRTP defined in this specification is subject to
the security considerations discussed in the SRTP specification the security considerations discussed in the SRTP specification
[RFC3711] and in the TESLA specification [RFC4082]. In particular, [RFC3711] and in the TESLA specification [RFC4082]. In particular,
the TESLA security is dependent on the computation of the "safety the TESLA security is dependent on the computation of the "safety
condition" as defined in Section 3.5 of [RFC4082]. condition" as defined in Section 3.5 of [RFC4082].
SRTP TESLA depends on the effective security of the systems that SRTP TESLA depends on the effective security of the systems that
perform bootstrapping (time synchronization) and key management. perform bootstrapping (time synchronization) and key management.
These systems are external to SRTP and are not considered in this These systems are external to SRTP and are not considered in this
specification. specification.
The length of the TESLA MAC is by default 80 bits. RFC 2104 requires The length of the TESLA MAC is by default 80 bits. RFC 2104 requires
the MAC length to be at least 80 bits and at least half the output the MAC length to be at least 80 bits and at least half the output
size of the underlying hash function. The SHA-1 output size is 160 size of the underlying hash function. The SHA-1 output size is 160
bits, so both of these requirements are met with the 80 bit MAC bits, so both of these requirements are met with the 80-bit MAC
specified in this document. Note that IPsec implementations tend to specified in this document. Note that IPsec implementations tend to
use 96 bits for their MAC values to align the header with a 64 bit use 96 bits for their MAC values to align the header with a 64-bit
boundary. Both MAC sizes are well beyond the reach of current boundary. Both MAC sizes are well beyond the reach of current
cryptanalytic techniques. cryptanalytic techniques.
8. IANA Considerations 8. Acknowledgements
No IANA registration is required.
9. Acknowledgements
The authors would like to thanks Ran Canetti, Karl Norrman, Mats The authors would like to thank Ran Canetti, Karl Norrman, Mats
Naslund, Fredrik Lindholm, David McGrew, and Bob Briscoe for their Naslund, Fredrik Lindholm, David McGrew, and Bob Briscoe for their
valuable help. valuable help.
10. Author's Addresses 9. References
Questions and comments should be directed to the authors and 9.1. Normative References
msec@ietf.org:
Mark Baugher [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Cisco Systems, Inc. Hashing for Message Authentication", RFC 2104, February
5510 SW Orchid Street Phone: +1 408-853-4418 1997.
Portland, OR 97219 USA Email: mbaugher@cisco.com
Elisabetta Carrara [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Ericsson Requirement Levels", BCP 14, RFC 2119, March 1997.
SE-16480 Stockholm Phone: +46 8 50877040
Sweden EMail: elisabetta.carrara@ericsson.com
11. References [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
Normative [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RFC1305] Mills D., Network Time Protocol (Version 3) Specification, 9.2. Informative References
Implementation and Analysis, Internet Engineering Task Force, RFC
1305, March, 1992.
[RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for [PCST] Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient
Message Authentication," Internet Engineering Task Force, RFC 2104, and Secure Source Authentication for Multicast", in Proc.
February, 1997. of Network and Distributed System Security Symposium NDSS
2001, pp. 35-46, 2001.
[RFC2119] Bradner, Keywords to Use in RFCs to Indicate Requirement [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Levels, Internet Engineering Task Force, RFC 2119, March 1997. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3711] Baugher, McGrew, Naslund, Carrara, Norrman, "The Secure [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Real-time Transport Protocol", Internet Engineering Task Force, RFC Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
3711, March 2004. August 2004.
[RFC4082] Perrig, Song, Canetti, Tygar, Briscoe, "TESLA: Multicast [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
Source Authentication Transform Introduction", Internet Engineering "Multicast Security (MSEC) Group Key Management
Task Force, RFC 4082, June 2005. Architecture", RFC 4046, April 2005.
Informative Authors' Addresses
[PCST] Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient and Questions and comments should be directed to the authors and
Secure Source Authentication for Multicast", in Proc. of Network and msec@ietf.org.
Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001.
[RFC3547] Baugher, Weis, Hardjono, Harney, "The Group Domain of Mark Baugher
Interpretation", Internet Engineering Task Force, RFC 3547, July Cisco Systems, Inc.
2003. 5510 SW Orchid Street
Portland, OR 97219 USA
[RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing", RFC Phone: +1 408-853-4418
3830, Internet Engineering Task Force, August 2004. EMail: mbaugher@cisco.com
[RFC4046] Baugher, Canetti, Dondeti, Lindholm, "MSEC Group Key Elisabetta Carrara
Management Architecture", Internet Engineering Task Force, April Royal Institute of Technology
2005. Stockholm
Sweden
Copyright Notice EMail: carrara@kth.se
Copyright (C) The Internet Society (2005). This document is subject Full Copyright Statement
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclaimer of Validity Copyright (C) The Internet Society (2006).
This document and the information contained herein are provided on This document is subject to the rights, licenses and restrictions
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE contained in BCP 78, and except as set forth therein, the authors
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE retain all their rights.
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF This document and the information contained herein are provided on an
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This draft expires in April 2006. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 106 change blocks. 
306 lines changed or deleted 278 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/