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]
