RFC 4442

Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)

📅 published March 2006, from ietf

Bootstrapping TESLA, aka RFC 4442 💖

Network Working Group 🎀 Request for Comments: 4442 Authors: S. Fries and H. Tschofenig (both from Siemens) ✨ Category: Standards Track 🦋 Date: March 2006 🌸 Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🫶

Okay bestie, the title is Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA) 💅 It's a Standards Track doc, so it's an actual spec people implement, not just a vibe.

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌈

Copyright (C) The Internet Society (2006).

Abstract 💜

Okay so TESLA (the Timed Efficient Stream Loss-tolerant Authentication protocol) handles source authentication in multicast 🔥 It's super efficient, with low communication and computation overhead, it scales to huge numbers of receivers, and it's totally fine with packet loss. It's based on loose time synchronization between sender and receivers ⏰ Source authentication happens through Message Authentication Code (MAC) chaining 🔗 TESLA has already been published for use inside the Secure Real-time Transport Protocol (SRTP), aimed at multicast authentication when SRTP is protecting multimedia data. That solution assumes the TESLA parameters arrive through out-of-band mechanisms 🫠

This doc is all about payloads for the Multimedia Internet Keying (MIKEY) protocol that bootstrap TESLA for source authentication in secure group communications using SRTP 🧚 TESLA can be bootstrapped with any of the MIKEY key management approaches. For example, you can send a digitally signed MIKEY message by unicast, multicast, or broadcast 📡

Table of Contents 🍓

   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. TESLA Parameter Overview ........................................4
   4. Parameter Encoding within MIKEY .................................6
      4.1. Security Policy (SP) Payload ...............................6
      4.2. TESLA Policy ...............................................7
      4.3. Time Synchronization .......................................8
      4.4. Key Data Transport within MIKEY's General
           Extension Payload .........................................10
   5. Security Considerations ........................................11
      5.1. Man-in-the-Middle Attack ..................................11
      5.2. Downgrading Attack ........................................12
      5.3. Denial of Service Attack ..................................12
      5.4. Replay Attack .............................................13
      5.5. Traffic Analysis ..........................................13
   6. IANA Considerations ............................................14
   7. Acknowledgements ...............................................15
   8. References .....................................................16
      8.1. Normative References ......................................16
      8.2. Informative References ....................................16

1. Introduction ✨

Okay so in lots of multicast, broadcast, and unicast setups, you need to be sure a message really came from a specific source and wasn't changed on the way 👀 In unicast, there's usually a pairwise security association that lets you check message integrity and data origin 💅 Group communication is different. A key is normally shared across all the members of a group, so that key can't be used for data origin authentication 😭 Some applications need to know exactly who the sender is, so there's a real requirement for data origin authentication in multicast too. TESLA [RFC4082] is one method that supports this. It provides source authentication in multicast through MAC chaining, and it's based on loose time synchronization between sender and receivers 🔥

[RFC4383] describes extensions for SRTP [RFC3711] so that it can support TESLA [RFC4082] for source authentication in multicast. SRTP needs a dedicated cryptographic context per multimedia session, describing the security parameters and security policy for that session. That context has to be extended with a set of TESLA parameters, and those parameters must be provided before the actual multicast session starts 🎀 [RFC4383] doesn't cover how to bootstrap those parameters, which is the gap this doc fills 🧩

This document covers bootstrapping TESLA parameters. That means distributing the TESLA policy and the initial key, using the Multimedia Internet Keying (MIKEY) [RFC3830] protocol 🫶 MIKEY is an authentication and key management framework for real-time applications, both peer-to-peer and group communication. [RFC3830] was designed mainly to support SRTP, but it's open to enhancements for other uses too 🌸 Following [RFC3830], MIKEY targets point-to-point as well as group communication. In a group setting, an administrator entity can hand out session keys to the entities in the communication session. That fits TESLA nicely, since one entity can give information to many others while the integrity of that information is still assured. Combining MIKEY and TESLA means using the MIKEY framework to send TESLA parameter info to every entity involved 💜 Heads up: this document is only about distributing the parameters. It doesn't cover generating them 🙈

MIKEY [RFC3830] itself describes three authentication and key exchange protocols: symmetric key encryption, public key encryption, and signed Diffie-Hellman. There have been extensions to the MIKEY key exchange methods too. A fourth key distribution method is in [DHHMAC], which describes a symmetrically protected Diffie-Hellman key agreement. There's also [RSA-R], an enhanced asymmetric exchange variant that supports inband certificate exchange 🍓 Any of the key management schemes above can be used to deliver the TESLA parameters. The required TESLA parameters are already described in [RFC4383], and this document describes how they get transported inside MIKEY 🧚

Here are the security requirements for exchanging TESLA parameters:

  • Authentication and Integrity MUST be provided when sending the TESLA parameters, especially for the initial key. 🔐
  • Confidentiality MAY be provided for the TESLA parameters. 🫧

These requirements only apply to the TESLA bootstrapping procedure. Security requirements for applications that use TESLA are out of scope for this document. Security aspects of TESLA itself are in [RFC4082], and security issues for TESLA usage with SRTP are covered in [RFC4383] 💅

One more thing: this document is one piece of a full solution 🧩 If media traffic is going to be secured with TESLA as described in [RFC4383], then you need both (a) keying material and (b) TESLA parameters. This document supplies the parameters, plus the MIKEY authentication methods used to provide the keying material. The TESLA parameter exchange also has to be protected against tampering, and MIKEY provides that protection too 🛡️

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 [RFC4383], a number of transform-dependent parameters have to be provided for TESLA to work properly. The complete list is in Section 4.3 of [RFC4383]. Parameter 10 of [RFC4383] (the lag of the receiver clock relative to the sender clock) is left out of this document, because it can be computed 🧮

MIKEY already requires synchronized clocks, and that also covers synchronization for TESLA ⏰ Section 4.3 also gives an option to use MIKEY for clock drift determination between sender and receiver. So this parameter doesn't need to be sent in MIKEY directly 💖

The bracketed info below gives the default values from Section 6.2 of [RFC4383] 🎀

  1. An identifier for the PRF (TESLA PRF), which implements the one-way function F(x) in TESLA (to derive the keys in the chain) and the one-way function F'(x) in TESLA (to derive the keys for the TESLA MAC from the keys in the chain). For example, it can indicate the keyed hash function (default HMAC-SHA1). 🔑
  2. A non-negative integer that sets the length of the F output, which is the length of the keys in the chain. It's also the key disclosed in an SRTP packet when TESLA is used in the SRTP context (default 160 bit). 📏
  3. A non-negative integer that sets the length of the output of F', which is the length of the key for the TESLA MAC (default 160 bit). 📐
  4. An identifier for the TESLA MAC that takes the output of F'(x) as its key. For example, it can indicate a keyed hashing function (default HMAC-SHA1). 🧾
  5. A non-negative integer that sets the length of the output of the TESLA MAC (default 80 bit). 🔢
  6. The start of the session that a key will be applied to. 🎬
  7. The interval duration (in milliseconds) that a dedicated key is used for. ⏳
  8. The key disclosure delay (in number of intervals). This is the period after which the key gets sent to the involved entities, for example as part of SRTP packets. 📬
  9. A non-negative integer that sets the length of the key chain, which is based on the expected duration of the stream 🎞️
  10. The initial key of the chain that the sender has committed to 🫶

4. Parameter Encoding within MIKEY 🧚

Like I said in Section 3, TESLA parameters need to be transported before a session actually starts 🕰️ Right now MIKEY only defines a payload for transporting the SRTP policy (see Section 6.10 of [RFC3830]). This section describes how MIKEY gets enhanced so it can carry a TESLA policy and also the initial TESLA key 🦋

4.1. Security Policy (SP) Payload ✨

Okay so the Security Policy payload is basically where you lay out a set of policies for one specific security protocol 💅 This bit leans on the security policy payload definition in [RFC3830], so go check that one too if you want the full picture 🎀

    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                                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the breakdown, bestie 🫶

  • Next payload (8 bits): This tells you which payload comes right after this one. See Section 6.1 of [RFC3830] for more details.
  • Policy no (8 bits): Every security policy payload needs its own distinct number for the current MIKEY session, and the local peer is the one who picks it 🔢 This number is what maps 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. MIKEY already defines the value 0, and a second value gets defined as shown below 🌈
Prot type     | Value |
---------------------------
SRTP          |     0 |
TESLA         |     1 |
  • Policy param length (16 bits): This field tells you the total length of the policy parameters for the selected security protocol 📏
  • Policy param (variable length): This field holds the policy for that specific security protocol 💜

The Policy param part is built up out of a bunch of Type/Length/Value (TLV) payloads. For each security protocol, there's a set of possible type/value pairs that can get 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 is where you specify the parameters for TESLA. The types and values that can be negotiated are defined by the table below. The concrete default values come from [RFC4383], but other values may also be used, so don't panic if you see something different 🌸

   Type | Meaning                                | Possible values
   ---------------------------------------------------------------
      1 | PRF identifier for f and f', realising | see below
          F(x) and F'(x)
      2 | Length of PRF f' output                | 160
      3 | Identifier for the TESLA MAC           | see below
      4 | Length of TESLA MAC output             | 80 (truncated)
      5 | Start of session                       | in bytes
      6 | Interval duration (in msec)            | in bytes
      7 | Key disclosure delay                   | in bytes
      8 | Key chain length (number of intervals) | in bytes
      9 | Local timestamp media receiver         | see below

Okay, now the time stuff 🕰️ The time values in items 5 and 9 SHALL be transported in NTP-UTC format, which is one of the three options described in Section 6.6 of [RFC3830]. A four-byte integer value for policy item 6 and a two-byte integer value for policy item 7 are RECOMMENDED, and those carry the interval duration and key disclosure delay respectively 💅 Policy type 9 is optional, and it SHOULD be used if the time synchronization described in Section 4.3, point two, is used. Otherwise, it SHOULD be omitted ⏰

For the PRF realizing F(x) and F'(x), a one-byte length is sufficient. The currently defined possible values are:

  TESLA PRF F(x), 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 ⏳

Okay this section is lowkey crucial. MIKEY and TESLA both need the communicating peers to be time synchronized 🕐 MIKEY needs it so it can do timestamp-based replay protection for its one-roundtrip authentication and key exchange protocols. TESLA needs it for a different reason: it uses this info to figure out the clock drift between the senders and the receivers, so it can release the disclosed key at the right moment 🔑 There are two alternatives for getting this done:

  1. Usage of out-of-band synchronization using NTP [RFC1305]. This approach is already recommended within [RFC3830]. The upside is that you get to use the MIKEY key management variants that perform within a half-roundtrip ⚡ The downside is that you need that time synchronization happening over an additional protocol.
  2. [RFC4082] also sketches a possible inband synchronization in Section 3.3.1. This approach is summarized 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. It sets the local time stamp at data receiver (parameter 11) to the value t_r received in the MIKEY initiator message, and it sets its local time as a 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 doesn't need an additional time synchronization protocol, which is so nice 🥰 The disadvantage is that you have to perform a full MIKEY handshake so the parameters get transported correctly. Moreover, this approach is direction dependent, since it may only be applied if the media receiver is also the MIKEY initiator 🙃

Out-of-band synchronization using NTP (i.e., alternative 1) is the RECOMMENDED approach for clock synchronization 🏆 In scenarios where the media receiver is also the MIKEY initiator, piggybacking timestamp 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 🎁

The General Extensions Payload was defined so MIKEY could take on extensions without someone having to invent a completely new payload every single time 🙌 This payload can be used in any MIKEY message, and it's 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, and 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 🔐

Real talk, this part matters a lot 😭 The security properties of multi-media data in a multicast environment depend on a number of building blocks.

SRTP-TESLA [RFC4383] describes extensions for SRTP [RFC3711] in order to support TESLA [RFC4082] for source authentication in multicast scenarios. As such, the security considerations described with TESLA (see [PCST] and [RFC4082]), the TESLA SRTP mapping [RFC4383], and SRTP [RFC3711] itself are all relevant in this context 🧠

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 too 🔑

As a summary, for a multi-media application to support TESLA, the following protocol interactions (in relationship to this document) are necessary 📋

  • 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, the Session Description Protocol (SDP) [RFC2327]. SDP might again be used within Session Initiation Protocol (SIP, [RFC3261]) to set up a session between the desired entities 📞
  • After the algorithms, parameters, and session keys are available at the respective communication entities, data traffic protection via SRTP-TESLA [RFC4383] 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. Man-in-the-Middle Attack 🕵️

Threat:

okay so this is the scary one 😭 If the two peers swap security-related parameters and algorithms without mutually authenticating each other, an adversary can pull off a man-in-the-middle attack. The mechanisms in this document don't provide that authentication and integrity protection on their own 🫶

Countermeasures:

the whole document assumes the parameter exchange is secured by another protocol. The parameters and algorithms ride along inside an authentication and key exchange protocol, namely MIKEY ✨ Source authentication for group and multicast traffic also can't happen if the earlier signaling never gave us a way to authenticate the source 💀 And if the authentication protocol doesn't hand out session keys as part of a successful exchange, it's impossible to derive the parameters TESLA needs. Luckily MIKEY does provide session key establishment 🔐 Finally, the exchange of parameters and algorithms MUST be authenticated and integrity protected, and its security protection needs to be the same level or higher 💅

5.2. Downgrading Attack 📉

Threat:

the parameter exchange is always open to downgrading, where an adversary changes some (or all) of the provided parameters 😈 For example, some parameters require that a supported hash algorithm be listed. So the attacker edits the list of algorithms and picks the weakest one. Rude!

Countermeasures:

TESLA parameter bootstrapping MUST be integrity protected so nobody can modify the parameters and their values 🛡️ And since unmodified parameters from an unknown source aren't useful, authentication MUST be provided too. The mechanisms in this document don't cover that part, so we borrow the capabilities of the underlying authentication and key exchange protocol (MIKEY) instead 🤝

5.3. Denial of Service Attack 🙅‍♀️

Threat:

an adversary might try to modify the parameters exchanged between the communicating entities so they end up with different state information 👀 For example, the attacker could mess with the key disclosure delay or the interval duration to disrupt the communication later on. That works because the TESLA algorithm assumes both participants know the same parameter set 💔

Countermeasures:

the exchanged parameters, and the parameters and algorithms, MUST be integrity protected so the recipient can detect whether an adversary tried to modify the exchanged information 🔍 Authentication and key exchange algorithms provided by MIKEY offer this protection ✨

5.4. Replay Attack 🔁

Threat:

an adversary who can eavesdrop on one or multiple protocol exchanges (MIKEY exchanges carrying the parameters described in this document) might be able to replay the payloads in a later exchange 😬 If the recipients accept the parameters and algorithms (or even the messages carrying these payloads), the result could be a denial of service, a downgrading attack, or a man-in-the-middle attack. It depends on the full set of replayed attributes and messages, so it's a whole vibe 🌀

Countermeasures:

to stop replay attacks, a freshness guarantee MUST be provided 🍓 That means the TESLA bootstrapping message exchange MUST be unique and fresh, and the corresponding authentication and key exchange protocol MUST provide the same properties. Honestly, it's essential to derive a unique and fresh session key as part of the authentication and key exchange protocol run, and that session key 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 they're sitting somewhere along the signaling path 🧐 That info can then be used later to mount attacks against the end-to-end multimedia communication. In some high-security and military environments, it might even be desirable to not reveal anything about the parameters used, so the attack is harder to pull off 🪖

Countermeasures:

confidentiality protection can be provided by a subset of the available MIKEY authentication and key exchange protocols, specifically the ones providing public key encryption and symmetric key encryption 🔐 The initial hash key (which is also one of the TESLA bootstrapping parameters) doesn't need confidentiality protection, thanks to the properties of a hash chain 🧠

6. IANA Considerations 📋

This document requires an IANA registration for the following attributes. The registries are provided by MIKEY [RFC3830] 🗂️

Prot Type:

this attribute specifies the protocol type for the security protocol, as described in Section 4.1.

Type:

identifies the type of the general payload. The General Extensions Payload was defined to allow possible extensions to MIKEY without needing a completely new payload every single time 🧩 Section 4.4 describes this attribute in more detail.

Following the policies outlined in [RFC3830], 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 🌸

The IANA has added the following attributes and their respective values to an existing registry created in [RFC3830] 🎀

Prot Type:

Prot Type     | Value | Description
-----------------------------------------------------
TESLA         |     1 | TESLA as a security protocol

The value of 1 for the 'Prot Type' must be added to the 'Prot type' registry created by [RFC3830].

Type:

Type          | Value | Description
-------------------------------------------
TESLA I-Key   |     2 | TESLA initial key

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] 💜

Also, the IANA has created 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 TESLA policy (see Section 4.2).

TESLA-MAC: MAC Function used in TESLA:

this attribute specifies values for pseudo-random functions used in 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 has added the following values to the TESLA-PRF and the TESLA-MAC registry ⭐

TESLA-PRF:

PRF Function     | Value
--------------------------
HMAC-SHA1        |  0

TESLA-MAC:

MAC Function     | Value
--------------------------
HMAC-SHA1        |  0

7. Acknowledgements 🫶

The authors would like to thank Mark Baugher and Ran Canetti for the discussions in context of time synchronization. Additionally, the authors 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

  • [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. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
  • [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006.

8.2. Informative References

  • [DHHMAC] Euchner, M., "HMAC-authenticated Diffie-Hellman for MIKEY", Work in Progress, April 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.
  • [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. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
  • [RSA-R] Ignjatic, D., "An additional mode of key distribution in MIKEY: MIKEY-RSA-R", Work in Progress, February 2006.

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

Copyright (C) The Internet Society (2006).

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.

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.

Intellectual Property ✨

okay so the IETF is NOT picking a side on whether any Intellectual Property Rights (IPR) apply to the tech in this doc, or how much they cover, or whether you can even get a license for them 🙈 it also isn't claiming it went digging for those rights itself. if you want the official procedures for RFC rights stuff, check out BCP 78 and BCP 79 💅

bestie, if you need copies of IPR disclosures sent to the IETF Secretariat, or the licensing assurances people have promised, or the results of trying to get a general license or permission to use proprietary rights as an implementer or user of this spec, the IETF's online IPR repository is where it's at: http://www.ietf.org/ipr 🧚

and the IETF is literally begging for help here 🥺 if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard, please let them know! send it to ietf-ipr@ietf.org 💜

Acknowledgement ✨

the RFC Editor function gets its funding from the IETF Administrative Support Activity (IASA) 🎀 so shoutout to them for keeping the lights on, iykyk 🫶🌸

📦 where this page comes from