< draft-ietf-msec-srtp-tesla-02.txt   draft-ietf-msec-srtp-tesla-03.txt >
Internet Engineering Task Force Baugher (Cisco) Internet Engineering Task Force Baugher (Cisco)
MSEC Working Group Carrara (Ericsson) MSEC Working Group Carrara (Ericsson)
INTERNET-DRAFT INTERNET-DRAFT
EXPIRES: April 2005 October 2004 EXPIRES: August 2005 February 2005
The Use of TESLA in SRTP The Use of TESLA in SRTP
<draft-ietf-msec-srtp-tesla-02.txt> <draft-ietf-msec-srtp-tesla-03.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, the authors certify that any By submitting this Internet-Draft, the authors certify that any
applicable patent or other IPR claims of which I am (we are) aware applicable patent or other IPR claims of which I am (we are) aware
have been disclosed, and any of which I (we) become aware will be have been disclosed, and any of which I (we) become aware will be
disclosed, in accordance with RFC 3668 (BCP 79). disclosed, in accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, the authors accept the provisions By submitting this Internet-Draft, the authors accept the provisions
of Section 3 of RFC 3667 (BCP 78). of Section 3 of RFC 3667 (BCP 78).
skipping to change at page 3, line 43 skipping to change at page 3, line 43
and [TESLA]. This specification uses the same definitions as TESLA and [TESLA]. This specification uses the same definitions as TESLA
for common terms and assumes that the reader is familiar with the for common terms and assumes that the reader is familiar with the
TESLA algorithms and protocols [TESLA]. TESLA algorithms and protocols [TESLA].
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 of RTP, which can provide confidentiality, message profile of RTP, which can provide confidentiality, message
authentication, and replay protection to the RTP traffic and to the authentication, and replay protection to the RTP traffic and to the
RTP control protocol, the Real-time Transport Control Protocol RTP control protocol, the Real-time Transport Control Protocol
(RTCP). Note, the term SRTP may often be used to indicate SRTCP as (RTCP). Note, the term "SRTP" may often be used to indicate SRTCP
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 to provide data origin authentication for group security mechanism 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 SRTP cryptographic framework. the 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. [RFC3711], its packet structure, and processing rules.
skipping to change at page 4, line 25 skipping to change at page 4, line 25
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
[TESLA]. For SRTP, it is assumed that the bootstrapping is [TESLA]. 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. [GDOI], that is exchanging the security parameters for SRTP, e.g. [GDOI,
[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 and delayed-authentication [TESLA]. chain and delayed-authentication [TESLA].
4.1. The TESLA extension 4.1. The TESLA extension
skipping to change at page 5, line 18 skipping to change at page 5, line 18
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 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 present in the current that is used to calculate the TESLA MAC of the current packet
packet (and in the 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)), that can be used to authenticate
previous packets from earlier time intervals [TESLA]. previous packets from earlier time intervals [TESLA].
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) [TESLA], The MAC computed using the key K'_i (derived from K_i) [TESLA],
which is disclosed in a subsequent packet (in the Disclosed Key which is disclosed in a subsequent packet (in the Disclosed Key
field). The MAC coverage is defined in Section 4.6. field). The MAC coverage is defined in Section 4.6.
skipping to change at page 8, line 35 skipping to change at page 8, line 35
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. The TESLA verification itself consists of some steps, such as key. The TESLA verification itself consists of some steps, such as
tests of TESLA security invariants, that are described in Section tests of TESLA security invariants, that are described in Section
3.5-3.7 of [TESLA]. The words "TESLA computation" and "TESLA 3.5-3.7 of [TESLA]. The words "TESLA computation" and "TESLA
verification" hereby imply all those steps, which are not all verification" hereby imply all those steps, which are not all
spelled out in the following. In particular, notice that the TESLA spelled out in the following. In particular, notice that the TESLA
verification implies checking the safety condition (Section 3.5 of verification implies checking the safety condition (Section 3.5 of
[TESLA]). If the safe condition does not hold, the packet MUST be [TESLA]).
discarded, and the event SHOULD be logged.
As pointed out in [TESLA], if the packet is deemed "unsafe", then
the receiver considers the packet unauthenticated. It should discard
unsafe packets but, at its own risk, it may choose to use them
unverified. Hence, if the safe condition does not hold, it is
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], The sender processing is as described in Section 3.3 of [RFC3711],
up to step 5 included. After that the following process is up to step 5 included. After that the following process is
followed: 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 time (as i field), the disclosed key of the chain current interval identifier (as i field), the disclosed key of the
for an earlier packet, and the TESLA MAC under the current key from chain for an earlier interval, and the TESLA MAC under the current
the chain. This step uses the related TESLA parameters from the key from the chain. This step uses the related TESLA parameters from
crypto context as for Step 4. 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 ROC (step 8 in Section 3.3 of 9. If necessary, update the ROC (step 8 in Section 3.3 of
skipping to change at page 13, line 24 skipping to change at page 13, line 27
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 time synchronization is guaranteed by out-of-band schemes (e.g. the time synchronization is guaranteed by out-of-band schemes (e.g.
key management), i.e. it is not in the scope of SRTP. key management), i.e. it is not in the scope of SRTP.
It is also important to realize that TESLA has some reliability It also should be noted that TESLA has some reliability requirements
requirements in that a key is disclosed for a packet in a subsequent in that a key is disclosed for a packet in a subsequent packet,
packet, which can get lost. Since a key is repeated across packets which can get lost. Since a key in a lost packet can be derived from
in an interval, TESLA is robust to packet loss. This repetition a future packet, TESLA is robust to packet loss. This repetition
might abruptly stop, however, if the key-bearing packets stop might abruptly stop, however, if the key-bearing packets stop
abruptly at the end of the stream. To avoid this nasty boundary abruptly at the end of the stream. To avoid this nasty boundary
condition, send null packets with TESLA keys for one entire interval condition, send null packets with TESLA keys for one entire interval
following the interval in which the stream ceases. following the interval in which the stream ceases.
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,
listed in section 4.3 of this document. The operating parameters which are listed in section 4.3 of this document. The operating
appear in the SRTP cryptographic context and have the following parameters appear in the SRTP cryptographic context and have the
default values. In the future, an Internet RFC MAY define default values that are described in this section. In the future,
alternative settings for SRTP TESLA that are different than those an Internet RFC MAY define alternative settings for SRTP TESLA that
specified here. In particular, it should be noted that the settings are different than those specified here. In particular, it should
defined in this memo can have a large impact on bandwidth, as it be noted that the settings defined in this memo can have a large
adds 38 bytes to each packet (when the field length values are the impact on bandwidth, as it adds 38 bytes to each packet (when the
default ones). For certain applications, this overhead may field length values are the default ones). For certain
represent more than a 50% increase in packet size. Alternative applications, this overhead may represent more than a 50% increase
settings might seek to reduce the number and length of various TESLA in packet size. Alternative settings might seek to reduce the
fields and outputs. No such optimizations are considered in this number and length of various TESLA fields and outputs. No such
memo. optimizations are considered in this 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 the
SRTP MAC provides only group authentication and serves only as SRTP MAC provides only group authentication and serves only as
protection against external DoS. protection against external DoS.
6.1 Transform-independent Parameters 6.1 Transform-independent Parameters
The value of the flag indicating the use of TESLA in SRTP is by The value of the flag indicating the use of TESLA in SRTP is by
default zero (TESLA not used). default zero (TESLA not used).
skipping to change at page 15, line 7 skipping to change at page 15, line 7
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 when delayed authentication is used Denial of Service (DoS) attacks on delayed authentication are
are discussed in [PCST]. TESLA requires receiver's 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 current specification REQUIRES the use of a 32-bit SRTP problem, the external SRTP MAC, based on the group key, MAY be used
MAC in addition to TESLA MAC. The shorter size of the SRTP MAC is in addition to the TESLA MAC. The short size of the SRTP MAC
here motivated by the fact that that MAC served purely for DoS (default 32 bits) is here motivated by the fact that that MAC served
prevention from attackers external to the group. purely for DoS prevention from attackers external to the group.
[TESLA] describes other mechanisms that can be used to prevent DoS,
in alternative to the external group-key MAC. Where these are used,
they need to be add as processing steps (following the guidelines of
[TESLA]).
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 [TESLA]. In particular, the [RFC3711] and in the TESLA specification [TESLA]. In particular, the
TESLA security is dependent on the computation of the "safety TESLA security is dependent on the computation of the "safety
condition" as defined in Section 3.5 of [TESLA]. condition" as defined in Section 3.5 of [TESLA].
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
skipping to change at page 16, line 5 skipping to change at page 16, line 6
10. Author's Addresses 10. Author's Addresses
Questions and comments should be directed to the authors and Questions and comments should be directed to the authors and
msec@ietf.org: msec@ietf.org:
Mark Baugher Mark Baugher
Cisco Systems, Inc. Cisco Systems, Inc.
5510 SW Orchid Street Phone: +1 408-853-4418 5510 SW Orchid Street Phone: +1 408-853-4418
Portland, OR 97219 USA Email: mbaugher@cisco.com Portland, OR 97219 USA Email: mbaugher@cisco.com
Elisabetta Carrara Elisabetta Carrara
Ericsson Research Ericsson Research
SE-16480 Stockholm Phone: +46 8 50877040 SE-16480 Stockholm Phone: +46 8 50877040
Sweden EMail: elisabetta.carrara@ericsson.com Sweden EMail: elisabetta.carrara@ericsson.com
11. References 11. References
Normative Normative
[PCST] Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient and [PCST] Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient and
Secure Source Authentication for Multicast", in Proc. of Network and Secure Source Authentication for Multicast", in Proc. of Network and
Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001. Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001.
[RFC1305] Mills D., Network Time Protocol (Version 3) [RFC1305] Mills D., Network Time Protocol (Version 3) Specification,
Specification, Implementation and Analysis, RFC 1305, March, 1992. Implementation and Analysis, RFC 1305, March, 1992.
http://www.ietf.org/rfc/rfc1305.txt
[RFC3711] Baugher, McGrew, Naslund, Carrara, Norrman, "The Secure [RFC3711] Baugher, McGrew, Naslund, Carrara, Norrman, "The Secure
Real-time Transport Protocol", RFC 3711, March 2004. Real-time Transport Protocol", RFC 3711, March 2004.
[TESLA] Perrig, Canetti, Song, Tygar, Briscoe, "TESLA: Multicast [TESLA] Perrig, Canetti, Song, Tygar, Briscoe, "TESLA: Multicast
Source Authentication Transform Introduction", August 2004, draft- Source Authentication Transform Introduction", December 2004, draft-
ietf-msec-tesla-intro-03.txt. ietf-msec-tesla-intro-04.txt.
Informative Informative
[gkmarch] Baugher, Canetti, Dondeti, Lindholm, "MSEC Group Key [gkmarch] Baugher, Canetti, Dondeti, Lindholm, "MSEC Group Key
Management Architecture", June 2004, <draft-ietf-msec-gkmarch- Management Architecture", June 2004, <draft-ietf-msec-gkmarch-
08.txt>. 08.txt>.
[GDOI] Baugher, Weis, Hardjono, Harney, "The Group Domain of [GDOI] Baugher, Weis, Hardjono, Harney, "The Group Domain of
Interpretation", RFC 3547, July 2003. Interpretation", RFC 3547, July 2003.
skipping to change at page 16, line 48 skipping to change at page 17, line 4
[RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing", [RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing",
December 2003, RFC 3830, August 2004. December 2003, RFC 3830, August 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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 2005. This draft expires in August 2005.
 End of changes. 17 change blocks. 
44 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/