[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-rmt-simple-auth-for-alc-norm

RMT                                                              V. Roca
Internet-Draft                                                     INRIA
Intended status: Experimental                          November 19, 2007
Expires: May 22, 2008


      Simple Authentication Schemes for the ALC and NORM Protocols
             draft-roca-rmt-simple-auth-for-alc-norm-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Roca                      Expires May 22, 2008                  [Page 1]


Internet-Draft            TESLA in ALC and NORM            November 2007


Abstract

   This document introduces two schemes that provide a per-packet
   authentication and integrity service in the context of the ALC and
   NORM protocols.  The first scheme is based on digital signatures.
   Because it relies on asymmetric cryptography, this scheme generates a
   high processing load at the sender and to a lesser extent at a
   receiver, as well as a significant transmission overhead.  It is
   therefore well suited to low data rate sessions.  The second scheme
   relies on a group Message Authentication Code (MAC).  Because this
   scheme relies symmetric cryptography, MAC calculation and
   verification are fast operations, which makes it suited to high data
   rate sessions.  However it only provides a group authentication and
   integrity service, which means that it only protects against
   attackers that are not group members.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions Used in this Document  . . . . . . . . . . . .  4
     1.2.  Terminology and Notations  . . . . . . . . . . . . . . . .  4
   2.  Digital Signature Scheme . . . . . . . . . . . . . . . . . . .  6
     2.1.  Principles . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Parameters that Need to Be Initialized Out-of-Band . . . .  6
     2.3.  Authentication Header Extension Format . . . . . . . . . .  7
     2.4.  Use of Authentication Header Extensions  . . . . . . . . .  8
   3.  Group MAC Scheme . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Principles . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.2.  Parameters that Need to Be Initialized Out-of-Band . . . .  9
     3.3.  Authentication Header Extension Format . . . . . . . . . . 10
     3.4.  Use of Authentication Header Extensions  . . . . . . . . . 11
   4.  Combined Use of the Digital Signatures and Group MAC
       Schemes  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Principles . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.2.  Combined Use of both Authentication Header Extensions  . . 12
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20







Roca                      Expires May 22, 2008                  [Page 2]


Internet-Draft            TESLA in ALC and NORM            November 2007


1.  Introduction

   Many applications using multicast and broadcast communications
   require that each receiver be able to authenticate the source of any
   packet it receives as well as its integrity.  For instance, ALC
   [draft-ietf-rmt-pi-alc-revised] and NORM
   [draft-ietf-rmt-pi-norm-revised] are two Content Delivery Protocols
   (CDP) designed to transfer reliably objects (e.g. files) between a
   session's sender and several receivers.

   The NORM protocol is based on bidirectional transmissions.  Each
   receiver acknowledges data received or, in case of packet erasures,
   asks for retransmissions.  The ALC protocol defines unidirectional
   transmissions.  Reliability can be achieved by means of cyclic
   transmissions of the content within a carousel, or by the use of
   proactive Forward Error Correction codes (FEC), or by the joint use
   of these mechanisms.  Being purely unidirectional, ALC is massively
   scalable, while NORM is intrinsically limited in terms of the number
   of receivers that can be handled in a session.  Both protocols have
   in common the fact that they operate at application level, on top of
   an erasure channel (e.g. the Internet) where packets can be lost
   (erased) during the transmission.  With some use case, an attacker
   might impersonate the ALC or NORM session's sender and inject forged
   packets to the receivers, thereby corrupting the objects
   reconstructed by the receivers.

   In case of group communications, several solutions exist to provide
   the receiver some guaranties on the integrity of the packets it
   receives and on the identity of the sender of these packets.  These
   solutions have different features that make them more or less suited
   to a given use case:

   o  digital signatures [RFC4359]: this scheme is well suited to low
      data rate flows, when a true packet sender authentication and
      packet integrity service is needed.  However this solution is
      limited by high computational costs and high transmission
      overheads.

   o  group Message Authentication Codes (MAC): this scheme is well
      suited to high data rate flows, when transmission overheads must
      be minimized.  However this scheme cannot protect against attacks
      coming from inside the group, where a group member impersonates
      the sender and sends forged messages to other receivers.

   o  TESLA (Timed Efficient Stream Loss-tolerant Authentication)
      [RFC4082]: this scheme is well suited to high data rate flows,
      when transmission overheads must be minimized, and when a true
      packet sender authentication and packet integrity service is



Roca                      Expires May 22, 2008                  [Page 3]


Internet-Draft            TESLA in ALC and NORM            November 2007


      needed.  The price to pay is an increased complexity, in
      particular the need to loosely synchronize the receivers and the
      sender, as well as the need to wait for the key to be disclosed
      before being able to authenticate a packet.

   The following table summarizes the pros/cons of each scheme:

   +----------------------------+--------------+---------------+-------+
   |                            |    Digital   |   Group MAC   | TESLA |
   |                            |   Signature  |               |       |
   +----------------------------+--------------+---------------+-------+
   | True authentication and    |      Yes     |   No (group   |  Yes  |
   | integrity service          |              |   security)   |       |
   |                            |              |               |       |
   | Immediate authentication   |      Yes     |      Yes      |   No  |
   |                            |              |               |       |
   | Processing load            |      --      |       ++      |   +   |
   |                            |              |               |       |
   | Transmission overhead      |      --      |       ++      |   +   |
   |                            |              |               |       |
   | Protocol complexity        |      ++      |       ++      |   --  |
   +----------------------------+--------------+---------------+-------+

   [draft-ietf-msec-tesla-for-alc-norm] explains how to use TESLA in the
   context of ALC and NORM protocols.  The current document specifies
   the use of the first two schemes, namely the Digital Signature and
   Group MAC schemes, in the ALC and NORM content delivery protocols.
   Since the FLUTE application [RFC3926] is built on top of ALC, it will
   directly benefit from the services offered by TESLA at the transport
   layer.  Unlike the TESLA scheme, this specification considers the
   authentication/integrity of the packets generated by the session's
   sender as well as those generated by the receivers (NORM).

1.1.  Conventions Used in this Document

   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 [RFC2119].

1.2.  Terminology and Notations

   The following notations and definitions are used throughout this
   document:

   o  MAC is the Message Authentication Code;

   o  HMAC is the Keyed-Hash Message Authentication Code;




Roca                      Expires May 22, 2008                  [Page 4]


Internet-Draft            TESLA in ALC and NORM            November 2007


   Digital signature related notations and definitions:

   o  K_pub is the public key used by a receiver to check a packet's
      signature.  This key must be communicated to all receivers, before
      starting the session;

   o  K_priv is the private key used by a sender to generate a packet's
      signature;

   o  n_k is the (private and public) key length, in bits. n_k is also
      the signature length, since both values must be equal with digital
      signatures;

   Group MAC related notations and definitions:

   o  K_g is a shared group key, communicated to all group members,
      confidentially, before starting the session.  The mechanism by
      which this group key is shared by the group members is out of the
      scope of this document;

   o  n_k is the key length, in bits;

   o  n_m is the length of the truncated output of the MAC [RFC2104].
      Only the n_m left-most bits (most significant bits) of the MAC
      output are kept;


























Roca                      Expires May 22, 2008                  [Page 5]


Internet-Draft            TESLA in ALC and NORM            November 2007


2.  Digital Signature Scheme

2.1.  Principles

   The computation of the digital signature, using K_priv, includes the
   ALC or NORM header (with the various header extensions) and the
   payload when applicable.  The UDP/IP/MAC headers are not included.
   During this computation, the "Signature" field MUST be set to 0.

   Upon receiving this packet, the receiver recomputes the Group MAC,
   using K_pub, and compares it to the value carried in the packet.
   During this computation, the Weak Group MAC field MUST also be set to
   0.  If the check fails, the packet MUST be immediately dropped.

   With RSASSA-PKCS1-v1_5 (default) and RSASSA-PSS signatures
   (Section 5), the size of the signature is equal to the "RSA modulus",
   unless the "RSA modulus" is not a multiple of 8 bits.  In that case,
   the signature MUST be prepended with between 1 and 7 bits set to zero
   such that the signature is a multiple of 8 bits [RFC4359].  The key
   size, which in practice is also equal to the "RSA modulus", has major
   security implications.  [RFC4359] explains how to choose this value
   depending on the maximum expected lifetime of the session.  This
   choice is out of the scope of this document.

2.2.  Parameters that Need to Be Initialized Out-of-Band

   Several parameters MUST be initialized by an out-of-band mechanism
   The sender or group controller:

   o  MUST communicate his public key, for each receiver to be able to
      verify the signature of the bootstrap (and direct time
      synchronization response messages when applicable).  As a side
      effect, the receivers also know the key length, n_k, and the
      signature length, the two parameters being equal.

   o  MAY communicate a certificate (which also means that a PKI has
      been setup), for each receiver to be able to check the sender's
      public key.

   o  MUST communicate the Signature Encoding Algorithm.  For instance,
      [RFC3447] defines the RSASSA-PKCS1-v1_5 and RSASSA-PSS algorithms
      that are usually used to that purpose.

   o  MUST associate a value to the "ASID" field (Authentication Scheme
      Identifier) of the EXT_AUTH header extension (Section 2.3).

   These parameters MUST be communicated to all receivers before they
   can authenticate the incoming packets.  For instance it can be



Roca                      Expires May 22, 2008                  [Page 6]


Internet-Draft            TESLA in ALC and NORM            November 2007


   communicated in the session description, or initialized in a static
   way on the receivers, or communicated by means of an appropriate
   initialization protocol.  The details of this out-of-band mechanism
   are out of the scope of this document.

2.3.  Authentication Header Extension Format

   The integration of Digital Signatures in ALC or NORM is similar and
   relies on the header extension mechanism defined in both protocols.
   More precisely this document details the EXT_AUTH==1 header extension
   defined in [draft-ietf-rmt-bb-lct-revised].

      ----- Editor's note: All authentication schemes using the EXT_AUTH
      header extension MUST reserve the same 4 bit "ASID" field after
      the HET/HEL fields.  This way, several authentication schemes can
      be used in the same ALC or NORM session, even on the same
      communication path. -----

   Several fields are added in addition to the HET (Header Extension
   Type) and HEL (Header Extension Length) fields (Figure 1).


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   HET (=1)    |      HEL      |  ASID |       Reserved        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                                                               ~
    |                           Signature                           |
    +                                               +-+-+-+-+-+-+-+-+
    |                                               |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: Format of the Digital Signature EXT_AUTH header extension.

   The fields of the Digital Signature EXT_AUTH header extension are:

   "ASID" (Authentication Scheme Identifier) field (4 bits):

      The "ASID" identifies the source authentication scheme or protocol
      in use.  The association between the "ASID" value and the actual
      authentication scheme is defined out-of-band, at session startup.

   "Reserved" field (12 bits):






Roca                      Expires May 22, 2008                  [Page 7]


Internet-Draft            TESLA in ALC and NORM            November 2007


      This is a reserved field that MUST be set to zero in this
      specification.

   "Signature" field (variable size, multiple of 32 bits):

      The "Signature" field contains a digital signature of the message.
      If need be, this field is padded (with 0) up to a multiple of 32
      bits.

2.4.  Use of Authentication Header Extensions

   Each packet sent by the session's sender MUST contain exactly one
   Digital Signature EXT_AUTH header extension.  A receiver MUST drop
   packets that do not contain a Digital Signature EXT_AUTH header
   extension.

   All receivers MUST recognize EXT_AUTH but MAY not be able to parse
   its content, for instance because they do not support digital
   signatures.  In that case these receivers MUST ignore the Digital
   Signature EXT_AUTH header extensions.


  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   HET (=1)    |    HEL (=33)  |  ASID |          0            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ----
 |                                                               |  ^  1
 +                                                               +  |  2
 |                                                               |  |  8
 .                                                               .  |
 .                      Signature (128 bytes)                    .  |  b
 .                                                               .  |  y
 |                                                               |  |  t
 +                                                               +  |  e
 |                                                               |  v  s
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ----

    Figure 2: Example: Format of the Digital Signature EXT_AUTH header
                   extension using 1024 bit signatures.

   For instance Figure 2 shows the digital signature EXT_AUTH header
   extension when using 128 byte (1024 bit) key digital signatures
   (which also means that the signature field is 128 byte long).  The
   Digital Signature EXT_AUTH header extension is then 132 byte long.






Roca                      Expires May 22, 2008                  [Page 8]


Internet-Draft            TESLA in ALC and NORM            November 2007


3.  Group MAC Scheme

3.1.  Principles

   The computation of the Group MAC, using K_g, includes the ALC or NORM
   header (with the various header extensions) and the payload when
   applicable.  The UDP/IP/MAC headers are not included.  During this
   computation, the Weak Group MAC field MUST be set to 0.  Then the
   sender truncates the MAC output to keep the n_w most significant bits
   and stores the result in the Group MAC Authentication header.

   Upon receiving this packet, the receiver recomputes the Group MAC,
   using K_g, and compares it to the value carried in the packet.
   During this computation, the Group MAC field MUST also be set to 0.
   If the check fails, the packet MUST be immediately dropped.

   [RFC2104] explains that it is current practice to truncate the MAC
   output, on condition that the truncated output length, n_m be not
   less than half the length of the hash and not less than 80 bits.
   However, this choice is out of the scope of this document.

3.2.  Parameters that Need to Be Initialized Out-of-Band

   Several parameters MUST be initialized by an out-of-band mechanism
   The sender or group controller:

   o  MUST communicate the cryptographic Message Authentication Code
      (MAC).  For instance, HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256,
      HMAC-SHA-384, or HMAC-SHA-512.  As a side effect, the receivers
      also know the key length, n_k, and the (non truncated) MAC output
      length.

   o  MUST communicate the length of the truncated output of the MAC,
      n_m.

   o  MUST communicate the K_g group key to the receivers,
      confidentially, before starting the session.  This key might have
      to be periodically refreshed.

   o  MUST associate a value to the "ASID" field (Authentication Scheme
      Identifier) of the EXT_AUTH header extension (Section 3.3).

   These parameters MUST be communicated to all receivers before they
   can authenticate the incoming packets.  For instance it can be
   communicated in the session description, or initialized in a static
   way on the receivers, or communicated by means of an appropriate
   initialization protocol.  The details of this out-of-band mechanism
   are out of the scope of this document.



Roca                      Expires May 22, 2008                  [Page 9]


Internet-Draft            TESLA in ALC and NORM            November 2007


3.3.  Authentication Header Extension Format

   The integration of Group MAC in ALC or NORM is similar and relies on
   the header extension mechanism defined in both protocols.  More
   precisely this document details the EXT_AUTH==1 header extension
   defined in [draft-ietf-rmt-bb-lct-revised].

      ----- Editor's note: All authentication schemes using the EXT_AUTH
      header extension MUST reserve the same 4 bit "ASID" field after
      the HET/HEL fields.  This way, several authentication schemes can
      be used in the same ALC or NORM session, even on the same
      communication path. -----

   Several fields are added in addition to the HET (Header Extension
   Type) and HEL (Header Extension Length) fields (Figure 3).


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   HET (=1)    |      HEL      |  ASID |       Reserved        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                                                               ~
    |                           Group MAC                           |
    +                                               +-+-+-+-+-+-+-+-+
    |                                               |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 3: Format of the Group MAC EXT_AUTH header extension.

   The fields of the Group MAC EXT_AUTH header extension are:

   "ASID" (Authentication Scheme Identifier) field (4 bits):

      The "ASID" identifies the source authentication scheme or protocol
      in use.  The association between the "ASID" value and the actual
      authentication scheme is defined out-of-band, at session startup.

   "Reserved" field (12 bits):

      This is a reserved field that MUST be set to zero in this
      specification.

   "Group MAC" field (variable size, multiple of 32 bits):






Roca                      Expires May 22, 2008                 [Page 10]


Internet-Draft            TESLA in ALC and NORM            November 2007


      The "Group MAC" field contains a Group MAC of the message.  If
      need be, this field is padded (with 0) up to a multiple of 32
      bits.

3.4.  Use of Authentication Header Extensions

   Each packet sent by the session's sender MUST contain exactly one
   Group MAC EXT_AUTH header extension.  A receiver MUST drop packets
   that do not contain a Group MAC EXT_AUTH header extension.

   All receivers MUST recognize EXT_AUTH but MAY not be able to parse
   its content, for instance because they do not support Group MAC.  In
   that case these receivers MUST ignore the Group MAC EXT_AUTH
   extensions.


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   HET (=1)    |     HEL (=4)  |  ASID |          0            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                      Group MAC (10 bytes)                     |
    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |            Padding            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4: Example: Format of the Group MAC EXT_AUTH header extension
                             using HMAC-SHA-1.

   For instance Figure 4 shows the Group MAC EXT_AUTH header extension
   when using HMAC-SHA-1.  The Group MAC EXT_AUTH header extension is
   then 16 byte long.

















Roca                      Expires May 22, 2008                 [Page 11]


Internet-Draft            TESLA in ALC and NORM            November 2007


4.  Combined Use of the Digital Signatures and Group MAC Schemes

4.1.  Principles

   In some situations, it can be interesting to use both authentication
   schemes.  The goal of the Group MAC is to mitigate DoS attacks coming
   from attackers that are not group member [RFC4082] by adding a light
   authentication scheme as a front-end.

   More specifically, before sending a message, the sender computes the
   Group MAC MAC(K_g, M), which includes the ALC or NORM header (with
   the various header extensions), plus the payload when applicable.
   During this computation, the Weak Group MAC field MUST be set to 0.
   However the digital signature MUST have been calculated and is
   included in the Group MAC calculation itself.  Then the sender
   truncates the MAC output to keep the n_w most significant bits and
   stores the result in the Group MAC authentication header.  Upon
   receiving this packet, the receiver recomputes the Group MAC and
   compares it to the value carried in the packet.  If the check fails,
   the packet MUST be immediately dropped.

   This scheme features a few limits:

   o  it is of no help if a group member (who knows K_g) impersonates
      the sender and sends forged messages to other receivers;

   o  it requires an additional MAC computing for each packet, both at
      the sender and receiver sides;

   o  it increases the size of the authentication headers.  In order to
      limit this problem, the length of the truncated output of the MAC,
      n_m, SHOULD be kept small (e.g. 32 bits) (see [RFC3711] section
      9.5).  As a side effect, the authentication service is
      significantly weakened (the probability that any packet be
      successfully forged is one in 2^32).  Since the Group MAC check is
      only a pre-check that will be followed by the standard signature
      authentication check, this is not considered to be an issue.

   For a given use-case, the benefits brought by the Group MAC must be
   balanced against these limitations.

4.2.  Combined Use of both Authentication Header Extensions

   In order to use both authentication schemes, the packet sender
   calculates and includes two EXT_AUTH header extensions, in any order,
   one for each authentication scheme.  It is RECOMMENDED that the n_m
   parameter of the group authentication scheme be small, for instance
   equal to 32 bits (Section 4.1).



Roca                      Expires May 22, 2008                 [Page 12]


Internet-Draft            TESLA in ALC and NORM            November 2007


   When it is decided that both schemes should be combined, then all the
   packets MUST include both header extensions.  A receiver receiving a
   packet with only one of the two schemes MUST reject it.  This
   requirement is meant to prevent DoS attacks where the attacker would
   inject forged packets containing only the Digital Signature EXT_AUTH
   header extension, to force the receiver to check it.













































Roca                      Expires May 22, 2008                 [Page 13]


Internet-Draft            TESLA in ALC and NORM            November 2007


5.  IANA Considerations

   This document does not require any IANA registration.
















































Roca                      Expires May 22, 2008                 [Page 14]


Internet-Draft            TESLA in ALC and NORM            November 2007


6.  Security Considerations

   TBD
















































Roca                      Expires May 22, 2008                 [Page 15]


Internet-Draft            TESLA in ALC and NORM            November 2007


7.  Acknowledgments

   TBD
















































Roca                      Expires May 22, 2008                 [Page 16]


Internet-Draft            TESLA in ALC and NORM            November 2007


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

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

   [draft-ietf-msec-tesla-for-alc-norm]
              Adamson, B., Bormann, C., Handley, M., and J. Macker, "Use
              of TESLA in the ALC and NORM Protocols",
               draft-ietf-msec-tesla-for-alc-norm-03.txt (work in
              progress), November 2007.

   [draft-ietf-rmt-bb-lct-revised]
              Luby, M., Watson, M., and L. Vicisano, "Layered Coding
              Transport (LCT) Building Block",
               draft-ietf-rmt-bb-lct-revised-06.txt (work in progress),
              November 2007.

   [draft-ietf-rmt-pi-alc-revised]
              Luby, M., Watson, M., and L. Vicisano, "Asynchronous
              Layered Coding (ALC) Protocol Instantiation",
               draft-ietf-rmt-pi-alc-revised-05.txt (work in progress),
              November 2007.

   [draft-ietf-rmt-pi-norm-revised]
              Adamson, B., Bormann, C., Handley, M., and J. Macker,
              "Negative-acknowledgment (NACK)-Oriented Reliable
              Multicast (NORM) Protocol",
               draft-ietf-rmt-pi-norm-revised-05.txt (work in progress),
              March 2007.

8.2.  Informative References

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.



Roca                      Expires May 22, 2008                 [Page 17]


Internet-Draft            TESLA in ALC and NORM            November 2007


              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC3926]  Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
              "FLUTE - File Delivery over Unidirectional Transport",
              RFC 3926, October 2004.

   [RFC4359]  Weis, B., "The Use of RSA/SHA-1 Signatures within
              Encapsulating Security Payload (ESP) and Authentication
              Header (AH)", RFC 4359, January 2006.









































Roca                      Expires May 22, 2008                 [Page 18]


Internet-Draft            TESLA in ALC and NORM            November 2007


Author's Address

   Vincent Roca
   INRIA
   655, av. de l'Europe
   Zirst; Montbonnot
   ST ISMIER cedex  38334
   France

   Email: vincent.roca@inrialpes.fr
   URI:   http://planete.inrialpes.fr/~roca/








































Roca                      Expires May 22, 2008                 [Page 19]


Internet-Draft            TESLA in ALC and NORM            November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.


Acknowledgment

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





Roca                      Expires May 22, 2008                 [Page 20]


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