Network Working Group T. Gondrom Internet-Draft July 12, 2010 Intended status: Informational Expires: January 13, 2011 LTANS Architecture draft-ietf-ltans-ari-01 Abstract This document 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. 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 13, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Gondrom Expires January 13, 2011 [Page 1] Internet-Draft ARI July 2010 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. General Architecture Overview . . . . . . . . . . . . . . . . 3 3. ERS and XMLERS . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Hot to verify a combination of ERS and XMLERS . . . . . . 6 4. Protocols and DSSC . . . . . . . . . . . . . . . . . . . . . . 6 5. Implementation details . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Gondrom Expires January 13, 2011 [Page 2] Internet-Draft ARI July 2010 1. Introduction 1.1. Motivation Over the last years various implementations 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, XMLERS, ERS-SCVP and DSSC 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 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 one of 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 until 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 January 13, 2011 [Page 3] Internet-Draft ARI July 2010 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 retrieved. 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 any simple protocol (e.g. HTTP, WebDAV, or others) 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 initiate them. 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 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 January 13, 2011 [Page 4] Internet-Draft ARI July 2010 * 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 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 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 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. 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 ensure 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 if a more intelligent storage system (like e.g. in some commercial hard disk arrays) is used in the storage itself. The advantage of a tighter 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 integration can result in various use cases for the specific protocols. As most of the today existing document management systems already implemented their own proprietary or open protocol it may be the case that the system only extends its Gondrom Expires January 13, 2011 [Page 5] Internet-Draft ARI July 2010 own protocol with the ERS functionality. Or it may offer a second protocol extension in parallel to it's own protocols for specific 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 vendors will implement a protocol for their data access layer which may impose very different requirements than the normal software application oriented implementations. 3. ERS and XMLERS The Evidence Records provided by ERS and XMLERS provide evidence records in ASN.1 and XML. They both follow identical design principles and provide the same level of security. But as the signature renewal process also must involve and includes parts of the byte representation of the data structures which are used, there is no bidirectional transformation from one format to the other. In general a system willeither implement ERS (using the ASN.1 format) or XMLERS (using XML). However as the renewal and protection process applies to data independent of the used data containers and formats it is possible to store ERS in systems using XMLERS and vice versa. But a verification process would in these cases be more complex and require a system supporting both standards. 3.1. Hot to verify a combination of ERS and XMLERS tbd 4. Protocols and DSSC tbd 5. Implementation details An LTANS system consists in its minimum implementation of a sevice speaking a basic transfer protocol (e.g. HTTP or WebDAV), 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 the used protocol can rely Gondrom Expires January 13, 2011 [Page 6] Internet-Draft ARI July 2010 on the already existing infrastructure with authenticated and authorized requests. 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 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 Gondrom Expires January 13, 2011 [Page 7] Internet-Draft ARI July 2010 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 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). 6. 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. Gondrom Expires January 13, 2011 [Page 8] Internet-Draft ARI July 2010 7. References 7.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 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. 7.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. Gondrom Expires January 13, 2011 [Page 9] Internet-Draft ARI July 2010 [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 Munich Germany Email: tobias.gondrom@gondrom.org Gondrom Expires January 13, 2011 [Page 10]