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]