Internet DRAFT - draft-kent-trans-monitor-auditor

draft-kent-trans-monitor-auditor



Public Notary Transparency                                      S. Kent
Internet Draft                                         BBN Technologies
Intended status: Standards Track                          D. Mandelberg
Expires: November 2016                                           K. Seo
                                                           May 24, 2016


   Certificate Transparency (CT) Requirements for Monitors and Auditors
                  draft-kent-trans-monitor-auditor-01.txt


Abstract

   This document establishes requirements for the Monitor and Auditor
   elements of the Certificate Transparency (CT) system, focusing on
   the Web PKI context.  It defines the functions performed by these
   system elements. This is a companion to the CT System Architecture
   document (draft-kent-trans-architecture).

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), 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 November 24, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.





Kent, et al.           Expires November 24, 2016               [Page 1]

Internet-Draft CT Requirements for Monitors and Auditors        May 2016


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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.

Table of Contents


   1. Introduction...................................................2
      1.1. Requirements Language.....................................3
   2. Monitor Requirements...........................................3
   3. Auditor Requirements...........................................6
      3.1. Checking MMD, STH Frequency Count and the Append-only
      property.......................................................7
      3.2. Checking for Consistency of Log Views.....................8
   4. Security Considerations........................................8
   5. IANA Considerations............................................9
   6. References.....................................................9
      6.1. Normative References......................................9
      6.2. Informative References...................................10
   7. Acknowledgments...............................................10

1. Introduction

   Certificate Transparency (CT) is a set of mechanisms designed to
   deter, detect, and facilitate remediation of certificate mis-
   issuance. The Monitor element of CT detects mis-issuance by
   performing the operations described in Section 2 below, notifying
   the CT-aware Subjects that it serves. The Auditor element of CT
   detects misbehavior of logs, and notifies the Monitors that it
   serves, so that these Monitors can perform their functions reliably.

   A Monitor observes a set of logs to detect certificate mis-issuance.
   A Monitor notifies a Subject [CA-Subject] when a bogus (or
   erroneous) certificate [draft-ietf-trans-threat-analysis] has been
   issued on behalf of that Subject. Every CT-aware Subject is expected
   to either perform self-Monitoring or to arrange with a third-party
   Monitor to detect mis-issued certificates on behalf of the Subject.

   A Monitor performs its function by examining all entries from a set
   of logs and comparing these entries to reference data for a set of
   one or more Subjects. The reference data consists, at a minimum, of
   a list of Subject and Subject Alternative Names and the pubic key
   information associated with each, supplied by the Subject. If a
   Monitor detects a log entry for a certificate that is inconsistent


Kent, et al.           Expires November 24, 2016               [Page 2]

Internet-Draft CT Requirements for Monitors and Auditors        May 2016


   with the reference data for a Subject, the Monitor notifies the
   Subject. A Subject may perform self-monitoring.

   An Auditor interacts with a log to detect misbehavior of the log.
   When it detects misbehavior, an Auditor notifies Monitors that have
   arranged for such notification. Because Browser Vendors supply log
   metadata in their browsers, each is expected to operate an Auditor,
   or to arrange to receive notifications of log misbehavior from
   Auditors, or both. (See [Browser-vendor] for additional details.)

   An Auditor detects log misbehavior by performing checks on log
   entries and Signed Tree Heads (STHs) [6962-bis]. One form of
   misbehavior (see Section 3 below) requires communication among
   Auditors and, perhaps, other CT system elements, and is not yet
   fully specified.

1.1. Requirements Language

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

2. Monitor Requirements

   As noted above, a Monitor observes a set of logs, looking for log
   entries of "interest". A Subject may act as a self-monitor, or may
   make use of the services of a third-party Monitor. In the self-
   monitoring context, the log entries of interest are ones that
   contain a Subject or Subject Alternative Name (SAN) associated with
   the Subject's web site(s). In the third-party Monitor context, the
   log entries of interest are the ones specified by its clients. Each
   client of a third party Monitor supplies the Monitor with a list of
   Subject names and SANs associated with the client's web site(s), and
   public key information associated with each name. Additionally, if
   the client intends to log name-constrained CA certificate(s) as
   described in Section 4.3 of [6962-bis], the client supplies the
   Monitor with a list of permitted dNSNames, and public key
   information associated with each name. The Monitor watches a set of
   logs looking for entries that match the client certificates of
   interest. A Certification Authority (CA) MAY operate a Monitor on
   behalf of the Subjects to which it issues certificates [CA-Subject].
   In this case, the Monitor has access to the reference information
   needed to detect mis-issued certificates (relative to those issued
   by this CA).

   The means by which a Subject or Monitor determines which set of logs
   to watch is outside the scope of the CT specifications. It is


Kent, et al.           Expires November 24, 2016               [Page 3]

Internet-Draft CT Requirements for Monitors and Auditors        May 2016


   anticipated that there will be a small number of logs that are
   widely used, and that the metadata for these logs [6962-bis] will be
   available from browser vendors [browser-vendor]. It is RECOMMENDED
   that third-party Monitors make public the set of logs that they
   watch, and the set of third-party Auditors they rely upon, to help
   clients decide which third-party Monitor(s) to use.

   A Monitor (self or third-party) that is observing a log periodically
   queries the log to determine if there is a new STH, using the get-
   sth interface (see Section 6.3 of [6962-bis]). When a new STH is
   detected, the Monitor then uses the get-entries interface to the log
   (see Section 6.7 of [6962-bis]) to retrieve all new log entries
   (relative to the previous STH acquired by the Monitor). (This
   command requires the Monitor to indicate the start and end entries,
   by index, data that is provided by get-sth.) The Monitor examines
   each log entry to determine if it is of interest:

     1. certificates with fully-specified DNS names - If the Subject or
        SAN is on the list of names of interest, the Monitor checks to
        see if the public key in the certificate matches the public key
        for the specified name(s).  If it does not match, then the
        certificate is deemed mis-issued.
     2. wildcard certificate log entries - If a Monitor encounters a
        log entry for a name-redacted certificate (Section 4.2 in
        [6962-bis]), it compares the non-redacted part of the name in
        the log entry against the list of names of interest. If a match
        is found, the Monitor then compares the certificate's public
        key to the public key for the name. If the public key in the
        log entry does not match, the certificate is deemed mis-issued.
     3. name-constrained CA certificates - If any of the dNSNames in
        the permittedSubtrees field is an ancestor of or equal to a
        name of interest, the Monitor checks to see if the public key
        in the certificate matches a public key which has been
        authorized for use in a name-constrained CA for the specified
        name(s).

   For any certificate deemed mis-issued, a third-party Monitor
   contacts the Subject and forwards the log entry, along with log
   metadata. (This step doesn't apply to the case of a self-monitoring
   Subject). The Subject contacts the CA that issued the certificate
   (using the Issuer name in the certificate) and requests revocation
   of the mis-issued certificate, to remedy the problem. The means by
   which a Subject determines how to contact a CA based on the issuer
   name is outside the scope of this specification.





Kent, et al.           Expires November 24, 2016               [Page 4]

Internet-Draft CT Requirements for Monitors and Auditors        May 2016


   <This document does not address syntactic mis-issuance. If the WG
   agrees that this is part of the scope of mis-issuance, as per the
   threat model, appropriate text will be added.>

   A Monitor MAY retain its own copies of log entries, but it is not
   required to do so. Local caching of log entries would be useful for
   a third party Monitor that acquires a new client, since the Monitor
   could examine the older entries for certificates that are now of
   interest. For a self-Monitor, maintaining a cache of old log entries
   may not be useful and may represent a storage burden.

   Note that the Monitor function, as described above, does not try to
   detect mis-behavior by a log. That is the responsibility of an
   Auditor, as described in Section 3. A system operating as a Monitor
   MAY incorporate some or all of the Auditor functions or it MAY make
   use of third-party Auditors. Because a Monitor relies on logs to
   behave properly in order to perform its function, every Monitor MUST
   acquire Auditor reports for every log that it observes. The means by
   which Subjects determine the set of functions provided by a third-
   party Monitor is not defined by this document; it may be described
   in a future Monitor API specification.

   CT does not include any mechanisms designed to detect misbehavior by
   a Monitor. A self-Monitor does not require such mechanisms; Subjects
   who elect to rely upon third-party Monitors would benefit from such
   mechanisms.

   Figure 1 illustrates the interactions between a Monitor and the
   other elements of the CT system.




















Kent, et al.           Expires November 24, 2016               [Page 5]

Internet-Draft CT Requirements for Monitors and Auditors        May 2016


               +----+
               | CA |<*********************
               +----+                     *
                  ^                       *
                  *                       *
                  v                       *
               +---------+                *
               | Subject |<*************  *
               +---------+             *  *
                  ^   ^                *  *
                  *   *******          *  *
                  v         *          *  *
               +---------+  *          *  *
               | Browser |  *          *  *
               +---------+  *          *  *
                  ^         *          *  *
                  *         *          *  *
                  v         v          *  *
               +----------------+      *  *
               | Browser Vendor |<***  *  *
               +----------------+   *  *  *
                                    v  v  v
   +-----+                        +---------+
   | Log |<---------------------->| Monitor |
   +-----+                        +---------+
                                       ^
                                       *
                                       v
                                  +---------+
                                  | Auditor |
                                  +---------+

   Legend:
   <---> Interface defined by CT
   <***> Interface out of scope for CT

        Figure 1 Monitor Interactions with other CT System Elements

3. Auditor Requirements

   Auditors perform checks intended to detect mis-behavior by logs.
   There are four log behavior properties that Auditors check:

     1. The Maximum Merge Delay (MMD)
     2. The STH Frequency Count
     3. The append-only property
     4. The consistency of the log view presented to all query sources


Kent, et al.           Expires November 24, 2016               [Page 6]

Internet-Draft CT Requirements for Monitors and Auditors        May 2016


   The first three of these checks are easily performed using existing
   log interfaces and log metadata, as described below. The last check
   is more difficult to perform because it requires a way to share log
   responses among a set of CT elements, perhaps including browsers,
   web sites, Monitors, and Auditors, e.g., so-called gossiping
   [Gossip]. There is as yet no standard for gossiping and thus the
   last check is NOT required of Auditors at this time.

               +---------+
               | Monitor |
               +---------+
                    ^
                    *
                    v
   +-----+     +---------+
   | Log |<--->| Auditor |
   +-----+     +---------+
                 ^     ^
                 #     #
                 V     v
         +---------+ +---------+
         | Browser | | Subject |
         +---------+ +---------+

   Legend:
   <---> Interface defined by CT
   <***> Interface out of scope for CT
   <###> Interface proposed by [Gossip]; not yet part of CT standards

        Figure 2 Auditor Interactions with other CT System Elements

3.1. Checking MMD, STH Frequency Count and the Append-only property

   Checking that a log is behaving correctly with regard to MMD, STH
   Frequency Count and Append-only property MUST be performed using the
   algorithms described in Sections 9.3 and 9.4 of [6962-bis] (or an
   algorithm that yields identical results):

     1. The MMD for a log is the maximum time that may elapse between
        the time that an SCT is issued and a log entry is created. When
        an Auditor executes the algorithm in Section 9.3 of [6962-bis],
        Step 7 enables it to detect when the MMD has been exceeded for
        the certificate append that triggered the new STH. The
        Auditor's polling period SHOULD be chosen to be small relative
        to the MMD in order to maximize the chance of successful
        detection of an MMD violation.



Kent, et al.           Expires November 24, 2016               [Page 7]

Internet-Draft CT Requirements for Monitors and Auditors        May 2016


     2. To prevent the use of an STH to identify an individual log
        client, a log MUST NOT generate an STH more frequently than is
        declared in the log metadata. To verify that a log is not
        violating this guarantee, when an Auditor executes the
        algorithm in Section 9.3 of [6962-bis], Step 5 enables it to
        determine how long it has been since the STH changed and to
        detect if this period is shorter than the minimum required. The
        Auditor's polling period SHOULD be chosen to be more frequent
        than the minimum frequency in order to maximize the chance of
        successful detection of too frequent generation of STHs.
     3. In order to verify the append-only property, an Auditor
        executes the algorithm as described in Section 9.4.2 of [6962-
        bis].



3.2. Checking for Consistency of Log Views

   In order for an Auditor to verify that a log provides a consistent
   view to all query sources, the Auditor needs to see the results of
   queries to the log from a broad range of requesters. In principle
   this could be accomplished using a gossip protocol that has the
   following constraints:

     1. TLS clients are not expected to interact directly with a Log
        for performance and privacy reasons (see [Browser-vendor]).
     2. TLS clients generally do not communicate directly with one
        another (with a few exceptions). As such, a gossip protocol
        would be easier to deploy if it does not rely on direct
        communication among TLS clients.
     3. If TLS clients have to acquire and distribute CT information
        about the web sites they visit, this should not overburden the
        browsers, Subject web sites, or Logs.

4. Security Considerations

   CT is a system created to improve security for X.509 public key
   certificates, especially in the Web PKI context. An attack analysis
   [draft-ietf-trans-threat-analysis] examines the types of attacks
   that can be mounted against CT, to effect mis-issuance, and how CT
   addresses (or fails to address) each type of attack. That analysis
   is based on the architecture described in this and other documents,
   and thus readers of this document are referred to that one for a
   thorough discussion of the security aspects of CT. Briefly, CT logs
   represent a viable means of deterring semantic mis-issuance of
   certificates. Monitors are an effective way to detect semantic mis-
   issuance of logged certificates. The CT architecture enables


Kent, et al.           Expires November 24, 2016               [Page 8]

Internet-Draft CT Requirements for Monitors and Auditors        May 2016


   certificate Subjects to request revocation of mis-issued
   certificates, thus remedying such mis-issuance.

   Residual vulnerabilities exist with regard to some forms of Log,
   Auditor and Monitor misbehavior, because the architecture does not
   include normative means of detecting such behavior. For example:

     1. The CT architecture does not incorporate a means to detect
        misbehavior by a third-party Monitor. This is a residual
        vulnerability for Subjects. A Subject may mitigate this
        vulnerability by performing self-monitoring or by becoming a
        client of more than one third-party Monitor.
     2. An Auditor can fail to report misbehavior by a log when such
        misbehavior occurs. To detect this, a Monitor can make use of
        multiple Auditors, or can perform Audit functions on its own
        behalf.
     3. Until a mechanism is standardized to detect logs that provide
        split views to different log clients, this form of log
        misbehavior may go undetected for an extended period.

   The current design does not ensure the ability of Monitors to detect
   syntactic mis-issuance of certificates. This is because provisions
   for asserting the type of certificate being issued, for inclusion in
   an SCT, have not been standardized.

5. IANA Considerations

   <TBD>

6. References

6.1. Normative References

   [Merkle] Merkle, R. C. (1988). "A Digital Signature Based on a
             Conventional Encryption Function." Advances in Cryptology
             - CRYPTO '87. Lecture Notes in Computer Science 293. p.
             369

   [6962-bis]  Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
             Stradling, "Certificate Transparency," draft-ietf-trans-
             rfc6962-bis-11 (work in progress), November 2015.

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

   [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.2", RFC 5246, August 2008.


Kent, et al.           Expires November 24, 2016               [Page 9]

Internet-Draft CT Requirements for Monitors and Auditors        May 2016


   [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
             Extensions: Extension Definitions", RFC 6066, January
             2011.

   [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
             Galperin, S., and C. Adams, "X.509 Internet Public Key
             Infrastructure Online Certificate Status Protocol - OCSP",
             RFC 6960, June 2013.

   [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
             Multiple Certificate Status Request Extension," RFC 6961,
             June 2013.

6.2. Informative References

   [draft-ietf-trans-threat-analysis] Kent, S., "Attack Model and
             Threat for Certificate Transparency," draft-ietf-trans-
             threat-analysis-03 (work in progress), October 2015.

   [Gossip] Nordberg, L., Gillmor, D., and Ritter, T., "Gossiping in
             CT," draft-ietf-trans-gossip-01 (work in progress),
             October 2015.

   [Browser-vendor]  Mandelberg, D. and S. Kent, "Certificate
             Transparency (CT) Browser Requirements," draft-dseomn-
             trans-browsers-00 (work in progress), November 2015.

   [CA-Subject]   TBD

7. Acknowledgments

   <TBD>

















Kent, et al.           Expires November 24, 2016              [Page 10]

Internet-Draft CT Requirements for Monitors and Auditors        May 2016


   Authors' Addresses

   Stephen Kent
   BBN Technologies
   10 Moulton St.
   Cambridge, MA  02138
   US

   Email: kent@bbn.com


   David Mandelberg

   Email: david@mandelberg.org


   Karen Seo

   Email: kseo@alum.mit.edu






























Kent, et al.           Expires November 24, 2016              [Page 11]