[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                                IETF MSEC
Internet Draft                                 Perrig, Canetti, Whillock
draft-ietf-msec-tesla-spec-00.txt                        CMU / IBM / CMU
27 October 2002
Expires: 27 April 2002


     TESLA: Multicast Source Authentication Transform Specification

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 mate­
   rial or to cite them other than as "work in progress".

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


Abstract

   Data authentication is an important component for many applications,
   for example audio and video Internet broadcasts, or data distribution
   by satellite. This document specifies TESLA, a secure source authen­
   tication mechanism for multicast or broadcast data streams. The com­
   panion draft draft-msec-tesla-intro-01.txt [1] introduces and
   describes TESLA in detail, this document specifies the format of the
   TESLA authentication field as it is used within the MESP header [2].

   The main deterrents so far for a data authentication mechanism for
   multicast were seemingly conflicting requirements: tolerance to
   packet loss, low per-packet overhead, low computation overhead, scal­
   ability, no per-receiver state at the sender. The problem is particu­
   larly hard in settings with high packet loss rates and where lost
   packets are not retransmitted, and where the receiver wants to
   authenticate each packet it receives.

   TESLA provides multicast source authentication of individual data
   packets, regardless of the packet loss rate. In addition, TESLA



Perrig, Canetti, Whillock                                     [Page 1]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002


   features low overhead for both sender and receiver, and does not
   require per-receiver state at the sender. TESLA is secure as long as
   the sender and receiver are loosely time synchronized.



                           Table of Contents

1          Introduction  . . . . . . . . . . . . . . . . . . . . . .   2
1.1        Previous Work . . . . . . . . . . . . . . . . . . . . . .   2
1.2        Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
2          TESLA Specification . . . . . . . . . . . . . . . . . . .   3
2.1        Sender Setup  . . . . . . . . . . . . . . . . . . . . . .   3
2.2        Receiver Bootstrapping  . . . . . . . . . . . . . . . . .   4
2.2.1      Bootstrapping Parameters  . . . . . . . . . . . . . . . .   4
2.2.2      Direct Time Synchronization . . . . . . . . . . . . . . .   5
2.2.3      set-up using a multicast key management protocol  . . . .   7
2.3        Layer Placement . . . . . . . . . . . . . . . . . . . . .   7
2.3.1      Interface Specification . . . . . . . . . . . . . . . . .   7
2.3.1.1    Time Synchronization request  . . . . . . . . . . . . . .   7
2.3.1.2    Authentic Parameters  . . . . . . . . . . . . . . . . . .   9
2.4        Sending Authenticated Data  . . . . . . . . . . . . . . .   9
3          Security Considerations . . . . . . . . . . . . . . . . .  10
4          Acknowledgments . . . . . . . . . . . . . . . . . . . . .  11
5          Bibliography  . . . . . . . . . . . . . . . . . . . . . .  11
A          Cryptographic Type Assigned Numbers . . . . . . . . . . .  12
B          Author Contact Information  . . . . . . . . . . . . . . .  13
C          Full Copyright Statement  . . . . . . . . . . . . . . . .  14



1 Introduction

   This document specifies the format of the TESLA source authentication
   data  as  an  external-authentication  transform  within  the  MESP
   protocol  [2].  It  specifies  the  cryptographic  operations  and
   message formats. The description of the TESLA protocol is
   in the companion draft draft-msec-tesla-intro-01.txt [1], more
   details are in our academic publications [3,4,5,6].

1.1 Previous Work

   A number of schemes for solving data authentication have been sug­
   gested [7,8,9,10,11,6,5,12,13].  An Internet Draft based on [11] was
   proposed by McCarthy in 1998 but was not updated.

   This document is based on the TESLA [3,6,5] and FLAMeS [12] schemes,
   which have low computation and communication overhead. Similar
   schemes were suggested by Cheung [14], and by Bergadano et al.



Perrig, Canetti, Whillock                                     [Page 2]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002


   [13,15].

1.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 [16].

2 TESLA Specification

   TESLA is described in several academic publications: A book on broad­
   cast security [3], a journal paper [4], and two conference papers
   [6,5]. Please refer to these publications for an in-depth treatment.
   The TESLA companion Internet Draft gives a basic introduction to the
   TESLA protocol [1].

2.1 Sender Setup

   The sender chooses a time interval duration T_int. Practical values
   for T_int vary from 100 milliseconds to 1 second.

   The sender estimates an upper bound on the round-trip-time (RTT).
   More specifically, this RTT is the propagation delay of a unicast
   packet from the receiver to the sender, plus the propagation delay of
   a broadcast packet from the sender to the receiver. Based on the RTT,
   the sender chooses a key disclosure delay d, where d denotes a number
   of time intervals, such that d > ceil(RTT/T_int).

   The sender picks the starting time of time interval zero, which we
   denote with T_0. The starting time of time interval i is thus T_0 + i
   * T_int.

   Next, the sender pre-computes the one-way key chain. Each key of the
   one-way key chain is active in one time interval, for example, key
   K_i is active in time interval i. The sender always uses the active
   key to compute the MAC of a packet it sends. The sender discloses the
   keys with a delay of d time intervals, so it discloses key K_i-d in
   time interval i.

   To generate the one-way key chain, the sender chooses the length of
   the chain N.  In future versions, we will define extensions which
   allow the sender to switch key chains, but for now we assume that N
   is large enough such that the key chain is long enough for the dura­
   tion of the broadcast. The sender randomly selects the last key of
   the one-way key chain K_N. The random choice of K_N is critical, since
   the security of TESLA relies on the fact that an attacker cannot guess
   K_N.  Simply using a hash of the current time, process id, port num­
   ber, etc. is thus not sufficient, and we suggest using hardware-based



Perrig, Canetti, Whillock                                     [Page 3]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002


   random number generators, or operating system provided random number
   generators such as /dev/random or /dev/urandom on some UNIX systems.
   The bit length of K_N is a global parameter, and needs to match the
   output length of the pseudo-random function F that generates the one-
   way key chain (see the companion draft for more details on how the
   PRF F is used to generate the one-way chain and the PRF F' is used to
   derive the MAC key [1]).

   The sender uses a pseudo-random function F with target-collision
   resistance to generate the previous elements of the chain. We suggest
   using HMAC-MD5 for this purpose [17,18], where the output is trun­
   cated to the bit length of the key. If the key length is larger than
   128 bits, we suggest using HMAC-SHA-1; the 160 bit size should be
   sufficient for all practical purposes.

   Jakobsson [19], and Coppersmith and Jakobsson [20] present a storage
   and computation efficient mechanism for one-way chains. For a chain
   of length N, storage is about log(N) elements, and the computation
   overhead to reconstruct each element is also about log(N).

   The companion document draft-msec-tesla-intro-01.txt [1] has more
   information on the one-way key chain.

2.2 Receiver Bootstrapping

   TESLA requires that the sender and the receiver be at least loosely
   time synchronized such that the receiver MUST know an upper bound on
   the sender's clock. The receiver MUST also receive authentic parame­
   ters for initiating the TESLA session. Authentication is achieved
   with a digital signature such as RSA or DSA.

2.2.1 Bootstrapping Parameters

   In order to bootstrap, the receiver must receive the following
   authenticated information (Note that the Cryptographic Type Assigned
   Number (CTAN) is a 16-bit integer describing the type of authentica­
   tion used to generate the signature Sig. CTAN is described in
   Appendix A.):

     · The id j of a specific time interval I_j.

     · An NTP timestamp TI_j describing the beginning of that time
       interval.

     · An NTP timestamp T_int describing the interval duration.

     · A PRF CTAN describing the function that will be used to calculate
       the keychain (F).



Perrig, Canetti, Whillock                                     [Page 4]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002


     · A PRF CTAN describing the function that will be used to derive
       the MAC key from the keychain (F').

     · The key disclosure interval d (unit is intervals).

     · A bit I telling whether or not the optional id field will be in
       the TESLA authentication tag.

     · An Encryption CTAN representing the type of key to be used.

     · A disclosed key K_i (i < j - d).

     · The id n of the final key in this key chain, K_n.

     · The interval d_n of the last key chain element.

   The Network Time Protocol (NTP) timestamp is described in RFC 958 and
   is a 64 bit integer which can represent time with precision of .2
   nanoseconds. It is noted that this format will overflow in year 2030,
   TESLA will agree with any format changes in NTP to accomodate this
   problem.

2.2.2 Direct Time Synchronization

   In direct time synchronization, the receiver will synchronize its
   clock with the sender by determining an upper bound on the sender's
   clock. The protocol is very simple, and sufficies for the loose time
   synchronization required by TESLA.

   The receiver sends an initial time synchronization request to the
   sender. This time synchronization request will contain only a random
   nonce N_r to later ensure that data received from the sender is
   authentic. The receiver will then record the time T_s at which the
   nonce was sent. Figure 1 describes the format of the nonce. The size
   of the nonce is a multiple of 8 bits, and the sender can deduce the
   nonce size from the size of the request packet.


   Once N_r has been received, the sender responds with the bootstrap­
   ping parameters as well as the following time synchronization parame­
   ters:

     · An NTP timestamp T_sig describing when the data was signed.

     · An Authentication CTAN S_sig describing the signature type.

     · A bit F, allowing for an optional formatting of the signature to
       include a public certificate chain.



Perrig, Canetti, Whillock                                     [Page 5]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002



 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                                                               ~
|                          Nr (nonce)                           |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 1: Time synchronization request format


     · The signature Sig, used to authenticate the parameters.


 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
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |  # of certs   |          PCAN of certs        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Certificate 1       |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               ~
|                       Certificate 1                           |
~                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |         Padding               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Certificate 2       |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               ~
|                       Certificate 2                           |
~                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |         Padding               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Signature(variable length)                  ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 2: Optional Signature Format







Perrig, Canetti, Whillock                                     [Page 6]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002


   Sig is a signature of the bootstrapping parameters, the time synchro­
   nization parameters (exluding Sig), and N_r. The receiver can authen­
   ticate the data by appending its nonce to the parameter and use this
   data to verify the signature. This method assumes that the receiver
   has an authentic public key of the sender, for example using a pub­
   lic-key infrastructure, so the receiver has a list of authentic pub­
   lic root key certificates of the certificate authorities, and the
   sender sends along its certificate signed by a certificate authority.

   Once a receiver has received both sets of parameters, it records the
   time at which he received the parameters, T_r. The maximum clock off­
   set is d_t = T_r - T_s. The receiver can now easily compute an upper
   bound on the sender's current time t_s, using it's current local time
   t_r as follows: t_s = t_r - T_r + T_s. If d_t is larger than a cer­
   tain threshold, the receiver may repeat time synchronization.

   TESLA will return the data in the form of a Signature Tag, which has
   the format described in Figure 3. If so required TESLA will include a
   certificate chain for authentication via RSA or another public cer­
   tificate algorithm. If the bit F is set, then the optional format
   described by  2 is used. The PCAN is a Public Certificate Assigned
   Number describing what format the certificates are in.

2.2.3 Set-up using a multicast key management protocol.

   Another way to set-up the parameters of the TESLA transform at the
   receiver is to obtain these parameters in the Security Association
   provided by the multicast key management protocol in use (e.g.,
   GDOI). This way of setting the parameters will be further described
   in future versions of this draft.

2.3 Layer Placement

   This document assumes TESLA to be implemented as a standalone
   library, which could reside either in the network, transport, or
   application layer. However, incorporating TESLA within MESP
   implies usage in the network layer.

   TESLA relies upon timing of packets, that is, TESLA requires knowing
   the arrival time of incoming packets. TESLA SHOULD NOT be deployed on
   top of a protocol or layer which will aggressively buffer packets and
   hides the true packet arrival time, e.g.  TCP.

2.3.1 Interface Specification

   The following describes the interface which the TESLA library will
   export for the above methods of bootstrapping.

2.3.1.1 Time Synchronization request

   TESLA will accept a nonce and write a time synchronization request
   tag (TSRT) to a user specified buffer which must be of required
   length.  The nonce must have significant random properties (non-triv­
   ial and of certain length). The implementer must provide adequate
   space to write the TSRT.




Perrig, Canetti, Whillock                                     [Page 7]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002



 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Id j of time interval I_j (integer)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                     TI_j (NTP timestamp)                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                      T_int (NTP timedif)                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       KeyChain PRF type(F)    |        MAC PRF type(F')       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|       d (intervals)         |    Key type(HMAC function)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Key length            |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               ~
|                                                               |
~                       K_i(variable length)                    ~
|                                                               |
~                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |       Padding                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Id n of K_n (integer)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Interval of n, d_n (intervals)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~            Time of signature T_sig (NTP timestamp)            ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Signature type           |        Signature Length       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved(0) |                                               |
+-+-+-+-+-+-+-+-+     Signature(variable length)                ~
|                                                               |
~                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |       Padding                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 3: Signature Tag format





Perrig, Canetti, Whillock                                     [Page 8]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002


2.3.1.2 Authentic Parameters

   TESLA will accept the time synchronization request, which has the
   format described in Figure 1, and write the signature tag to a user
   specified buffer. It is assumed that the signature tag will be sent
   to the receiver immediately following the creation of the signature.
   Significant delay would result in too large a bound for d_t and pos­
   sible synchronization failure.

2.4 Sending Authenticated Data

   When the sender sends an authenticated message to all receivers, it
   adds a TESLA authentication tag to attach to the message. With the
   authentication tag, a receiver MAY be able to verify or disrepute
   previously received messages.

   TESLA will be used as the external authentication transform in the
   MESP protocol. (Recall that MESP determines exactly which fields
   are covered under the TESLA authentication.) The format of the TESLA
   authentication tag is shown in Figure 4. Here M denotes the data in
   the fields covered by the external authentication in MESP. Within
   the TESLA tag, the Id i of K_i is always sent with the MAC of the
   message M computed using K_i. The last disclosed key K_(i-d) can be
   used to authenticate previous messages.

   When a receiver receives the tag, he must first check to see that the
   time of the message does not violate the security conditions for the
   keys used. M is buffered, and he attempts to authenticate any mes­
   sages which relied upon K_(i-d).

   If i is not included in the message, the receiver determines i by the
   time the packet was received and the maximum time displacement from
   the server. With this time it then can determine the sender's current
   interval i.

   When the receiver receives an MESP packet with external authentication
   done using TESLA, it first needs to verify whether the packet is
   safe, which is to check that the key used to compute the MAC of the
   packet was still secret upon packet arrival. For this, the receiver
   computes an upper bound on the sender's clock, and checks that the
   MAC key is still secret (based on the key disclosure schedule).
   If the packet is safe, the receiver buffers the packet.

   Once the receiver has determined i, either directly or by the
   sender's time, it checks K_(i-d) against the most recently stored
   key, K_c.  If i-d=c then the receiver does nothing. Otherwise he
   applies the PRF (i-d)-c times to K_(i-d) which should yield K_c. If
   K_(i-d) is authentic, the receiver uses it to authenticate all mes­
   sages which used keys in the range K_(c+1) .. K_(i-d) as the MAC key.
   Finally the receiver replaces K_c with K_(i-d). Note, that if i-d<c
   the packet would have been unsafe and discarded before this step.



Perrig, Canetti, Whillock                                     [Page 9]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002



 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Id i of K_i(optional)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                      Disclosed Key K_(i-d)                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                     MAC(K_i, M)                               ~
|                                                               |
~                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     |               Padding                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Figure 4: Authentication Tag format. (This is the external
             authentication tag of MESP with TESLA.)


   A message in this interval may be authentic or tainted. Dealing with
   tainted messages is left to the implementor. It is possible that the
   sender and receiver have fallen out of sync, in which case it is REC­
   OMMENDED that they resynchronize times. If i is not included in the
   message to the receiver and the two have fallen out of sync, the
   receiver will not correctly compute i, and failure will occur when
   attempting to authenticate the key.

3 Security Considerations

   For a formal proof of the security of TESLA, please see [6].
   An analysis of the robustness of TESLA to denial-of-



Perrig, Canetti, Whillock                                    [Page 10]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002


   service attacks along with countermeasures is described in [5].

4 Acknowledgments

   We would like to thank Mike Luby for his feedback and support.

5 Bibliography

   [1] A. Perrig, R. Canetti, D. Song, and J. D. Tygar, "Tesla: Multi­
   cast source authentication transform introduction (draft-msec-tesla-
   intro-01.txt)," Internet Draft, Internet Engineering Task Force, Oct.
   2002.  Work in progress.

   [2] R. Canetti, P. R. P.-C. Cheng, and M. Baugher, "Mesp: Multicast
   encapsulating security payload (draft-ietf-msec-mesp-00.txt)," Inter­
   net Draft, Internet Engineering Task Force, Oct. 2002.  Work in
   progress.

   [3] A. Perrig and J. D. Tygar, Secure Broadcast Communication in
   Wired and Wireless Networks Kluwer Academic Publishers, Oct. 2002.
   ISBN 0792376501.

   [4] A. Perrig, R. Canetti, J. D. Tygar, and D. Song, "The tesla
   broadcast authentication protocol," RSA CryptoBytes , vol. 5, no.
   Summer, 2002.

   [5] A. Perrig, R. Canetti, D. Song, and J. D. Tygar, "Efficient and
   secure source authentication for multicast," in Network and Dis­
   tributed System Security Symposium, NDSS '01 , pp. 35--46, February
   2001.

   [6] A. Perrig, R. Canetti, J. Tygar, and D. X. Song, "Efficient
   authentication and signing of multicast streams over lossy channels,"
   in IEEE Symposium on Security and Privacy , May 2000.

   [7] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B.
   Pinkas, "Multicast security: A taxonomy and some efficient construc­
   tions," in Infocom '99 , 1999.

   [8] R. Gennaro and P. Rohatgi, "How to Sign Digital Streams," tech.
   rep., IBM T.J.Watson Research Center, 1997.

   [9] P. Rohatgi, "A compact and fast hybrid signature scheme for mul­
   ticast packet authentication," in 6th ACM Conference on Computer and
   Communications Security , November 1999.

   [10] P. Rohatgi, "A hybrid signature scheme for multicast source
   authentication," Internet Draft, Internet Engineering Task Force,



Perrig, Canetti, Whillock                                    [Page 11]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002


   June 1999.  Work in progress.

   [11] C. K. Wong and S. S. Lam, "Digital signatures for flows and mul­
   ticasts," in Proc. IEEE ICNP `98 , 1998.

   [12] B. Briscoe, "Flames: Fast, loss-tolerant authentication of mul­
   ticast streams," tech. rep., BT Research, 2000.
   http://www.labs.bt.com/people/briscorj/papers.html.

   [13] F. Bergadano, D. Cavagnino, and B. Crispo, "Chained stream
   authentication," in Selected Areas in Cryptography 2000 , (Waterloo,
   Canada), August 2000.  A talk describing this scheme was given at IBM
   Watson in August 1998.

   [14] S. Cheung, "An efficient message authentication scheme for link
   state routing," in 13th Annual Computer Security Applications Confer­
   ence , 1997.

   [15] F. Bergadano, D. Cavalino, and B. Crispo, "Individual single
   source authentication on the mbone," in ICME 2000 , Aug 2000.  A talk
   containing this work was given at IBM Watson, August 1998.

   [16] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments (Best Current Practice) 2119, Internet
   Engineering Task Force, Mar. 1997.

   [17] M. Bellare, R. Canetti, and H. Krawczyk, "HMAC: Keyed-hashing
   for message authentication," Internet Request for Comment RFC 2104,
   Internet Engineering Task Force, Feb. 1997.

   [18] M. Bellare, R. Canetti, and H. Krawczyk, "Keying hash functions
   for message authentication," in Advances in Cryptology - Crypto '96
   (N. Koblitz, ed.), (Berlin), pp. 1--15, Springer-Verlag, 1996.  Lec­
   ture Notes in Computer Science Volume 1109.

   [19] M. Jakobsson, "Fractal hash sequence representation and traver­
   sal."  Cryptology ePrint Archive, http://eprint.iacr.org/2002/001/,
   Jan. 2002.

   [20] D. Coppersmith and M. Jakobsson, "Almost optimal hash sequence
   traversal," in Proceedings of the Sixth International Financial Cryp­
   tography Conference (FC '02) , March 2002.

A Cryptographic Type Assigned Numbers


- PRF
     There are currently no pseudo-random functions defined.



Perrig, Canetti, Whillock                                    [Page 12]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002


     values 1-65000 are reserved to IANA. Values 65001-65535 are for
     private use among mutually consenting parties.


- Encryption Algorithm                       Defined In
      DES-CBC                             1     RFC 2405
      IDEA-CBC                            2
      Blowfish-CBC                        3
      RC5-R16-B64-CBC                     4
      3DES-CBC                            5
      CAST-CBC                            6

- Authentication Method
      pre-shared key                      1
      DSS signatures                      2
      RSA signatures                      3
      Encryption with RSA                 4
      Revised encryption with RSA         5

Public Certificate Assigned Numbers (PCAN)

Each PCAN is assigned to a specific Authentication Method assigned a CTAN.

- pre-shared key
      No certificates for pre-shared keys are defined.

- DSS signatures
      No certificates for DSS signatures are defined.

- RSA signatures
      PEM encoded                       1
      DER encoded                       2

- Encryption with RSA
      Same as RSA signatures

- Revised encryption with RSA
      Same as RSA signatures



B Author Contact Information


Adrian Perrig
Carnegie Mellon University
1301 Hamerschlag Hall
5000 Forbes Avenue



Perrig, Canetti, Whillock                                    [Page 13]


Internet Draft          draft-msec-tesla-spec-00         27 October 2002


Pittsburgh, PA 15218
US
perrig@cmu.edu

Ran Canetti
IBM Research
30 Saw Mill River Rd
Hawthorne, NY 10532
US
canetti@watson.ibm.com

Bram Whillock
Carnegie Mellon University
3150 La Mesa Dr.
San Carlos, CA 94070
US
bwhilloc@andrew.cmu.edu



C Full Copyright Statement

   Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this doc­
   ument itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop­
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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 MER­
   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."






Perrig, Canetti, Whillock                                    [Page 14]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/