path: root/doc/rfc/rfc4442.txt

Network Working Group                                           S. Fries
Request for Comments: 4442                                 H. Tschofenig
Category: Standards Track                                        Siemens
                                                              March 2006


                             Bootstrapping
      Timed Efficient Stream Loss-Tolerant Authentication (TESLA)

Status of This Memo

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

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   TESLA, the Timed Efficient Stream Loss-tolerant Authentication
   protocol, provides source authentication in multicast scenarios.
   TESLA is an efficient protocol with low communication and computation
   overhead that 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 Message Authentication Code (MAC) chaining.  The use
   of TESLA within the Secure Real-time Transport Protocol (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 payloads for the Multimedia Internet Keying
   (MIKEY) protocol 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.









Fries & Tschofenig          Standards Track                     [Page 1]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


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





























Fries & Tschofenig          Standards Track                     [Page 2]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


1.  Introduction

   In many multicast, broadcast, and unicast communication scenarios, it
   is necessary to guarantee that a received message has been sent from
   a dedicated source and has not been altered in transit.  In unicast
   communication, commonly a pairwise security association exists that
   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 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.

   [RFC4383] 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
   parameter 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.  [RFC4383] 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 that is intended to support SRTP in the first place
   but is open to enhancements to be used for other purposes too.
   Following the description in [RFC3830], MIKEY is targeted for point-
   to-point as well as 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 focuses only on the distribution
   of the parameters, not on the generation of those parameters.

   MIKEY [RFC3830] itself describes three authentication and key
   exchange protocols (symmetric key encryption, public key encryption,



Fries & Tschofenig          Standards Track                     [Page 3]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


   and signed Diffie-Hellman).  Extensions to the MIKEY key exchange
   methods have been defined.  A fourth key distribution method is
   provided by [DHHMAC] and describes a symmetrically protected Diffie-
   Hellman key agreement.  A further option has been proposed in [RSA-R]
   that describes an enhanced asymmetric exchange variant, also
   supporting inband certificate exchange.  All the different key
   management schemes mentioned above may be used to provide the TESLA
   parameters.  The required TESLA parameters to be exchanged are
   already described in [RFC4383], 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 are covered in [RFC4383].

   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 [RFC4383], then (a) keying material and (b)
   parameters for TESLA are required.  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 also provided 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 [RFC4383], a number of transform-dependent parameters
   need to be provided for proper TESLA operation.  The complete list of
   parameters can be found in Section 4.3 of [RFC4383].  Note that
   parameter 10 of [RFC4383], describing the lag of the receiver clock
   relative to the sender clock, is omitted in this document since it
   can be computed.




Fries & Tschofenig          Standards Track                     [Page 4]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


   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 the 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 [RFC4383].

   1.   An identifier for the PRF (TESLA PRF), implementing 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), e.g., to indicate the
        keyed hash function (default HMAC-SHA1).

   2.   A non-negative integer, determining the length of the F output,
        i.e., the length of the keys in the chain, which is also the key
        disclosed in an SRTP packet if TESLA is used in the SRTP context
        (default 160 bit).

   3.   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).

   4.   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).

   5.   A non-negative integer, determining the length of the output of
        the TESLA MAC (default 80 bit).

   6.   The beginning of the session for which a key will be applied.

   7.   The interval duration (in milliseconds) for which a dedicated
        key will be used.

   8.   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).

   9.   Non-negative integer, determining the length of the key chain,
        which is determined based on the expected duration of the
        stream.

   10.  The initial key of the chain to which the sender has committed
        himself.





Fries & Tschofenig          Standards Track                     [Page 5]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


4.  Parameter Encoding within MIKEY

   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 (SP) Payload

   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 |

      *  Policy param length (16 bits):
         This field defines the total length of the
         policy parameters for the selected security protocol.




Fries & Tschofenig          Standards Track                     [Page 6]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


      *  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 [RFC4383], but other values
   may also be used:

      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

   The time values stated 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, carrying
   interval duration and key disclosure delay.  Policy type 9 stated



Fries & Tschofenig          Standards Track                     [Page 7]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


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

   MIKEY as well as TESLA require the time synchronization of the
   communicating peers.  MIKEY requires time synchronization 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 release the disclosed key
   appropriately.  Two alternatives are available for time
   synchronization:

   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 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, setting the local
          time stamp at data receiver (parameter 11) to the value t_r



Fries & Tschofenig          Standards Track                     [Page 8]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


          received in the MIKEY initiator message, and sets his 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 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.

   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.






















Fries & Tschofenig          Standards Track                     [Page 9]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


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
   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.

















Fries & Tschofenig          Standards Track                    [Page 10]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


5.  Security Considerations

   The security properties of multi-media data in a multicast
   environment depends 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, security considerations described with TESLA
   (see [PCST] and [RFC4082]), the TESLA SRTP mapping [RFC4383], and
   SRTP [RFC3711] itself are 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.

   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, 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.

   o  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:

      The exchange of security-related parameters and algorithms without
      mutual authentication of the two peers can allow an adversary to
      perform a man-in-the-middle attack.  The mechanisms described in
      this document do not themselves 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



Fries & Tschofenig          Standards Track                    [Page 11]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


      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
      exchange will make it impossible 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.

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 be listed.  To
      mount an attack, the adversary has to modify the list of provided
      algorithms and to select the weakest one.

   Countermeasures:

      TESLA parameter bootstrapping MUST be integrity protected to
      prevent modification of the parameters 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 exchanged 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 disrupt the
      communication at a later state since the TESLA algorithm assumes
      that the participating communication entities know the same
      parameter set.





Fries & Tschofenig          Standards Track                    [Page 12]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


   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

   Threat:

      An adversary who is able to eavesdrop on 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), 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
      he is located along the signaling path.  This information can then
      later be used to mount attacks against the end-to-end multimedia
      communication.  In some high-security and military environments,
      it might even be desirable not to reveal information about the
      used parameters to make it more difficult to launch an attack.

   Countermeasures:

      Confidentiality 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



Fries & Tschofenig          Standards Track                    [Page 13]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


      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.  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 the need for defining a completely new payload each
      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].




Fries & Tschofenig          Standards Track                    [Page 14]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


   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, we
   would like to thank Lakshminath Dondeti, Russ Housley, and Allison
   Mankin for their document reviews and for their guidance.












Fries & Tschofenig          Standards Track                    [Page 15]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


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.






Fries & Tschofenig          Standards Track                    [Page 16]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


   [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


























Fries & Tschofenig          Standards Track                    [Page 17]
^L
RFC 4442                  Bootstrapping TESLA                 March 2006


Full Copyright Statement

   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

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Fries & Tschofenig          Standards Track                    [Page 18]
^L