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

Versions: (draft-dondeti-msec-ipsec-tesla) 00

Network                                                  L. Dondeti, Ed.
Internet-Draft                                            QUALCOMM, Inc.
Intended status: Standards Track                              R. Canetti
Expires: August 28, 2007                                    IBM Research
                                                       February 24, 2007


 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
                                in IPsec
                     draft-ietf-msec-ipsec-tesla-00

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 August 28, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies the use of Timed Efficient Stream Loss-
   tolerant Authentication (TESLA) -- a source authentication mechanism
   for multicast or broadcast data streams -- with IPsec ESP.  In
   addition to the source authentication using TESLA, group
   authentication of the ESP packet can be provided using a shared
   symmetric group key.  Thus, the proposed extension to ESP combines



Dondeti & Canetti        Expires August 28, 2007                [Page 1]


Internet-Draft                 IPsec TESLA                 February 2007


   group secrecy, group authentication, and source authentication
   transforms in an ESP packet.

Contributors

   Adrian Perrig, Ran Canetti, and Bram Whillock were the original
   contributors of the TESLA work.  Mark Baugher, Ran Canetti, Pau-Chen
   Cheng and Pankaj Rohatgi were the original contributors to the
   multicast ESP transform design.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Notes on IPsec ESP and TESLA . . . . . . . . . . . . . . . . .  4
   4.  IPsec ESP Packet Format with TESLA . . . . . . . . . . . . . .  4
     4.1.  On the IPsec ICV in TESLA Protected ESP packets  . . . . .  6
   5.  Cryptographic Algorithms for IPsec ESP with TESLA  . . . . . .  7
   6.  Sender Processing of TESLA Protected Packets . . . . . . . . .  7
   7.  Receiver Processing of TESLA Protected Packets . . . . . . . .  8
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 12























Dondeti & Canetti        Expires August 28, 2007                [Page 2]


Internet-Draft                 IPsec TESLA                 February 2007


1.  Introduction

   The IPsec Encapsulation Security Payload (ESP) [RFC4303] transform
   provides a set of security services that include data origin
   authentication, which enables an IPsec receiver to validate that a
   received packet originated from a peer-sender in a pairwise security
   association (SA).  A Message Authentication Code (MAC) based on a
   symmetric key is the common means to provide data origin
   authentication for pairwise IPsec SAs.  However, for secure groups
   such as IP multicast groups, a MAC supports only "group
   authentication" and not data origin authentication.  This document
   specifies a ESP data origin authentication transform based on TESLA
   for source authentication of data sent to groups of receivers.

   The description of the TESLA protocol itself is available in RFC 4082
   [RFC4082].  The TESLA authentication itself is protected from DoS
   attacks by an external authentication transform using a symmetric-key
   based MAC.  Thus senders first source authenticate a packet and then
   protect it with group authentication.  The receivers verify the
   external MAC to rule out any attacks from parties outside of the
   secure group and then proceed to verify that the message originated
   from the claimed source following the TESLA procedures.


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].
   In addition, the following terms are defined and used in this
   document:

   Group Secrecy (GS):  Group Secrecy ensures that transmitted data is
      accessible only to group members.  This is often used as the means
      to enforce access control.  A typical realization of GS is to
      encrypt data using a key known only to group members.
      Essentially, the solution for group secrecy is the same as the
      solution for two party confidential communication.

   Group Authentication (GA):  The GA functionality enables a group
      member to verify that the received data originated from someone in
      the group and was not modified en-route by a non-group member.
      Note that group authentication by itself does not identify the
      source of the data.  For example, the data might have been forged
      by any malicious group member.  GA can be efficiently realized
      using standard shared key authentication mechanisms such as
      Message Authentication Codes (MACs), e.g., CBC-MAC or HMAC.




Dondeti & Canetti        Expires August 28, 2007                [Page 3]


Internet-Draft                 IPsec TESLA                 February 2007


   Source and Data Authentication (SrA):  The SrA functionality enables
      a group member to verify that the received data originated from
      the claimed source and was not modified en-route by anyone
      (including other group members).  Unlike Group Authentication, SrA
      provides the IPsec data origin authentication function.  SrA
      provides a much stronger security guarantee than GA in that a
      particular group member can be identified as a source of a packet.


3.  Notes on IPsec ESP and TESLA

   IPsec ESP provides confidentiality, integrity protection, replay
   protection and traffic flow confidentiality.  Integrity protection
   may be provided using symmetric keys or digital signatures [RFC4359].
   For unicast communication, integrity protection using either
   mechanism provides data origin authentication.  In case of multicast
   or group communication, symmetric-key based integrity protection
   supports group authentication only.  For source authentication of
   multicast streams, the sender may sign every packet [RFC4359], use
   TESLA or another source authentication mechanism.

   TESLA uses symmetric key chain commitment, delayed disclosure of a
   key from the key chain, and loose time synchronization between the
   sender's and the receivers' clocks to support source and data origin
   authentication.  The delayed disclosure of keys from the key chain
   implies that the receivers must buffer packets until the
   authentication can be verified.  To avoid denial of service attacks
   taking advantage of this buffering requirement, TESLA protected
   packets may be further protected using group authentication of
   packets.  That limits any such denial of service attacks to from
   members of the secure group.

   TESLA receivers may be bootstrapped using a digitally signed
   broadcast message containing the commitment to a key chain, local
   time, disclosure delay and other TESLA parameters from the sender or
   via individual registration processes with the sender.  Bootstrapping
   of TESLA is out of scope for this document.  The key management
   protocol that establishes the IPsec SA can be used for bootstrapping
   TESLA at the receivers.


4.  IPsec ESP Packet Format with TESLA

   In the following we first describe the TESLA authentication fields,
   followed by a depiction of where the those fields fit in an IPsec ESP
   packet.  Figure 2 also shows the coverage of encryption (when the
   encryption algorithm is non-NULL), IPsec integrity protection (IPsec
   ICV), and the TESLA MAC.



Dondeti & Canetti        Expires August 28, 2007                [Page 4]


Internet-Draft                 IPsec TESLA                 February 2007


   The TESLA Authentication Fields are as follows:

   o  Id i of K_i (OPTIONAL) -- The 32-bit Id of the key used to compute
      the TESLA-MAC of the current packet: Within the TESLA tag, the Id
      i of K_i MAY be sent with the MAC of the message M computed using
      K_i.  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.

   o  Disclosed Key K_(i-d) -- Variable length disclosed key is
      MANDATORY and is used to authenticate previous packets from
      earlier time intervals.

   o  TESLA MAC (K'_i, M): Variable length, MANDATORY.  TESLA MAC is
      computed using the key K'_i (derived from K_i) [RFC4082], which is
      disclosed in a subsequent packet (in the Disclosed Key field).
      The MAC coverage is shown in Figure 2.


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


                  Figure 1: TESLA Authentication Fields.

   TESLA authentication fields are added to IPsec ESP packets as shown
   in Figure 2.
















Dondeti & Canetti        Expires August 28, 2007                [Page 5]


Internet-Draft                 IPsec TESLA                 February 2007


      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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
    |               Security Parameters Index (SPI)                 |  ^
  --+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  ^ |                      Sequence Number                          |  |
  | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- I
  T |                    IV (optional)                              |^ P
  E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| s
  S |                    Rest of Payload Data  (variable)           |E e
  L ~                                                               ~N c
  A |                                                               |C
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R I
  M |               |         TFC Padding * (optional, variable)    |Y C
  A +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P V
  C |                         |        Padding (0-255 bytes)        |T |
  | +-+-+-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
  v |                               |  Pad Length   | Next Header   |v |
  --+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
    ~            TESLA Authentication Fields   (variable)           ~  v
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
    ~             Integrity Check Value-ICV   (variable)            ~
    +---------------------------------------------------------------+



      Figure 2: IPsec ESP Packet Format with TESLA MAC and IPsec ICV

   In the figure,

   o  The label "Encyrpt" indicates the coverage of IPsec encryption.
      It is the same as that described in the IPsec ESP specification
      [RFC4303].

   o  The label "IPsec ICV" indicates IPsec ESP's ICV coverage.  Whether
      the ICV is present and its coverage of the fields of the IPsec
      packet is as specified in the ESP specification.

   o  The label "TESLA MAC" indicates the TESLA MAC coverage.  The TESLA
      MAC protects the IPsec ESP packet starting with the Sequence
      number and ending with the Next Header field.

4.1.  On the IPsec ICV in TESLA Protected ESP packets

   IPsec ESP mandates the presence of an Integrity Check Value (ICV),
   except when combined mode algorithms are used to protect the packet
   and the ICV is part of the combined mode algorithm.  In case of CCM,
   the ICV is encrypted and only parseable at the receiver after



Dondeti & Canetti        Expires August 28, 2007                [Page 6]


Internet-Draft                 IPsec TESLA                 February 2007


   decryption.  With TESLA protection of a packet, technically an ICV is
   not required for integrity protection of the packet.  However, as
   noted above, a symmetric-key based ICV has the advantage of
   protecting against some DoS attacks on TESLA, so ICV is REQUIRED to
   be present in ESP-TESLA.


5.  Cryptographic Algorithms for IPsec ESP with TESLA

   TESLA needs a PRF algorithm to derive keys in the key chain.  TESLA
   PRF algorithm is specified through the key management protocol that
   distributes the ESP SA.

   The TESLA MAC algorithm is also specified through the key management
   protocol.  There is no reason for this algorithm to be different from
   the IPsec ICV algorithm.  When the TESLA MAC algorithm is not
   explicitly specified, the receivers are REQUIRED to use the IPsec ICV
   algorithm to compute the TESLA MAC algorithm.

   In the single sender group communication, all encryption algorithms
   that are appropriate for unicast communication are also suitable for
   secure group communication.  In the multi-sender communication case,
   the counter mode algorithms must be used as specified in .
   [I-D.weis-esp-group-counter-cipher]


6.  Sender Processing of TESLA Protected Packets

   In addition to the steps in [RFC4303], the sender follows the steps
   below for TESLA protected packets:

   o  The sender determines the current TESLA time interval i.  The
      sender may include the time interval i in the message.

   o  It then includes the TESLA Key, K_(i-d), where d is the TESLA
      disclosure delay.

   o  Next, it computes the TESLA MAC over the IPsec ESP packet,
      starting at the Sequence Number field and ending with the Next
      Header field, using the TESLA Key K_i.  That key itself SHALL NOT
      be disclosed until the TESLA interval i+d.

   o  The sender includes all the TESLA Authentication Fields after the
      Next Header field of the ESP packet and proceeds to compute the
      IPsec ICV over the entire ESP packet excluding the ICV field
      itself.





Dondeti & Canetti        Expires August 28, 2007                [Page 7]


Internet-Draft                 IPsec TESLA                 February 2007


7.  Receiver Processing of TESLA Protected Packets

   Receiver processing of TESLA packets contains the following steps.
   Note that the symmetric key MAC or the group MAC verification is
   similar to the MAC verification process specified in Section 3.4.4 of
   [RFC4303].  We limit the specification below for TESLA MAC
   verification.

   o  When a receiver receives an ESP packet with TESLA fields, it must
      first check to see that the time interval of the message does not
      violate the security conditions for the keys used.  The message is
      buffered, and the receiver attempts to authenticate any messages
      which are authenticated using K_(i-d), i.e., messages received
      with the index i-d.

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

   o  When the receiver receives a TESLA protected ESP packet, it first
      needs to verify whether the packet is safe, which is to verify
      that the key used to compute the MAC of the packet was still
      secret upon packet arrival.  For the verification, 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.  The "safe
      packet test" is explained in detail in Section 3.5 of [RFC4082].

   o  Once the receiver has determined i, it checks K_(i-d) against the
      most recently stored key, K_c.  If i-d=c then the receiver does
      nothing.  Otherwise it 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 buffered messages 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).  If K_(i-d) is not authentic,
      the receiver discards the received message.  If the MAC
      verification on any individual buffered packet fails, the receiver
      discards that buffered packet.

   o  Note, that if i-d < c the packet would have been unsafe and
      discarded before this step.

   o  After the TESLA MAC has been verified, the receiver updates the
      replay window.






Dondeti & Canetti        Expires August 28, 2007                [Page 8]


Internet-Draft                 IPsec TESLA                 February 2007


8.  Security Considerations

   This document specifies the use of a source authentication scheme
   TESLA with IPsec ESP.  TESLA provides source authentication using a
   symmetric key MAC but relies on loose time synchronization and
   delayed MAC key disclosure.  The scheme is safe as long as receivers
   can estimate an upper bound on the sender's time and accept packets
   only if there is a local assurance that the sender has not revealed
   the MAC key used to authenticate the received packet.  To that end,
   the security considerations in [RFC4082] apply.

   A group member cannot authenticate the source of the packet for a
   multicast group where multiple members share the MAC key.  Thus, a
   rogue member of the group has all the keying material needed to
   impersonate a sender of the group if that attacker is able to inject
   packets into the network using that sender's IP address.  TESLA-ESP
   addresses this problem by augmenting the IPsec ICV with the TESLA MAC
   protection.  Source authentication schemes leave multicast receivers
   vulnerable to DoS attacks if the receiver is duped into performing
   computationally-expensive validation of bogus packets or buffering of
   bogus packets.  An IPsec ICV is RECOMMENDED to accompany the TESLA
   MAC so as to limit the effectiveness of bogus packets sent by non-
   group members.

   Unfortunately, group members are still capable of sending packets
   with a valid external-authenticating MAC and invalid TESLA MAC, i.e.,
   any group member can launch a DoS attack.  In this case, the IPsec
   ICV verification will succeed only to have the TESLA MAC verification
   to fail.

   The new transform includes the ESP sequence number in the TESLA MAC
   to protect against a replay attack by a group member.  When the TESLA
   MAC is used, however, the ESP receiver MUST validate both the
   authentication tags before updating the ESP replay window.


9.  IANA Considerations

   IANA considerations associated with this work will appear in future
   version of this document.


10.  References

10.1.  Normative References

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



Dondeti & Canetti        Expires August 28, 2007                [Page 9]


Internet-Draft                 IPsec TESLA                 February 2007


   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

10.2.  Informative References

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

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

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

   [I-D.weis-esp-group-counter-cipher]
              McGrew, D. and B. Weis, "Using Counter Modes with
              Encapsulating Security Payload (ESP) and  Authentication
              Header (AH) to Protect Group Traffic",
              draft-weis-esp-group-counter-cipher-00 (work in progress),
              October 2006.


Authors' Addresses

   Lakshminath Dondeti (editor)
   QUALCOMM, Inc.
   5775 Morehouse Dr
   San Diego, CA
   USA

   Phone: +1 858-845-1267
   Email: ldondeti@qualcomm.com













Dondeti & Canetti        Expires August 28, 2007               [Page 10]


Internet-Draft                 IPsec TESLA                 February 2007


   Ran Canetti
   IBM Research
   30 Saw Mill River Rd
   Hawthorne, NY
   USA

   Phone:
   Email: canetti@watson.ibm.com











































Dondeti & Canetti        Expires August 28, 2007               [Page 11]


Internet-Draft                 IPsec TESLA                 February 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).





Dondeti & Canetti        Expires August 28, 2007               [Page 12]


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