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

Versions: 00 01

Architecture of Long term                                     T. Gondrom
archiving with non-repudiation and                 Open Text Corporation
integrity protection                                    October 16, 2006
Internet-Draft
Intended status: Experimental
Expires: April 19, 2007


                           LTANS Architecture
                        draft-ietf-ltans-ari-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 April 19, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This documents outlines best practices how to use and integrate
   components based on the various specifications prepared by the LTANS
   WG for long term archiving and non-repudiation services can work
   together in a best practices environment.  It especially takes care
   of the overall architecture and integration of the protocol and the
   data structures.



Gondrom                  Expires April 19, 2007                 [Page 1]


Internet-Draft                     ARI                      October 2006


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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  General Architecture Overview  . . . . . . . . . . . . . . . .  3
   3.  Implementation details . . . . . . . . . . . . . . . . . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     5.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10
































Gondrom                  Expires April 19, 2007                 [Page 2]


Internet-Draft                     ARI                      October 2006


1.  Introduction

1.1.  Motivation

   Over the last months various implementstations of the specifications
   of the LTANS drafts have been build.  And as the current
   specifications come to their final state, an architectural
   information about how to best integrate these specifications and how
   to best build such an archive system seems helpful.

   After ERS and LTAP have specified the necessary to standards for the
   protocol and the data structures for such a service this document
   only has informational character helping to understand and follow
   best practices on how to design such a system and combine the variosu
   drafts for maximum effect.

   The certain weaknesses identied in some of today's most common hash
   algorithms like SHA-1 also make it clear that a protection of the
   integrity of data after the compromise of a specific hash algorithm
   is of elemtary importance to society.  Considering that in case one
   of the today in digital signatures used hash algorithms might loose
   its security attributes (by. e.g. cryptoanalysis attacks showing that
   the collision resistance can no longer be guaranteed, will put all
   today already signed messages and data at risk.  This can e.g. also
   hit data that only needed simple integrity protection by applying
   timestamps as defined by RFC3161.


2.  General Architecture Overview

   The central design principle in electronic archiving is to provide a
   simple identification for an electronic data object.  Any user who
   knows this id and has the proper authorization can at a later point
   in time access the digital object from any place in the world.

   This of course has certain implications for the data.

   1.  Availability: How long shall the data be stored

   2.  Integrity: is the object still the one that has been entrusted to
       the electronic archive?

       *  protect against modifications by the system or an attacker

       *  can the owner proof to another party that the data has not
          been altered since archiving (including not been altered by
          himself)?




Gondrom                  Expires April 19, 2007                 [Page 3]


Internet-Draft                     ARI                      October 2006


   3.  Confidentiality: how can the data best be protected against
       disclosure to e.g. service providers operating the system or
       during transmission of data to and from the archive?

   For the general system design it may also be considered how can the
   data later be found and retrived.  Is there additional metadata
   necessary and by which system is it handled best?

   Availability
   As nearly all data has only to be stored for a limited (although
   possibly very long) time and after this can be deleted, the system
   should deploy rules or configuration parameters when data can be
   removed and destroyed.  As the data also represents an important
   value to its users it is also necessary that retrieval and retention
   management employ a consistent access control management.

   System Architecture
   The genral server architecture of a LTANS archive service can follow
   several possible architecture concepts:

   1.  the LTANS archiving and signature renewal system can be managed
       as a stand-alone solution:
       Users submit data directly via LTAP to the service.  The system
       stores the documents and based on system policies manages the
       signature renewal and integrity protection.  In the most simple
       implementation the system may even not apply any actions
       automatically but always need the command of a responsible data
       owner to perform.  The minimum actions that may be needed to be
       performed are data storing, data retrieval, signature renewal and
       data delete.  In theory all these actions could also be requested
       by the user.  But usually a normal user does not know, e.g. when
       a specific algorithm is no longer secure and initiate a renewal
       in time.  In the best configuration this would be managed by the
       system.  And with the long storage times coming with electronic
       archiving the usual user may also not want to manage the data
       retention by himself but simply want to tell the system at the
       time of storage (or any later time) when to securely delete and
       irreversly destroy the stored data.  An example of a very simple
       client could e.g. be a WebDAV or File system like interface that
       directly speaks with the service via LTAP and stores all data
       with a predefined policy.  Server configuration and operations
       defines the used parameters, retention times and when a signature
       renewal is initiated.

   2.  The LTANS signature renewal service can also be loosely coupled
       with a normal archiving system.  This can have various
       implementations:




Gondrom                  Expires April 19, 2007                 [Page 4]


Internet-Draft                     ARI                      October 2006


       *  The service might be completely hidden by the normal archive
          system with two differnet techniques:
          the archive system may simply transfer all its data that shall
          be integrity protected by LTANS Evidence Records directly to
          the LTANS server via LTAP or it may keep its own data and only
          simply submit copies of data that needs the integrity
          protection and non-repudiation of the LTANS system via LTAP to
          the service.  With the second approach it may still use its
          own techniques for the normal operation and management and
          only in the case of the needed integrity and non-repudiation
          proof retrieve data via LTAP from the service and verify the
          evidence record.

       *  the service might be provided in parallel to the normal
          archive in a more complex system architecture.
          In such a case a client may access either the normal document
          management system/archive or also directly access the LTANS
          service via LTAP.  Documents may be directly tansferred from
          the normal document management system to the LTANS service for
          integrity protection and non-repudiation services.  Depending
          on the need of the user he requests data from the document
          management system or (if he requires a valid evidence reocrd
          for his data) directly accesses the LTANS archive service.
          The connection to these two services in parallel may make the
          integration in some parts easier as every system can
          specialize on its defined tasks but may raise issues of how to
          do access control.  In this case a ticketing system may be
          helpful where the user has to obtain a secure authorization
          ticket from the document management system or application to
          get access to the evidence record in the LTANS system.

   3.  The LTANS signature renewal can be directly integrated in an
       existing archiving system:
       In this case a commercial archiving system might simply add the
       functionality of applying timestamps and signature renewal to its
       backend storage system.  This can be done at two layers: Either
       in the archiving system or on if a more intelligent storage
       system (like e.g. in some commercial hard disk arrays) is used in
       the storage itself.  The advantage of the tight integration with
       an archiving system can be that existing infrastructure and
       management systems can be used, renewal and retention times can
       be based on metadata available to the overall system, the
       organization of the data on storage media and in data groups for
       the evidence record can also be determined (and optimized) by
       this metadata available to applications and document management
       systems.  This tight integration can result in various use cases
       for the LTAP protocol.  As most of the today existing document
       management systems already implemented their own proprietary or



Gondrom                  Expires April 19, 2007                 [Page 5]


Internet-Draft                     ARI                      October 2006


       open protocol it may be the case that the system only extends its
       own protocol with the LTAP functionality.  Or it may offer the
       LTAP protocol in parallel to it's own protocols for specific LTAP
       clients for non-repudiation and integrtity verification.  In the
       case that the LTANS service will be implemented on the storage
       level it may be that the storage verndors will implement th LTAP
       protocol for their data access layer which may impose very
       different requirements on LTAP implmentations than the normal
       software application oriented implementations.


3.  Implementation details

   An LTANS system consists in its minimum implementation of a sevice
   speaking the LTAP protocol, a data management system organizing the
   data by grouping, building hashtrees and executing renewal
   procedures, a storage media where the system keeps the initial
   documents (for the case of later Hashtree renewals) and the evidence
   records and a trusted time stamp source which would best be provided
   by an independent trusted third party.

   A client stores his to the system by using directly or indirectly
   (e.g. via a WebDAV client to file share).  As most systems already
   deploy their own access control management LTAP relies on the already
   existing infrastructure in this case and expects an authenticated and
   authorized request.  This may e.g. be done via a Kerberos or other
   implementation.

   The system receives the data and collects it.
   In case of digital signed documents it may in a first step verify
   these and also receive additinal necessary verification data from
   other sources as specified in the draft draft-ietf-ltans-validate.
   It is recommended to integrate any necessary verification data at
   this step into the document as e.g. specified in RFC3126 or to
   combine all necessary date for verification with the document and
   signatures themselves together in one container for storage and non-
   repudiation protection so that any later party can rely on the
   unbroken integrity and chain of custody for the documents and all the
   verification data since the time of archiving and redo the
   verification procedure based on the complete information as some of
   the verification information might be difficult to obtain at a later
   time, e.g. 30 years later.

   The specification of ERS relies as an example on time stamps based on
   RFC3161, but can explicitely also support and use other time stamping
   mechanisms that rely on certain basic mechanisms: Public key
   algorithms, using a trusted time source, and from a trusted third
   party (which may in some countries require an accreditation by a



Gondrom                  Expires April 19, 2007                 [Page 6]


Internet-Draft                     ARI                      October 2006


   government agency.  Such other time stamp sources may e.g. also be
   the Time stamp mechanism specified by ISO.

   Additionally to the verification data certain systems may require the
   storage of certain metadata additional with the document as the
   document may only be complete and understandable with this context
   (metadata information).  This can e.g. also be accomplished by
   storing document and metadata within one container, which can be the
   same or another container within the container of the docuemnht and
   the verification data.

   After the retrieval of the document and the possible enrichment of
   the data, the document or the container is stored in the system.  In
   the case that time stamps or signatures have been applied before the
   submission of the data, this data already has a certain level of
   evidence based on the security level of the used algorithms and
   procedures.  Instead of evaluating the algorithms used in the initial
   data, the system applies one initial archivetimestamp with its own
   secure timestamps and hash algorithms to "equalize" all data to a
   defined integrity and non-repudiation assurance level.  For this step
   the system groups all data within a hashtree and applies a timestamp
   it received from an external trusted third party.  Thhe frequency of
   this initial step may be configured in the system, some may require
   only a granularity of once per week, others with a high volume may
   execute this every hour or even shorter interval.  Current
   implementations have shown that the granularity of a daily initial
   ArchiveTimestamping seems an adequate protection.

   After this initial Archivetimestamp the system now knows the well
   defined algorithms it used during this step and will renew the
   archive timestamp (and together with this, all the data already
   stored in the container and signed or encrypted with other
   algorithms) if the algorithms of the initial Archivetimestamp get
   weak.

   The execution of renewal can be configured at the LTANS server or
   even manually executed before the algorithms used in the last
   Archivetimestamp of the ArchiveTimestampchain as specified in ERS get
   weak.

   The system stores data and the created archivetimestamps, later in
   the form of Evidence Record.  For better data management it is
   recommended to store them on the same type of media or even on the
   same media, as the stored data may be worthless without the Evidence
   Record and vice versa.

   At a later point in time the client may request the data or the
   Evidence record from the LTANS system.  A certain implementaion of



Gondrom                  Expires April 19, 2007                 [Page 7]


Internet-Draft                     ARI                      October 2006


   the LTANS system may even only implement an interface to retrieve the
   Evidence Record and not the the data itself which in such a
   configuration would have to be stored and kept by the user or client
   separately.  (For renewals due to identified weaknesses in used hash
   algorithms it is still necessary to store the data to the system so
   that a hashtree renewal as defined by ERS can be performed.)

   The client then verifies the received Evidence Record based on a
   defined archive policy (which defines which algorithm was considered
   secure for which period of time (begin and end) and which time stamp
   sources and verification data may be trustworthy).  This may be done
   automatically or also done manually by an expert (e.g. during a
   lawsuit).


4.  Security Considerations

   System design

   the system architecture raises a number of security questions
   especially in the area of access control and confidentiality as the
   security of a system can always only as strong as the security of the
   weakest part of the chain.


5.  References

5.1.  Normative References

   [ANSX995]  American National Standard for Financial Services,
              "Trusted Timestamp Management and Security", ANSX X9.95-
              2005, June 2005.

   [I180141]  ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1:
              Framework", ISO ISO-18014-1, February 2002.

   [I180142]  ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2:
              Mechanisms producing independent tokens", ISO ISO-18014-2,
              December 2002.

   [I180143]  ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3:
              Mechanisms producing linked tokens", ISO ISO-18014-3,
              February 2004.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", RFC 2026, 1996.

   [RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate



Gondrom                  Expires April 19, 2007                 [Page 8]


Internet-Draft                     ARI                      October 2006


              Requirement Levels", RFC 2119, 1997.

   [RFC3126]  Adams, C., Pinkas, D., Ross, J., and N. Pope, "Electronic
              Signature Formats for long term electronic signatures",
              RFC 3126, 2001.

   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
              "Internet X.509 Public Key Infrastructure Time-Stamp
              Protocol (TSP)", RFC 3161, August 2001.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              August 2001.

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

5.2.  Informative References

   [ETSI2003]
              European Telecommunication Standards Institute (ETSI),
              Electronic Signatures and Infrastructures (ESI);,
              "Algorithms and Parameters for Secure Electronic
              Signatures", ETSI SR 002 176 V1.1.1, March 2003.

   [MER1980]  Merkle, R., "Protocols for Public Key Cryptosystems,
              Proceedings of the 1980 IEEE Symposium on Security and
              Privacy (Oakland, CA, USA)", pages 122-134, April 1980.

   [REQ2004]  Wallace, C., Brandner, R., and U. Pordesch, "Long-term
              Archive Service Requirements", I-D ???, 2005.


Author's Address

   Tobias Gondrom
   Open Text Corporation
   Werner-von-Siemens-Ring 20
   Grasbrunn, Munich  D-85630
   Germany

   Phone: +49 (0) 89 4629-1816
   Fax:   +49 (0) 89 4629-33-1816
   Email: tobias.gondrom@opentext.com






Gondrom                  Expires April 19, 2007                 [Page 9]


Internet-Draft                     ARI                      October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

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

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

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


Acknowledgment

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





Gondrom                  Expires April 19, 2007                [Page 10]


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