MSEC S. Fries Internet-Draft H. Tschofenig Expires: April 17, 2006 Siemens October 14, 2005 Bootstrapping TESLA draft-ietf-msec-bootstrapping-tesla-02.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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 17, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol is a protocol for providing source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead, which scales to large numbers of receivers, and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using MAC chaining. The use of TESLA within the Secure Real-time Transport Protocol Fries & Tschofenig Expires April 17, 2006 [Page 1] Internet-Draft Bootstrapping TESLA October 2005 (SRTP) has been published targeting multicast authentication in scenarios, where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms. This document specifies MIKEY payloads for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast or broadcast. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. TESLA Parameter Overview . . . . . . . . . . . . . . . . . . . 4 4. Parameter encoding within MIKEY . . . . . . . . . . . . . . . 5 4.1. Security Policy payload (SP) . . . . . . . . . . . . . . . 6 4.2. TESLA policy . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Time synchronization . . . . . . . . . . . . . . . . . . . 8 4.4. Key data transport within MIKEY's General Extension Payload . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.1. MitM Attack . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Downgrading Attack . . . . . . . . . . . . . . . . . . . . 12 5.3. Denial of Service Attack . . . . . . . . . . . . . . . . . 12 5.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Fries & Tschofenig Expires April 17, 2006 [Page 2] Internet-Draft Bootstrapping TESLA October 2005 1. Introduction In many multicast, broadcast, and also unicast communication scenarios it is necessary to guarantee that a recieved message has been sent from a dedicated source and has not been altered while in transfer. In unicast communication commonly a pairwise security association exists, which enables the validation of message integrity and data origin. The approach in group based communication is different as here a key is normally shared between the members of a group and thus this key may not be used for data origin authentication. As in some applications a dedicated identification of a sender is required, there exists the requirement to support data origin authentication also in multicast scenarios. One of the methods supporting this is TESLA [RFC4082]. TESLA provides source authentication in multicast scenarios by using MAC chaining. It is based on loose time synchronization between the sender and the receivers. [I-D.ietf-msec-srtp-tesla] describes extensions for SRTP [RFC3711] in order to support TESLA [RFC4082] for source authentication in multicast scenarios. SRTP needs dedicated cryptographic context describing the security paramter and security policy per multimedia session to be protected. This cryptographic context needs to be enhanced with a set of TESLA parameters. It is necessary to provide these parameters before the actual multicast session starts. [I-D.ietf-msec-srtp-tesla] does not address the bootstrapping for these parameters. This document details bootstrapping of TESLA parameters in terms of parameter distribution for TESLA policy as well as the initial key, using the Multimedia Internet Keying (MIKEY) [RFC3830] protocol. MIKEY defines an authentication and key management framework that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, [RFC3830] is defined in a way to support SRTP in the first place but is open to enhancements to be used for other purposes too. Following the description in RFC 3830 [RFC3830] MIKEY is targeted for point-to- point as well as for group communication. In the context of group communication an administrator entity can distribute session keys to the associated entities participating in the communication session. This scenario is also applicable for TESLA where one entity may provide information to many others in a way that the integrity of the communicated information can be assured. The combination of MIKEY and TESLA supports this group-based approach by utilizing the MIKEY framework to distribute TESLA parameter information to all involved entities. Note that this document does only focus on the distribution of the parameters, not on the generation. Fries & Tschofenig Expires April 17, 2006 [Page 3] Internet-Draft Bootstrapping TESLA October 2005 MIKEY [RFC3830] itself describes three authentication and key exchange protocols (symmetric key enryption, public key encryption, and signed Diffie Hellman) Extensions to the MIKEY key exchange methods have been defined. A fourth key distribution method is provided by [I-D.ietf-msec-mikey-dhhmac] and describes a symetrically protected Diffie Hellman key agreement. Recently a further option has been proposed in [I-D.ietf-msec-mikey-rsa-r] describing an enhanced asymmetric exchange variant, supporting also inband certificate exchange. All of the different key management schemens mentioned above may be used to provide the TESLA parameters. The required TESLA parameters to be exchanged are already described in [I-D.ietf-msec-srtp-tesla], while this document describes their transport within MIKEY. The following security requirements have to be placed on the exchange of TESLA parameters: o Authentication and Integrity MUST be provided when sending the TESLA parameters, especially for the initial key. o Confidentiality MAY be provided for the TESLA parameters These security requirements apply to the TESLA bootstrapping procedure only. Security requirements for applications using TESLA are beyond the scope of this document. Security aspects that relate to TESLA itself are described in [RFC4082] and security issues for TESLA usage for SRTP is covered in [I-D.ietf-msec-srtp-tesla]. 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 as described in [I-D.ietf-msec-srtp-tesla] then (a) keying material is required and (b) parameters for TESLA. This document contributes the parameters and the authentication methods used in MIKEY to provide the keying material. The parameter exchange for TESLA also needs to be secured against tampering. This protection is provided also by MIKEY. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. TESLA Parameter Overview According to [I-D.ietf-msec-srtp-tesla] the following transform 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]: Fries & Tschofenig Expires April 17, 2006 [Page 4] Internet-Draft Bootstrapping TESLA October 2005 1. An identifier for the 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 (dafault HMAC- SHA1). 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 disclosed in an SRTP packet if TESLA is used in the SRTP context) (dafault 160 bit). 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 keys in the chain), e.g. to indicate a keyed hashing function (default HMAC-SHA1). 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 bit). 5. An identifier for the TESLA MAC, that accepts the output of F'(x) as its key, e.g. to indicate a keyed hashing function (default HMAC-SHA1). 6. A non-negative integer, determining the length of the output of the TESLA MAC (default 80 bit). 7. The beginning of the session for which a key will be applied. 8. The interval duration (in milliseconds), for which a dedicated key will be used. 9. The key disclosure delay (in number of intervals), characterizes the period after which the key will be sent to the involved entities (e.g., as part of SRTP packets). 10. Non-negative integer, determining the length of the key chain, which is determined based up the expected duration of the stream. 11. The initial key of the chain to which the sender has committed 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 Fries & Tschofenig Expires April 17, 2006 [Page 5] Internet-Draft Bootstrapping TESLA October 2005 As mentioned in Section 3, TESLA parameters need to be transported before actually starting a session. MIKEY currently only defines a payload for transporting the SRTP policy (see Section 6.10 of [RFC3830]). This section describes the enhancement of MIKEY to allow the transport of a TESLA policy and additionally the initial TESLA key. 4.1. Security Policy payload (SP) The Security Policy payload defines a set of policies that apply to a specific security protocol. The definition here relies on the security policy payload definition in [RFC3830]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Policy no ! Prot type ! Policy param ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ length (cont) ! Policy param ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload (8 bits): Identifies the payload that is added after this payload. See Section 6.1 of [RFC3830] for more details. * Policy no (8 bits): Each security policy payload must be given a distinct number for the current MIKEY session by the local peer. This number is used to map a cryptographic session to a specific policy (see also Section 6.1.1 of [RFC3830]). * Prot type (8 bits): This value defines the security protocol. A second value needs to be defined as shown below: (MIKEY already defines the value 0.) Prot type | Value | --------------------------- SRTP | 0 | TESLA | 1 | Fries & Tschofenig Expires April 17, 2006 [Page 6] Internet-Draft Bootstrapping TESLA October 2005 * Policy param length (16 bits): This field defines the total length of the policy parameters for the selected security protocol. * Policy param (variable length): This field defines the policy for the specific security protocol. The Policy param part is built up by a set of Type/Length/Value (TLV) payloads. For each security protocol, a set of possible type/value pairs can be negotiated as defined. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type ! Length ! Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Type (8 bits): Specifies the type of the parameter. * Length (8 bits): Specifies the length of the Value field (in bytes). * Value (variable length): Specifies the value of the parameter. 4.2. TESLA policy This policy specifies the parameters for TESLA. The types/values that can be negotiated are defined by the following table. The concrete default values are taken from [I-D.ietf-msec-srtp-tesla], but other values may also be used: Fries & Tschofenig Expires April 17, 2006 [Page 7] Internet-Draft Bootstrapping TESLA October 2005 Type | Meaning | Possible values --------------------------------------------------------------- 1 | PRF identifier for f, realising F(x) | see below 2 | Length of PRF f output | 160 3 | PRF identifier for f', realising F'(x) | see below 4 | Length of PRF f' output | 160 5 | Identifier for the TESLA MAC | see below 6 | Length of TESLA MAC output | 80 (truncated) 7 | Start of session | in bytes 8 | Interval duration (in msec) | in bytes 9 | Key disclosure delay | in bytes 10| Key chain length (numer of intervals) | in bytes 11| local timestamp media receiver | see below For the PRF realising F(x), a one byte length is sufficient. The currently defined possible values are: TESLA PRF F(x) | Value ----------------------- HMAC-SHA1 | 0 For the PRF realising F'(x), a one byte length is enough. The currently defined possible values are: TESLA PRF F'(x) | Value ----------------------- HMAC-SHA1 | 0 For the TESLA MAC, a one byte length is enough. The currently defined possible values are: TESLA MAC | Value ----------------------- HMAC-SHA1 | 0 4.3. Time synchronization MIKEY as well as TESLA require the time synchronization of the communicating peers. MIKEY requires time sychronization to provide timestamp-based replay protection for the one-roundtrip authentication and key exchange protocols. TESLA, on the other hand, needs this information to determine the clock drift between the senders and the receivers in order to appropriately release the disclosed key. Two alternatives are available for time synchronization: Fries & Tschofenig Expires April 17, 2006 [Page 8] Internet-Draft Bootstrapping TESLA October 2005 1. Usage of out-of-band synchronization using NTP [RFC1305]. This approach is already recommended within [RFC3830]. The advantage of this approach is the option to use the MIKEY key management variants that perform within a half-roundtrip. The disadvantage is the required time synchronization via an additional protocol. 2. [RFC4082] also sketches a possible inband synchronization in Section 3.3.1. This approach is shortly repeated here in the context of MIKEY. Note, that here the actual TESLA policy payload is transmitted as part of the MIKEY responder message. * The data receiver, which would be the MIKEY initiator sets the 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 stored locally. * Upon receipt of the MIKEY initiator message the data sender replies with the MIKEY responder message, setting the local time stamp at data receiver (parameter 11) to the value t_r received in the MIKEY initiator message and sets his local time as 64 bit UTC value t_s in the timestamp payload as described in [RFC3830]. MIKEY initiator message [MIKEY parameter incl. local timestamp (t_r)] ------------------> MIKEY responder message [MIKEY parameter incl. local timestamp (t_s), TESLA policy payload, received local time stamp t_r] <------------------ * 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 clock drift throughout the duration of the session. This approach has the advantage that it does not require an additional time synchronization protocol. The disadvantage is the necessity to perform a full MIKEY handshake, to enable correct parameter transport. Moreover this approach is direction dependent, as it may only be applied if the media receiver is also the MIKEY initiator. Therefore, in scenarios, where the media receiver is also the MIKEY initiator, alternative 2, piggybacking timestamp information in MIKEY, MAY be chosen, while in any other case NTP SHOULD be used (alternative 1). 4.4. Key data transport within MIKEY's General Extension Payload The General Extensions Payload was defined to allow possible extensions to MIKEY without the need for defining a completely new Fries & Tschofenig Expires April 17, 2006 [Page 9] Internet-Draft Bootstrapping TESLA October 2005 payload each time. This payload can be used in any MIKEY message and is part of the authenticated/signed data part. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Type ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Next payload (8 bits): Identifies the payload following this payload. * Type (8 bits): Identifies the type of general payload. MIKEY already defines the Values 0 and 1. This document introduces a new value (2). Type | Value | Comments ---------------------------------------------------- Vendor ID | 0 | Vendor specific byte string SDP IDs | 1 | List of SDP key mgmt IDs TESLA I-Key | 2 | TESLA initial key * Length (16 bits): The length in bytes of the Data field. * Data (variable length): The general payload data. 5. Security Considerations The security properties of multi-media data in a multicast environment depends on a number of building blocks. SRTP-TESLA [I-D.ietf-msec-srtp-tesla] describes extensions for SRTP [RFC3711] in order to support TESLA [RFC4082] for source authentication in multicast scenarios. As such, security considerations described with TESLA (see [PCST] and [RFC4082]), the TESLA SRTP mapping [I-D.ietf-msec-srtp-tesla] and SRTP [RFC3711] itself are relevant in this context. Fries & Tschofenig Expires April 17, 2006 [Page 10] Internet-Draft Bootstrapping TESLA October 2005 Furthermore, since this document details bootstrapping of TESLA using the Multimedia Internet Keying (MIKEY) [RFC3830] protocol the security considerations of MIKEY are applicable to this document. As a summary, in order for a multi-media application to support TESLA the following protocol interactions (in relationship to this document are necessary): o MIKEY [RFC3830] is executed between the desired entities to perform authentication and a secure distribution of keying material. In order to subsequently use TESLA the parameters described in this document are distributed using MIKEY. MIKEY itself uses another protocol for parameter transport, namely SDP, that might again be used within SIP to setup a session between the desired entities. o After the algorithms, parameters and the session keys are available at the respective communication entities data traffic 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 the processing guidelines of TESLA need to be followed. 5.1. MitM Attack Threat: The exchange of security related parameters and algorithms without proper authentication can allow an adversary to perform a man-in- the-middle attack. The mechanisms described in this document do not itself provide such an authentication and integrity protection. Countermeasures: Throughout the document it is assumed that the parameter exchange is secured using another protocol, i.e., the exchange parameters and algorithms are part of a authentication and key exchange protocol, namely MIKEY. Source authentication of group and multicast communication cannot be provided for the data traffic if the prior signaling exchange did not provide facilities to authenticate the source. Using an authentication protocol that does not provide session keys as part of a successful protocol run it is not possible to derive the necessary parameters required by TESLA. MIKEY provides session key establishment. Additionally, the exchange of parameters and algorithms MUST be authenticated and integrity protected. The security protection of the parameter exchange needs to provide the same level or a higher level of security. Fries & Tschofenig Expires April 17, 2006 [Page 11] Internet-Draft Bootstrapping TESLA October 2005 5.2. Downgrading Attack Threat: The exchange of security-related parameters and algorithms is always subject to downgrading whereby an adversary modifies some (or all) of the provided parameters. For example, a few parameters require that a supported hash algorithm is listed. To mount an attack the adversary has to modify the list of provided algorithms and to select the weakest one. Countermeasures: The parameter exchange provided in this document MUST be integrity protected to prevent modification of fields and their values. Moreover, since unmodified parameters from an unknown source are not useful, authentication MUST be provided. This functionality is not provided by mechanisms described in this document. Instead the capabilities of the underlying authentication and key exchange protocol (MIKEY) are reused for this purpose. 5.3. Denial of Service Attack Threat: An adversary might want to modify parameters exchange between the communicating entities in order to establish different state information at the respective communication entities. For example, an adversary might want to modify the key disclosure delay or the interval duration in order to discurpt the communication at a later state since the TESLA algorithm assumes that the participating communication entities know the same parameter set. Countermeasures: The exchanged parameters and the parameters and algorithms MUST be integrity protected to allow the recipient to detect whether an adversary attempted to modify the exchanged information. Authentication and key exchange algorithms provided by MIKEY offer this protection. 5.4. Replay Attack Fries & Tschofenig Expires April 17, 2006 [Page 12] Internet-Draft Bootstrapping TESLA October 2005 Threat: An adversary who is able to eavesdrop one or multiple protocol exchanges (MIKEY exchanges with the parameters described in this document) might be able to replay the payloads in a later protocol exchange. If the recipients accept the parameters and algorithms (or even the messages that carry these payloads as well then a Denial of Service, downgrading or a man-in-the-middle attack might be the consequence (depending on the entire set of replayed attributes and messages). Countermeasures: In order to prevent replay attacks a freshness guarantee MUST be provided. As such, the TESLA bootstrapping message exchange MUST be unique and fresh and the corresponding authentication and key exchange protocol MUST provide the same properties. In fact, it is essential to derive a unique and fresh session key as part of the authentication and key exchange protocol run that MUST be bound to the protocol session. This includes the exchanged parameters. 5.5. Traffic Analysis Threat: An adversary might be able to learn parameters and algorithms, if located along the signaling path. This information can then later be used to mount attacks against the end-to-end multi-media communication. In some high-security and military environments it might even be desireable not to reveal information about the used parameters to make it more difficult to launch an attack. Countermeasures: Confidentity protection can be provided by a subset of the available MIKEY authentication and key exchange protocols, namely those providing public key encryption and symmetric key encryption. The initial hash key, which is also one of the TESLA bootstrapping parameters, does not require confidentiality protection due to the properties of a hash chain. 6. IANA Considerations This document requires an IANA registration for the following attributes: Fries & Tschofenig Expires April 17, 2006 [Page 13] Internet-Draft Bootstrapping TESLA October 2005 Prot Type: This attribute specifies the protocol type for the security 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: Identifies the type of the general payload. The General Extensions Payload was defined to allow possible extensions to MIKEY without the need for defining a completely new payload each time. Section 4.4 describes this attribute in more detail. Following the policies outline in [RFC2434] the values 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 needs to register the following attributes and their respective values: Prot Type: Prot Type | Value | Description ----------------------------------------------------- TESLA | 1 | TESLA as a security protocol PRF: PRF Function | Value -------------------------- HMAC-SHA1 | 0 Fries & Tschofenig Expires April 17, 2006 [Page 14] Internet-Draft Bootstrapping TESLA October 2005 MAC: MAC Function | Value -------------------------- HMAC-SHA1 | 0 Type: Type | Value | Description ------------------------------------------- TESLA I-Key | 2 | TESLA initial key The values of 0 and 1 are already registered. 7. Acknowledgments The authors would like to thank Mark Baugher and Ran Canetti for the discussions in context of time synchronization. Additionally, we would like to thank Lakshminath Dondeti, Russ Housley and Allison Mankin for their document reviews and for their guidance. 8. References 8.1. Normative References [I-D.ietf-msec-srtp-tesla] Carrara, E. and M. Baugher, "The Use of TESLA in SRTP", draft-ietf-msec-srtp-tesla-05 (work in progress), October 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Fries & Tschofenig Expires April 17, 2006 [Page 15] Internet-Draft Bootstrapping TESLA October 2005 Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005. 8.2. Informative References [I-D.ietf-msec-mikey-dhhmac] Euchner, M., "HMAC-authenticated Diffie-Hellman for MIKEY", draft-ietf-msec-mikey-dhhmac-11 (work in progress), April 2005. [I-D.ietf-msec-mikey-rsa-r] Ignjatic, D., "An additional mode of key distribution in MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-00 (work in progress), July 2005. [PCST] Perrig, A., Canetti, R., Song, D., and D. Tygar, ""Efficient and Secure Source Authentication for Multicast", in Proc. of Network and Distributed System Security Symposium NDSS 2001, pp. 35-46", 2001. [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. Fries & Tschofenig Expires April 17, 2006 [Page 16] Internet-Draft Bootstrapping TESLA October 2005 Authors' Addresses Steffen Fries Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: steffen.fries@siemens.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com Fries & Tschofenig Expires April 17, 2006 [Page 17] Internet-Draft Bootstrapping TESLA October 2005 Intellectual Property Statement 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. Disclaimer of Validity This document and the information contained herein are provided on an "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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Fries & Tschofenig Expires April 17, 2006 [Page 18]