< draft-ietf-msec-bootstrapping-tesla-02.txt   draft-ietf-msec-bootstrapping-tesla-03.txt >
MSEC S. Fries MSEC S. Fries
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Expires: April 17, 2006 Siemens Expires: July 15, 2006 Siemens
October 14, 2005 January 11, 2006
Bootstrapping TESLA Bootstrapping TESLA
draft-ietf-msec-bootstrapping-tesla-02.txt draft-ietf-msec-bootstrapping-tesla-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2006. This Internet-Draft will expire on July 15, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
TESLA, the Timed Efficient Stream Loss-tolerant Authentication TESLA, the Timed Efficient Stream Loss-tolerant Authentication
protocol is a protocol for providing source authentication in protocol is a protocol for providing source authentication in
multicast scenarios. TESLA is an efficient protocol with low multicast scenarios. TESLA is an efficient protocol with low
communication and computation overhead, which scales to large numbers communication and computation overhead, which scales to large numbers
of receivers, and also tolerates packet loss. TESLA is based on of receivers, and also tolerates packet loss. TESLA is based on
loose time synchronization between the sender and the receivers. loose time synchronization between the sender and the receivers.
Source authentication is realized in TESLA by using MAC chaining. Source authentication is realized in TESLA by using Message
The use of TESLA within the Secure Real-time Transport Protocol Authentication Code (MAC) chaining. The use of TESLA within the
(SRTP) has been published targeting multicast authentication in Secure Real-time Transport Protocol (SRTP) has been published
scenarios, where SRTP is applied to protect the multimedia data. targeting multicast authentication in scenarios, where SRTP is
This solution assumes that TESLA parameters are made available by applied to protect the multimedia data. This solution assumes that
out-of-band mechanisms. TESLA parameters are made available by out-of-band mechanisms.
This document specifies MIKEY payloads for bootstrapping TESLA for This document specifies payloads for the Multimedia Internet Keying
source authentication of secure group communications using SRTP. (MIKEY) protocol for bootstrapping TESLA for source authentication of
TESLA may be bootstrapped using one of the MIKEY key management secure group communications using SRTP. TESLA may be bootstrapped
approaches, e.g., by using a digitally signed MIKEY message sent via using one of the MIKEY key management approaches, e.g., by using a
unicast, multicast or broadcast. digitally signed MIKEY message sent via unicast, multicast or
broadcast.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. TESLA Parameter Overview . . . . . . . . . . . . . . . . . . . 4 3. TESLA Parameter Overview . . . . . . . . . . . . . . . . . . . 4
4. Parameter encoding within MIKEY . . . . . . . . . . . . . . . 5 4. Parameter encoding within MIKEY . . . . . . . . . . . . . . . 6
4.1. Security Policy payload (SP) . . . . . . . . . . . . . . . 6 4.1. Security Policy payload (SP) . . . . . . . . . . . . . . . 6
4.2. TESLA policy . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. TESLA policy . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Time synchronization . . . . . . . . . . . . . . . . . . . 8 4.3. Time synchronization . . . . . . . . . . . . . . . . . . . 9
4.4. Key data transport within MIKEY's General Extension 4.4. Key data transport within MIKEY's General Extension
Payload . . . . . . . . . . . . . . . . . . . . . . . . . 9 Payload . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5.1. MitM Attack . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Man-in-the-Middle (MitM) Attack . . . . . . . . . . . . . 11
5.2. Downgrading Attack . . . . . . . . . . . . . . . . . . . . 12 5.2. Downgrading Attack . . . . . . . . . . . . . . . . . . . . 12
5.3. Denial of Service Attack . . . . . . . . . . . . . . . . . 12 5.3. Denial of Service Attack . . . . . . . . . . . . . . . . . 12
5.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 12 5.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 13 5.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
In many multicast, broadcast, and also unicast communication In many multicast, broadcast, and also unicast communication
scenarios it is necessary to guarantee that a recieved message has scenarios it is necessary to guarantee that a recieved message has
been sent from a dedicated source and has not been altered while in been sent from a dedicated source and has not been altered while in
transfer. In unicast communication commonly a pairwise security transfer. In unicast communication commonly a pairwise security
association exists, which enables the validation of message integrity association exists, which enables the validation of message integrity
and data origin. The approach in group based communication is and data origin. The approach in group based communication is
different as here a key is normally shared between the members of a different as here a key is normally shared between the members of a
skipping to change at page 3, line 26 skipping to change at page 3, line 26
of a sender is required, there exists the requirement to support data of a sender is required, there exists the requirement to support data
origin authentication also in multicast scenarios. One of the origin authentication also in multicast scenarios. One of the
methods supporting this is TESLA [RFC4082]. TESLA provides source methods supporting this is TESLA [RFC4082]. TESLA provides source
authentication in multicast scenarios by using MAC chaining. It is authentication in multicast scenarios by using MAC chaining. It is
based on loose time synchronization between the sender and the based on loose time synchronization between the sender and the
receivers. receivers.
[I-D.ietf-msec-srtp-tesla] describes extensions for SRTP [RFC3711] in [I-D.ietf-msec-srtp-tesla] describes extensions for SRTP [RFC3711] in
order to support TESLA [RFC4082] for source authentication in order to support TESLA [RFC4082] for source authentication in
multicast scenarios. SRTP needs dedicated cryptographic context multicast scenarios. SRTP needs dedicated cryptographic context
describing the security paramter and security policy per multimedia describing the security parameter and security policy per multimedia
session to be protected. This cryptographic context needs to be session to be protected. This cryptographic context needs to be
enhanced with a set of TESLA parameters. It is necessary to provide enhanced with a set of TESLA parameters. It is necessary to provide
these parameters before the actual multicast session starts. these parameters before the actual multicast session starts.
[I-D.ietf-msec-srtp-tesla] does not address the bootstrapping for [I-D.ietf-msec-srtp-tesla] does not address the bootstrapping for
these parameters. these parameters.
This document details bootstrapping of TESLA parameters in terms of This document details bootstrapping of TESLA parameters in terms of
parameter distribution for TESLA policy as well as the initial key, parameter distribution for TESLA policy as well as the initial key,
using the Multimedia Internet Keying (MIKEY) [RFC3830] protocol. using the Multimedia Internet Keying (MIKEY) [RFC3830] protocol.
MIKEY defines an authentication and key management framework that can MIKEY defines an authentication and key management framework that can
be used for real-time applications (both for peer-to-peer be used for real-time applications (both for peer-to-peer
communication and group communication). In particular, [RFC3830] is communication and group communication). In particular, [RFC3830] is
defined in a way to support SRTP in the first place but is open to defined in a way that is intended to support SRTP in the first place
enhancements to be used for other purposes too. Following the but is open to enhancements to be used for other purposes too.
description in RFC 3830 [RFC3830] MIKEY is targeted for point-to- Following the description in RFC 3830 [RFC3830] MIKEY is targeted for
point as well as for group communication. In the context of group point-to-point as well as for group communication. In the context of
communication an administrator entity can distribute session keys to group communication an administrator entity can distribute session
the associated entities participating in the communication session. keys to the associated entities participating in the communication
This scenario is also applicable for TESLA where one entity may session. This scenario is also applicable for TESLA where one entity
provide information to many others in a way that the integrity of the may provide information to many others in a way that the integrity of
communicated information can be assured. The combination of MIKEY the communicated information can be assured. The combination of
and TESLA supports this group-based approach by utilizing the MIKEY MIKEY and TESLA supports this group-based approach by utilizing the
framework to distribute TESLA parameter information to all involved MIKEY framework to distribute TESLA parameter information to all
entities. Note that this document does only focus on the involved entities. Note that this document only focuses on the
distribution of the parameters, not on the generation. distribution of the parameters, not on the generation of those
parameters.
MIKEY [RFC3830] itself describes three authentication and key MIKEY [RFC3830] itself describes three authentication and key
exchange protocols (symmetric key enryption, public key encryption, exchange protocols (symmetric key enryption, public key encryption,
and signed Diffie Hellman) Extensions to the MIKEY key exchange and signed Diffie-Hellman) Extensions to the MIKEY key exchange
methods have been defined. A fourth key distribution method is methods have been defined. A fourth key distribution method is
provided by [I-D.ietf-msec-mikey-dhhmac] and describes a symetrically provided by [I-D.ietf-msec-mikey-dhhmac] and describes a symetrically
protected Diffie Hellman key agreement. Recently a further option protected Diffie-Hellman key agreement. A further option has been
has been proposed in [I-D.ietf-msec-mikey-rsa-r] describing an proposed in [I-D.ietf-msec-mikey-rsa-r] describing an enhanced
enhanced asymmetric exchange variant, supporting also inband asymmetric exchange variant, supporting also inband certificate
certificate exchange. All of the different key management schemens exchange. All of the different key management schemes mentioned
mentioned above may be used to provide the TESLA parameters. The above may be used to provide the TESLA parameters. The required
required TESLA parameters to be exchanged are already described in TESLA parameters to be exchanged are already described in [I-D.ietf-
[I-D.ietf-msec-srtp-tesla], while this document describes their msec-srtp-tesla], while this document describes their transport
transport within MIKEY. within MIKEY.
The following security requirements have to be placed on the exchange The following security requirements have to be placed on the exchange
of TESLA parameters: of TESLA parameters:
o Authentication and Integrity MUST be provided when sending the o Authentication and Integrity MUST be provided when sending the
TESLA parameters, especially for the initial key. TESLA parameters, especially for the initial key.
o Confidentiality MAY be provided for the TESLA parameters o Confidentiality MAY be provided for the TESLA parameters
These security requirements apply to the TESLA bootstrapping These security requirements apply to the TESLA bootstrapping
procedure only. Security requirements for applications using TESLA procedure only. Security requirements for applications using TESLA
are beyond the scope of this document. Security aspects that relate are beyond the scope of this document. Security aspects that relate
to TESLA itself are described in [RFC4082] and security issues for to TESLA itself are described in [RFC4082] and security issues for
TESLA usage for SRTP is covered in [I-D.ietf-msec-srtp-tesla]. TESLA usage for SRTP are covered in [I-D.ietf-msec-srtp-tesla].
It is important to note that this document is one piece of a complete It is important to note that this document is one piece of a complete
solution. Assuming that media traffic is to be secured using TESLA solution. Assuming that media traffic is to be secured using TESLA
as described in [I-D.ietf-msec-srtp-tesla] then (a) keying material as described in [I-D.ietf-msec-srtp-tesla] then (a) keying material
is required and (b) parameters for TESLA. This document contributes is required and (b) parameters for TESLA. This document contributes
the parameters and the authentication methods used in MIKEY to the parameters and the authentication methods used in MIKEY to
provide the keying material. The parameter exchange for TESLA also provide the keying material. The parameter exchange for TESLA also
needs to be secured against tampering. This protection is provided needs to be secured against tampering. This protection is provided
also by MIKEY. also by MIKEY.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. TESLA Parameter Overview 3. TESLA Parameter Overview
According to [I-D.ietf-msec-srtp-tesla] the following transform According to [I-D.ietf-msec-srtp-tesla] a number of transform
dependent parameters need to be provided for proper TESLA operation dependent parameters need to be provided for proper TESLA operation.
(the information in brackets provides the default values specified in
section 6.2 of [I-D.ietf-msec-srtp-tesla]:
1. An identifier for the PRF, implementing the one-way function The complete list of parameters can be found in Section 4.3 of
F(x) in TESLA (F(x) is used to calculate keys using a hash [I-D.ietf-msec-srtp-tesla]. Note, that the parameter 10 of
chain), e.g. to indicate a keyed hashing function (dafault HMAC- [I-D.ietf-msec-srtp-tesla], describing the lag of the receiver clock
SHA1). relative to the sender clock, is omitted in this document since it
can be computed.
MIKEY already requires synchronized clocks, which also provides for
synchronization for TESLA. Moreover, Section 4.3, states an option
to use MIKEY for clock drift determination between sender and
receiver. Thus, this parameter does not need to be transmitted in
MIKEY directly.
The information in brackets provides the default values as specified
in Section 6.2 of [I-D.ietf-msec-srtp-tesla].
1. An identifier for the Pseudo Random Function (PRF), implementing
the one-way function F(x) in TESLA (F(x) is used to calculate
keys using a hash chain), e.g. to indicate a keyed hashing
function (default HMAC-SHA1).
2. A non-negative integer, determining the length of the F output, 2. A non-negative integer, determining the length of the F output,
i.e. the length of the keys in the chain (that is also the key i.e. the length of the keys in the chain (that is also the key
disclosed in an SRTP packet if TESLA is used in the SRTP disclosed in an SRTP packet if TESLA is used in the SRTP
context) (dafault 160 bit). context) (default 160 bit).
3. An identifier for the PRF, implementing the one-way function 3. An identifier for the PRF, implementing the one-way function
F'(x) in TESLA (to derive the keys for the TESLA MAC, from the F'(x) in TESLA (to derive the keys for the TESLA MAC, from the
keys in the chain), e.g. to indicate a keyed hashing function keys in the chain), e.g. to indicate a keyed hashing function
(default HMAC-SHA1). (default HMAC-SHA1).
4. A non-negative integer, determining the length of the output of 4. A non-negative integer, determining the length of the output of
F', i.e. the length of the key for the TESLA MAC (default 160 F', i.e. the length of the key for the TESLA MAC (default 160
bit). bit).
skipping to change at page 5, line 47 skipping to change at page 6, line 16
the period after which the key will be sent to the involved the period after which the key will be sent to the involved
entities (e.g., as part of SRTP packets). entities (e.g., as part of SRTP packets).
10. Non-negative integer, determining the length of the key chain, 10. Non-negative integer, determining the length of the key chain,
which is determined based up the expected duration of the which is determined based up the expected duration of the
stream. stream.
11. The initial key of the chain to which the sender has committed 11. The initial key of the chain to which the sender has committed
himself. himself.
Section 6.2 in [I-D.ietf-msec-srtp-tesla] provides more information
about the default value for the above-listed parameters.
4. Parameter encoding within MIKEY 4. Parameter encoding within MIKEY
As mentioned in Section 3, TESLA parameters need to be transported As mentioned in Section 3, TESLA parameters need to be transported
before actually starting a session. MIKEY currently only defines a before actually starting a session. MIKEY currently only defines a
payload for transporting the SRTP policy (see Section 6.10 of payload for transporting the SRTP policy (see Section 6.10 of
[RFC3830]). This section describes the enhancement of MIKEY to allow [RFC3830]). This section describes the enhancement of MIKEY to allow
the transport of a TESLA policy and additionally the initial TESLA the transport of a TESLA policy and additionally the initial TESLA
key. key.
4.1. Security Policy payload (SP) 4.1. Security Policy payload (SP)
The Security Policy payload defines a set of policies that apply to a The Security Policy payload defines a set of policies that apply to a
skipping to change at page 8, line 19 skipping to change at page 8, line 19
3 | PRF identifier for f', realising F'(x) | see below 3 | PRF identifier for f', realising F'(x) | see below
4 | Length of PRF f' output | 160 4 | Length of PRF f' output | 160
5 | Identifier for the TESLA MAC | see below 5 | Identifier for the TESLA MAC | see below
6 | Length of TESLA MAC output | 80 (truncated) 6 | Length of TESLA MAC output | 80 (truncated)
7 | Start of session | in bytes 7 | Start of session | in bytes
8 | Interval duration (in msec) | in bytes 8 | Interval duration (in msec) | in bytes
9 | Key disclosure delay | in bytes 9 | Key disclosure delay | in bytes
10| Key chain length (numer of intervals) | in bytes 10| Key chain length (numer of intervals) | in bytes
11| local timestamp media receiver | see below 11| local timestamp media receiver | see below
The time values stated in items 7 and 11 SHALL be transported in NTP-
UTC format, which is one of the three options described in Section
6.6 of [RFC3830]. For the policy item 8 a four-byte integer value
and for the policy item 9 a two-byte integer value is RECOMMENDED
carrying interval and key disclosure delay. Note that the policy
type 11 does NOT correspond to the TESLA parameter 11 stated in
Section 3, which is actually discussed in Section 4.4. Moreover, the
policy type 11 stated above is optional and SHOULD be used, if the
time synchronization described in Section 4.3 point two is used.
Otherwise it SHOULD be omitted.
For the PRF realising F(x), a one byte length is sufficient. For the PRF realising F(x), a one byte length is sufficient.
The currently defined possible values are: The currently defined possible values are:
TESLA PRF F(x) | Value TESLA PRF F(x) | Value
----------------------- -----------------------
HMAC-SHA1 | 0 HMAC-SHA1 | 0
For the PRF realising F'(x), a one byte length is enough. For the PRF realising F'(x), a one byte length is enough.
The currently defined possible values are: The currently defined possible values are:
skipping to change at page 9, line 4 skipping to change at page 9, line 15
4.3. Time synchronization 4.3. Time synchronization
MIKEY as well as TESLA require the time synchronization of the MIKEY as well as TESLA require the time synchronization of the
communicating peers. MIKEY requires time sychronization to provide communicating peers. MIKEY requires time sychronization to provide
timestamp-based replay protection for the one-roundtrip timestamp-based replay protection for the one-roundtrip
authentication and key exchange protocols. TESLA, on the other hand, authentication and key exchange protocols. TESLA, on the other hand,
needs this information to determine the clock drift between the needs this information to determine the clock drift between the
senders and the receivers in order to appropriately release the senders and the receivers in order to appropriately release the
disclosed key. Two alternatives are available for time disclosed key. Two alternatives are available for time
synchronization: synchronization:
1. Usage of out-of-band synchronization using NTP [RFC1305]. This 1. Usage of out-of-band synchronization using NTP [RFC1305]. This
approach is already recommended within [RFC3830]. The advantage approach is already recommended within [RFC3830]. The advantage
of this approach is the option to use the MIKEY key management of this approach is the option to use the MIKEY key management
variants that perform within a half-roundtrip. The disadvantage variants that perform within a half-roundtrip. The disadvantage
is the required time synchronization via an additional protocol. is the required time synchronization via an additional protocol.
2. [RFC4082] also sketches a possible inband synchronization in 2. [RFC4082] also sketches a possible inband synchronization in
Section 3.3.1. This approach is shortly repeated here in the Section 3.3.1. This approach is summarized here in the context
context of MIKEY. Note, that here the actual TESLA policy of MIKEY. Note, that here the actual TESLA policy payload is
payload is transmitted as part of the MIKEY responder message. transmitted as part of the MIKEY responder message.
* The data receiver, which would be the MIKEY initiator sets the * The data receiver, which would be the MIKEY initiator sets the
local time parameter t_r and sends it as part of the timestamp local time parameter t_r and sends it as part of the timestamp
payload as described in [RFC3830]. This value t_r needs to be payload as described in [RFC3830]. This value t_r needs to be
stored locally. stored locally.
* Upon receipt of the MIKEY initiator message the data sender * Upon receipt of the MIKEY initiator message the data sender
replies with the MIKEY responder message, setting the local replies with the MIKEY responder message, setting the local
time stamp at data receiver (parameter 11) to the value t_r time stamp at data receiver (parameter 11) to the value t_r
received in the MIKEY initiator message and sets his local received in the MIKEY initiator message and sets his local
time as 64 bit UTC value t_s in the timestamp payload as time as 64 bit UTC value t_s in the timestamp payload as
described in [RFC3830]. described in [RFC3830].
skipping to change at page 9, line 44 skipping to change at page 10, line 5
* Upon receiving the MIKEY responder message the data receiver * Upon receiving the MIKEY responder message the data receiver
sets D_t = t_s - t_r + S, where S is an estimated bound on the sets D_t = t_s - t_r + S, where S is an estimated bound on the
clock drift throughout the duration of the session. clock drift throughout the duration of the session.
This approach has the advantage that it does not require an This approach has the advantage that it does not require an
additional time synchronization protocol. The disadvantage is additional time synchronization protocol. The disadvantage is
the necessity to perform a full MIKEY handshake, to enable the necessity to perform a full MIKEY handshake, to enable
correct parameter transport. Moreover this approach is direction correct parameter transport. Moreover this approach is direction
dependent, as it may only be applied if the media receiver is dependent, as it may only be applied if the media receiver is
also the MIKEY initiator. also the MIKEY initiator.
Therefore, in scenarios, where the media receiver is also the Out-of-band synchronization using NTP (i.e., alternative 1) is the
MIKEY initiator, alternative 2, piggybacking timestamp RECOMMENDED approach for clock synchronization. In scenarios where
information in MIKEY, MAY be chosen, while in any other case NTP the media receiver is also the MIKEY initiator piggybacking timestamp
SHOULD be used (alternative 1). information in MIKEY (i.e., alternative 2) MAY be used to allow for
inband determination of the clock drift between sender and receiver.
4.4. Key data transport within MIKEY's General Extension Payload 4.4. Key data transport within MIKEY's General Extension Payload
The General Extensions Payload was defined to allow possible The General Extensions Payload was defined to allow possible
extensions to MIKEY without the need for defining a completely new extensions to MIKEY without the need for defining a completely new
payload each time. This payload can be used in any MIKEY message and payload each time. This payload can be used in any MIKEY message and
is part of the authenticated/signed data part. is part of the authenticated/signed data part.
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
skipping to change at page 11, line 12 skipping to change at page 11, line 24
TESLA SRTP mapping [I-D.ietf-msec-srtp-tesla] and SRTP [RFC3711] TESLA SRTP mapping [I-D.ietf-msec-srtp-tesla] and SRTP [RFC3711]
itself are relevant in this context. itself are relevant in this context.
Furthermore, since this document details bootstrapping of TESLA using Furthermore, since this document details bootstrapping of TESLA using
the Multimedia Internet Keying (MIKEY) [RFC3830] protocol the the Multimedia Internet Keying (MIKEY) [RFC3830] protocol the
security considerations of MIKEY are applicable to this document. security considerations of MIKEY are applicable to this document.
As a summary, in order for a multi-media application to support TESLA As a summary, in order for a multi-media application to support TESLA
the following protocol interactions (in relationship to this document the following protocol interactions (in relationship to this document
are necessary): are necessary):
o MIKEY [RFC3830] is executed between the desired entities to o MIKEY [RFC3830] is executed between the desired entities to
perform authentication and a secure distribution of keying perform authentication and a secure distribution of keying
material. In order to subsequently use TESLA the parameters material. In order to subsequently use TESLA the parameters
described in this document are distributed using MIKEY. MIKEY described in this document are distributed using MIKEY. MIKEY
itself uses another protocol for parameter transport, namely SDP, itself uses another protocol for parameter transport, namely the
that might again be used within SIP to setup a session between the Session Description Protocol (SDP, [RFC2327]), that might again be
desired entities. used within Session Initiation Protocol (SIP, [RFC3261]) to setup
a session between the desired entities.
o After the algorithms, parameters and the session keys are o After the algorithms, parameters and the session keys are
available at the respective communication entities data traffic available at the respective communication entities data traffic
protection via SRTP-TESLA [I-D.ietf-msec-srtp-tesla] can be used. protection via SRTP-TESLA [I-D.ietf-msec-srtp-tesla] can be used.
SRTP-TESLA itself applies TESLA to the SRTP protocol and as such SRTP-TESLA itself applies TESLA to the SRTP protocol and as such
the processing guidelines of TESLA need to be followed. the processing guidelines of TESLA need to be followed.
5.1. MitM Attack 5.1. Man-in-the-Middle (MitM) Attack
Threat: Threat:
The exchange of security related parameters and algorithms without The exchange of security related parameters and algorithms without
proper authentication can allow an adversary to perform a man-in- mutual authentication of the two peers can allow an adversary to
the-middle attack. The mechanisms described in this document do perform a man-in-the-middle attack. The mechanisms described in
not itself provide such an authentication and integrity this document do not itself provide such an authentication and
protection. integrity protection.
Countermeasures: Countermeasures:
Throughout the document it is assumed that the parameter exchange Throughout the document it is assumed that the parameter exchange
is secured using another protocol, i.e., the exchange parameters is secured using another protocol, i.e., the exchange parameters
and algorithms are part of a authentication and key exchange and algorithms are part of a authentication and key exchange
protocol, namely MIKEY. Source authentication of group and protocol, namely MIKEY. Source authentication of group and
multicast communication cannot be provided for the data traffic if multicast communication cannot be provided for the data traffic if
the prior signaling exchange did not provide facilities to the prior signaling exchange did not provide facilities to
authenticate the source. Using an authentication protocol that authenticate the source. Using an authentication protocol that
does not provide session keys as part of a successful protocol run does not provide session keys as part of a successful protocol
it is not possible to derive the necessary parameters required by exchange will make it impossible to derive the necessary
TESLA. MIKEY provides session key establishment. Additionally, parameters required by TESLA. MIKEY provides session key
the exchange of parameters and algorithms MUST be authenticated establishment. Additionally, the exchange of parameters and
and integrity protected. The security protection of the parameter algorithms MUST be authenticated and integrity protected. The
exchange needs to provide the same level or a higher level of security protection of the parameter exchange needs to provide the
security. same level or a higher level of security.
5.2. Downgrading Attack 5.2. Downgrading Attack
Threat: Threat:
The exchange of security-related parameters and algorithms is The exchange of security-related parameters and algorithms is
always subject to downgrading whereby an adversary modifies some always subject to downgrading whereby an adversary modifies some
(or all) of the provided parameters. For example, a few (or all) of the provided parameters. For example, a few
parameters require that a supported hash algorithm is listed. To parameters require that a supported hash algorithm is listed. To
mount an attack the adversary has to modify the list of provided mount an attack the adversary has to modify the list of provided
algorithms and to select the weakest one. algorithms and to select the weakest one.
Countermeasures: Countermeasures:
The parameter exchange provided in this document MUST be integrity TESLA parameter bootstrapping MUST be integrity protected to
protected to prevent modification of fields and their values. prevent modification of the parameters and their values.
Moreover, since unmodified parameters from an unknown source are Moreover, since unmodified parameters from an unknown source are
not useful, authentication MUST be provided. This functionality not useful, authentication MUST be provided. This functionality
is not provided by mechanisms described in this document. Instead is not provided by mechanisms described in this document. Instead
the capabilities of the underlying authentication and key exchange the capabilities of the underlying authentication and key exchange
protocol (MIKEY) are reused for this purpose. protocol (MIKEY) are reused for this purpose.
5.3. Denial of Service Attack 5.3. Denial of Service Attack
Threat: Threat:
An adversary might want to modify parameters exchange between the An adversary might want to modify parameters exchange between the
communicating entities in order to establish different state communicating entities in order to establish different state
information at the respective communication entities. For information at the respective communication entities. For
example, an adversary might want to modify the key disclosure example, an adversary might want to modify the key disclosure
delay or the interval duration in order to discurpt the delay or the interval duration in order to disrupt the
communication at a later state since the TESLA algorithm assumes communication at a later state since the TESLA algorithm assumes
that the participating communication entities know the same that the participating communication entities know the same
parameter set. parameter set.
Countermeasures: Countermeasures:
The exchanged parameters and the parameters and algorithms MUST be The exchanged parameters and the parameters and algorithms MUST be
integrity protected to allow the recipient to detect whether an integrity protected to allow the recipient to detect whether an
adversary attempted to modify the exchanged information. adversary attempted to modify the exchanged information.
Authentication and key exchange algorithms provided by MIKEY offer Authentication and key exchange algorithms provided by MIKEY offer
skipping to change at page 13, line 34 skipping to change at page 13, line 47
parameters. parameters.
5.5. Traffic Analysis 5.5. Traffic Analysis
Threat: Threat:
An adversary might be able to learn parameters and algorithms, if An adversary might be able to learn parameters and algorithms, if
located along the signaling path. This information can then later located along the signaling path. This information can then later
be used to mount attacks against the end-to-end multi-media be used to mount attacks against the end-to-end multi-media
communication. In some high-security and military environments it communication. In some high-security and military environments it
might even be desireable not to reveal information about the used might even be desirable not to reveal information about the used
parameters to make it more difficult to launch an attack. parameters to make it more difficult to launch an attack.
Countermeasures: Countermeasures:
Confidentity protection can be provided by a subset of the Confidentity protection can be provided by a subset of the
available MIKEY authentication and key exchange protocols, namely available MIKEY authentication and key exchange protocols, namely
those providing public key encryption and symmetric key those providing public key encryption and symmetric key
encryption. The initial hash key, which is also one of the TESLA encryption. The initial hash key, which is also one of the TESLA
bootstrapping parameters, does not require confidentiality bootstrapping parameters, does not require confidentiality
protection due to the properties of a hash chain. protection due to the properties of a hash chain.
6. IANA Considerations 6. IANA Considerations
This document requires an IANA registration for the following This document requires an IANA registration for the following
attributes: attributes. The registries are provided by MIKEY [RFC3830].
Prot Type: Prot Type:
This attribute specifies the protocol type for the security This attribute specifies the protocol type for the security
protocol as described in Section 4.1. protocol as described in Section 4.1.
Pseudo-random Function (PRF) used in the TESLA policy:
This attribute specifies values for pseudo-random functions used
in the the TESLA policy (see Section 4.2).
MAC Function used in TESLA:
This attribute specifies values for pseudo-random functions used
in the the TESLA policy (see Section 4.2).
Type: Type:
Identifies the type of the general payload. The General Identifies the type of the general payload. The General
Extensions Payload was defined to allow possible extensions to Extensions Payload was defined to allow possible extensions to
MIKEY without the need for defining a completely new payload each MIKEY without the need for defining a completely new payload each
time. Section 4.4 describes this attribute in more detail. time. Section 4.4 describes this attribute in more detail.
Following the policies outline in [RFC2434] the values in the range Following the policies outlined in [RFC3830] the values in the range
up to 240 (including 240) for the above attributes are assigned after up to 240 (including 240) for the above attributes are assigned after
Expert Review by the MSEC working group or its designated successor. Expert Review by the MSEC working group or its designated successor.
The values in the range from 241 to 255 are reserved for Private Use. The values in the range from 241 to 255 are reserved for Private Use.
IANA needs to register the following attributes and their respective IANA needs to add the following attributes and their respective
values: values to an existing registry created in [RFC3830]:
Prot Type: Prot Type:
Prot Type | Value | Description Prot Type | Value | Description
----------------------------------------------------- -----------------------------------------------------
TESLA | 1 | TESLA as a security protocol TESLA | 1 | TESLA as a security protocol
PRF: The value of 1 for the 'Prot Type' must be added to the 'Prot
type' registry created by [RFC3830].
PRF Function | Value Type:
--------------------------
HMAC-SHA1 | 0
MAC: Type | Value | Description
-------------------------------------------
TESLA I-Key | 2 | TESLA initial key
MAC Function | Value The value of 2 for the 'Type' must be added to the 'Type' registry
created by [RFC3830]. The values of 0 and 1 are already
registered in [RFC3830].
Furthermore, this document requires IANA to create two new
registries:
TESLA-PRF: Pseudo-random Function (PRF) used in the TESLA policy:
This attribute specifies values for pseudo-random functions used
in the the TESLA policy (see Section 4.2).
TESLA-MAC: MAC Function used in TESLA:
This attribute specifies values for pseudo-random functions used
in the the TESLA policy (see Section 4.2).
Following the policies outlined in [RFC2434] the values for the
TESLA-PRF and the TESLA-MAC registry in the range up to 240
(including 240) for the above attributes are assigned after Expert
Review by the MSEC working group or its designated successor. The
values in the range from 241 to 255 are reserved for Private Use.
IANA is requested to add the following values to the TESLA-PRF and
the TESLA-MAC registry:
TESLA-PRF:
PRF Function | Value
-------------------------- --------------------------
HMAC-SHA1 | 0 HMAC-SHA1 | 0
Type: TESLA-MAC:
Type | Value | Description
-------------------------------------------
TESLA I-Key | 2 | TESLA initial key
The values of 0 and 1 are already registered. MAC Function | Value
--------------------------
HMAC-SHA1 | 0
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Mark Baugher and Ran Canetti for the The authors would like to thank Mark Baugher and Ran Canetti for the
discussions in context of time synchronization. Additionally, we discussions in context of time synchronization. Additionally, we
would like to thank Lakshminath Dondeti, Russ Housley and Allison would like to thank Lakshminath Dondeti, Russ Housley and Allison
Mankin for their document reviews and for their guidance. Mankin for their document reviews and for their guidance.
8. References 8. References
skipping to change at page 16, line 4 skipping to change at page 16, line 34
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005. Transform Introduction", RFC 4082, June 2005.
8.2. Informative References 8.2. Informative References
[I-D.ietf-msec-mikey-dhhmac] [I-D.ietf-msec-mikey-dhhmac]
Euchner, M., "HMAC-authenticated Diffie-Hellman for Euchner, M., "HMAC-authenticated Diffie-Hellman for
MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in
progress), April 2005. progress), April 2005.
[I-D.ietf-msec-mikey-rsa-r] [I-D.ietf-msec-mikey-rsa-r]
Ignjatic, D., "An additional mode of key distribution in Ignjatic, D., "An additional mode of key distribution in
MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-00 (work MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-01 (work
in progress), July 2005. in progress), October 2005.
[PCST] Perrig, A., Canetti, R., Song, D., and D. Tygar, [PCST] Perrig, A., Canetti, R., Song, D., and D. Tygar,
""Efficient and Secure Source Authentication for ""Efficient and Secure Source Authentication for
Multicast", in Proc. of Network and Distributed System Multicast", in Proc. of Network and Distributed System
Security Symposium NDSS 2001, pp. 35-46", 2001. 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, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
Authors' Addresses Authors' Addresses
Steffen Fries Steffen Fries
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
skipping to change at page 18, line 41 skipping to change at page 19, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 51 change blocks. 
124 lines changed or deleted 176 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/