INTERNET-DRAFT J. M. Schanck Intended Status: Experimental Security Innovation & U. Waterloo Expires: [date] W. Whyte Security Innovation Z. Zhang Security Innovation 20 September 2015 Criteria for selection of public-key cryptographic algorithms for quantum-safe hybrid cryptography draft-whyte-select-pkc-qsh-00.txt Abstract Authenticated key exchange mechanisms instantiated with cryptosystems based on integer factorization, finite field discrete log, or elliptic curve discrete log, are believed to be secure now but are vulnerable to a harvest-then-decrypt attack where an attacker who cannot currently break the mechanism records the traffic anyway, then decrypts it at some point in the future when quantum computers become available. The Quantum-safe Hybrid approach is a modular design, allowing any authenticated key exchange mechanism to be protected against the harvest-then-decrypt attack by exchanging additional secret material protected with an ephemeral key for a quantum-safe public key cryptographic algorithm and including that secret material in the Key Derivation Function (KDF) run at the end of the key exchange. This approach has been proposed in TLS as the Quantum-safe Hybrid handshake mechanism for Transport Layer Security protocol (QSH_TLS). This document provides a guideline to criteria for selecting public key encryption algorithms approved for experimental use in the quantum safe hybrid setting. 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. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. Schanck et al. Expires 20 March 2016 [Page 1] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 [date]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Quantum Attacks on Cryptosystems . . . . . . . . . . . . . 4 2.1.1. Shor's algorithm . . . . . . . . . . . . . . . . . . . 4 2.1.2. Grover's algorithm . . . . . . . . . . . . . . . . . . 5 2.2. Harvest-then-decrypt attack . . . . . . . . . . . . . . . 5 2.3. Quantum-safe hybrid approach . . . . . . . . . . . . . . . 5 2.4. Symmetric algorithm . . . . . . . . . . . . . . . . . . . 6 2.5. Random bit generation . . . . . . . . . . . . . . . . . . 6 3. Selection Criteria . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Similar work . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Mandatory aspects . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Security levels . . . . . . . . . . . . . . . . . . . 7 3.2.2. Freely available specifications of the algorithm . . . 7 3.2.3. Freely available source code for a reference implementation . . . . . . . . . . . . . . . . . . . . 8 3.3 Desirable aspects . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. SUPERCOP implementation . . . . . . . . . . . . . . . 8 3.3.2. Constant-time implementation . . . . . . . . . . . . . 9 3.3.3. Standardization . . . . . . . . . . . . . . . . . . . 9 3.3.4. Patent and IP related issues . . . . . . . . . . . . . 9 4. Recommendations, justifications and considerations . . . . . . 9 4.1. Preliminary list of recommendations . . . . . . . . . . . 9 4.2. Schemes under consideration . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . . 14 Schanck et al. Expires 20 March 2016 [Page 2] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] 1. Introduction Quantum computers pose a significant threat to modern cryptography. The two most widely adopted public key cryptosystems, namely, RSA [PKCS1] and Elliptic Curve Cryptography (ECC) [SECG], will be broken by general purpose quantum computers. RSA is adopted in TLS from Version 1.0 to TLS Version 1.3 [RFC2246], [RFC4346], [RFC5246], [TLS1.3]. ECC is enabled in RFC 4492 [RFC4492] and adopted in TLS version 1.2 [RFC5246] and 1.3 [TLS1.3]. Those two primitives are the only public key cryptography that TLS relies on. Although these algorithms are currently believed to be secure, data encrypted using these algorithms is vulnerable to a "harvest-then- decrypt" attack where an attacker who cannot currently break the mechanism records the traffic anyway, then decrypts it at some point in the future when quantum computers become available. See section 2 for a detailed account of those attacks. The Quantum-safe Hybrid approach, which has a concrete proposal as the Quantum-safe Hybrid handshake for Transport Layer Security protocol (QSH_TLS) [QSHTLS], addresses this attack by introducing a quantum-safe public key encapsulation mechanism along with the classical authenticated handshake. QSH_TLS is a modular design that allows in principle for any quantum-safe encryption algorithm to be used in the hybrid approach. Since the IETF has not yet designated a single algorithm for use to provide quantum-safety, and since the quantum-safe algorithm used is intended to enhance security rather than being the only source of security, it is appropriate for there to be multiple algorithms that may be used in a quantum-safe hybrid setting. This provides an opportunity for implementers to compare different quantum-safe algorithms before the choice of a single one becomes vital. However, an algorithm should clearly satisfy some baseline set of criteria before it is approved for use in the quantum-safe hybrid setting, even if those criteria are more relaxed than they would be for selecting a single algorithm to rely on. This document specifies what those criteria are. The remainder of this document is organized as follows. Section 2 provides necessary background of the modular design of quantum-safe handshake for TLS. Section 3 specifies selection criteria. Section 4 provides a preliminary list of recommended encryption algorithms. Section 5 describes IANA considerations. This is followed by the lists of normative and informative references cited in this document, the authors' contact information, and Schanck et al. Expires 20 March 2016 [Page 3] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] statements on intellectual property rights and copyrights. 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]. Well-known abbreviations and acronyms can be found at RFC Editor Abbreviations List [REAL]. 2. Background 2.1. Quantum Attacks on Cryptosystems If there exists a general purpose quantum computer, any cryptosystem that is built on top of the mathematical hard problems of integer factorization, finite field discrete logarithm (DL), or elliptic curve discrete logarithm (ECDL) will be vulnerable. This includes RSA, DSA, DH, ECDH, ECDSA and other variants of these ciphers, including variants currently under consideration for standardization by CFRG and all public key cryptosystems used in TLS. A quantum computer may allow a real-time attack on the authentication within a handshake protocol, or may allow an attacker to decrypt previously recorded network traffic. It is not clear when quantum computers will become available. The EU has expressed in their Horizon 2020 project a desire for systems to be "quantum-ready" by 2020 [H2020]. Research groups have optimistically predicted practical and powerful quantum computer could become available by the same date [TPM15], which may be large enough to solve some instances of the elliptic curve discrete log problem that are currently secure. It is, however, clear that data exchanged today may be vulnerable to the harvest-then-decrypt attack described below. 2.1.1. Shor's algorithm Many of the hard problems used in public key cryptography can be reduced to the Hidden Subgroup Problem over a finite cyclic group. For an finite cyclic group G and finite set X, a function f : G -> X is said to hide a subgroup H if f(a) = f(b) iff a - b is in H. The Hidden Subgroup Problem (HSP) is to determine the hidden subgroup H given black box access to f. Shor's algorithm [SHOR97] is a probabilistic quantum algorithm that solves the HSP over any finite cyclic group in polynomial time. Among the problems that reduce to the HSP are the integer factorization and discrete logarithm problems that underly RSA, DSA, DH, ECDH, and ECDSA, hence all of these systems are vulnerable to quantum attacks. Schanck et al. Expires 20 March 2016 [Page 4] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] 2.1.2. Grover's algorithm Grover's algorithm [GROV96] is a probabilistic quantum algorithm that finds the unique input to a black box function that produces a particular output value. Compared with classical algorithms, Grover's algorithm finds the solution with a quadratic boost, i.e., within O(N^(1/2)) evaluations of the function, where N is the size of the function's domain. While an exact cost analysis of Grover's algorithm will depend crucially on architecture dependent parameters that are not currently available, it is a common belief among cryptographers that Grover's algorithm is effective against symmetric primitives [BRA98]. To be conservative we ignore constant factors and simply assume that Grover's algorithm finds preimages quadratically faster than classical brute force search. Likewise, we assume that Grover's algorithm reduces the time required to recover the key of a symmetric cipher by a quadratic factor. As an example, AES-256 provides 256 bits of security against classical computers, but is assumed to provide only 128 bits of security against quantum computers. 2.2. Harvest-then-decrypt attack The harvest-then-decrypt attack is a straightforward yet effective attack. In such an attack, the attacker stores encrypted data for long periods of time until legal, technological, or cryptanalytic means become available for revealing keys. Under the context of quantum computing, this attack becomes extremely powerful. TLS relies on RSA and ECC, both will be broken when quantum computer becomes available. Hence, any data encrypted now will be vulnerable to this attack. It is likely that it will be some time before breaks become so cheap that all harvested traffic can be decrypted. However, this is little consolation to the people whose traffic is initially targeted for decryption. It seems prudent to provide protection against the harvest-then-decrypt attack natively to secure data exchange protocols as soon as possible. 2.3. Quantum-safe hybrid approach The quantum safe hybrid approach defeats the quantum harvest-then- decrypt attack by introducing a second quantum-safe cryptographic primitive running in parallel with existing handshake approaches. This measure assures that when the classical cryptography fails, the attacker still need to break the corresponding quantum-safe encryption algorithm. It is easy to see that this approach is at least as strong as the Schanck et al. Expires 20 March 2016 [Page 5] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] stronger primitive of classical cryptography and the quantum-safe cryptography in the pre-quantum world [QSHTOR]. Therefore, it is an ideal approach to migrate into quantum-safe cryptography for TLS as it does not reduce the security guarantees that TLS is already delivering; in the meantime, it allows for trial usage of quantum- safe algorithms and protects data against the aforementioned harvest- the-decrypt attack. 2.4. Symmetric algorithm For 128 bit security, implementations of a quantum-safe hybrid approach SHOULD use a symmetric algorithm with a 256-bit key, but MAY use a symmetric algorithm with a 128-bit key for interoperability or performance reasons. 2.5. Random bit generation For 128 bit security, implementations of a quantum-safe hybrid approach SHOULD ensure that any Deterministic Random Bit Generator (DRBG) used in key generation or encryption for a quantum-safe primitives is instantiated with at least 256 bits of entropy from a secure random source. 3. Selection Criteria The hybrid approach is a modular design, which, in order to support various quantum-safe algorithms, does not recommend any specific quantum-safe encryption algorithm. In this section we give guidelines for selecting encryption algorithms that are suitable for experimental use in the hybrid approach. 3.1. Similar work To date, multiple groups have been involved in the work of evaluating quantum-safe encryption algorithms. o The National Security Agency of the United States has announced a plan to migrate to quantum-safe cryptography [NSA15]. o The ETSI Quantum-Safe Cryptography (QSC) Industry Specification Group (ISG) aims to assess and make recommendations for quantum-safe cryptographic primitives and protocols, taking into consideration both the current state of academic cryptology and quantum algorithm research, as well as industrial requirements for real-world deployment [ETSIQ]. o The Secure Architectures of Future Emerging Cryptography (SAFEcrypto) project [SAFEC], supported by H2020 project, focuses Schanck et al. Expires 20 March 2016 [Page 6] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] on practical implementation of quantum-safe encryptions algorithms, particularly lattice-based public key cryptography. o The Post-quantum cryptography for long-term security (PQCRYPTO) group, also supported by H2020 project, has made their initial recommendations of long-term secure post-quantum systems [PQCRY]. Note that PQCRYPTO is the only group that has made initial recommendations on quantum-safe cryptography. This document describes criteria for quantum-safe encryption algorithms, with a focus on those algorithms existing today and suitable for transitional use until the quantum era. The intent is ultimately to align with other industry groups while enabling earlier deployment of algorithms that can reasonably be expected to make things better, not worse. 3.2. Mandatory aspects Algorithms to be considered by quantum-safe hybrid approach MUST meet the following criteria. 3.2.1. Security levels The candidate algorithm MUST provide 128 bit security in the quantum- safe setting. If the candidate algorithm is subject to decryption failures, these MUST happen with a probability of less than 2^-74 (such that 128 billion devices (2^7 * 2^30) each initiating 128 billion connections (2^7 * 2^30) will with high probability encounter no decryption failures). Note that an attacker will be able to create invalid messages that do not decrypt correctly, so an implementation will have to correctly handle this failure case even when the chance of a decryption failure is negligible on a valid message (or even when this chance is zero). 3.2.2. Freely available specifications of the algorithm The candidate algorithm MUST have a set of publicly accessible documents specifying common techniques and implementation choices. The documents MAY be Internet Drafts. Topics MUST include: o Cryptographic primitives: the building blocks for a secure cryptographic scheme; Schanck et al. Expires 20 March 2016 [Page 7] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] o Cryptographic schemes: complete sequences of operations for performing secure cryptographic functions; o Supported parameter choices: specific selections of approved sets of values for cryptographic parameters; o Classical security levels for the proposed parameter sets; o Argument for post-quantum security levels for the proposed parameter sets; o Encoding of cryptographic data items: specifies encoding/decoding of public keys and ciphertexts. In addition, it MAY include relevant information to assist in the development and interoperable implementation, including: o Security considerations; o Open issues. 3.2.3. Freely available source code for a reference implementation It is important to have a stable reference implementation available for the candidate algorithm. The code needs to be rigorously tested and reviewable. A poor implementation of a good cryptosystem can be as harmful as a broken cryptosystem. The implementation SHOULD also be open source to allow for public auditing. In particular, any default choice of parameters MUST be justified. 3.3 Desirable aspects The following aspects are desirable. Algorithms that meet those criteria are preferred. 3.3.1. SUPERCOP implementation System for Unified Performance Evaluation Related to Cryptographic Operations and Primitives (SUPERCOP) [SUPEC] is a toolkit developed by the Virtual Application and Implementation Research (VAMPIRE) Lab for measuring the performance of cryptographic software. The latest release of SUPERCOP measures the performance of hash functions, secret key stream ciphers, public key encryption systems, public key signature systems, and public key secret sharing systems. The candidate algorithm MAY have a reference implementation for Schanck et al. Expires 20 March 2016 [Page 8] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] SUPERCOP. Performance of the implementation on SUPERCOP MAY be taken into consideration when selections are made. 3.3.2. Constant-time implementation An implementation of a cryptosystem is constant-time means that the time for encryption/decryption functions is constant, regardless of the input and the output of the functions. As an example, the time to decrypt any valid ciphertext should use a same time as decrypting an invalid ciphertext and producing a decryption error. Constant time implementation is important for cryptography as it makes side- channel attacks substantially harder. Algorithms with provable constant time implementations SHOULD be preferred. However, this is not an absolute requirement as the QSH setting uses ephemeral keys and an implementation of QSH SHOULD only decrypt once with any key, so an attacker is unlikely to gain sufficient information from the time of a single decryption to recover the plaintext. 3.3.3. Standardization The candidate algorithm MAY be standardized by another standards body, such as ANSI X.9, IEEE, or ETSI. Algorithms that maintain creditability among multiple standards bodies SHOULD be preferred. 3.3.4. Patent and IP related issues The candidate algorithm MAY be either non-patented or patented but with FRAND (Free or Reasonable and Non-Discriminatory) licensing statement made and all relevant IETF IP declarations provided. 4. Recommendations, justifications and considerations 4.1. Preliminary list of recommendations The following list is an (incomplete) list of recommended quantum- safe encryption algorithms and parameters for 128 bits security that MAY be considered in the hybrid approach. o NTRUEncrypt lattice-based encryption scheme with parameter sets ees443ep1, ees587ep1, and ees743ep1 as defined in [EESS1]; o Specification: [EESS1] provides a concrete specification of NTRUEncrypt with parameter set ees443ep1, ees587ep1, and ees743ep1, including primitives, syntax, reference to classical security analysis in [HOF15], quantum security analysis, and encode/decode mechanisms Schanck et al. Expires 20 March 2016 [Page 9] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] o Open-sourced reference implementation: Available from [NTRU-GIT] o SUPERCOP implementation: Available for related parameter sets, not yet available for the recommended parameter sets o Constant-time implementation: Not yet available o Standardization: The recommended parameter sets have not been published in a standard, but the encryption scheme and other parameter sets have been standardized in IEEE 1363.1 and ANSI X9.98. o Patent and IP Issues: NTRUEncrypt is subject to patents held by Security Innovation. Security Innovation has provided IPR Declaration 2588 to IETF. 4.2. Schemes under consideration The following schemes are under consideration. They are well known quantum safe encryption algorithms in the literature. However, due to the lack of specifications, implementation of those schemes are non-trivial. For this reason we list those schemes as "under consideration". They will be promoted to the recommendation list once detailed specifications are provided. o Learning with error lattice-based encryption scheme [REG05], with parameter set form [LIN11]; o NTRUEncrypt lattice-based encryption scheme instantiated with learning with error problem [STE11]; o McEliece code-based encryption scheme [MCELI] with parameter set for McBits [MCBIT]; o McEliece code-based encryption scheme with Quasi-cyclic Moderate Density Parity-Check (MDPC) codes [MDPC]. 5. IANA Considerations This document does not establish any new IANA registries, nor does it add any entries to existing registries. 6. References 6.1. Normative References Schanck et al. Expires 20 March 2016 [Page 10] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] [BER09] Bernstein, D., "Cost analysis of hash collisions: Will quantum computers make SHARCS obsolete?", SHARCS'09. [BRA98] Brassard, G., Hoyer, P., and Tapp, A., "Quantum cryptanalysis of hash and claw-free functions", LATIN'98: Theoretical Informatics. [EESS1] Consortium for Efficient Embedded Security, "Efficient Embedded Security Standard #1: Implementation Aspects of NTRUEncrypt", March 2015. [ETSIQ] ETSI White Paper No. 8, "Quantum Safe Cryptography and Security: An introduction, benefits, enablers and challenges", June 2015. [GROV96] Grover, L., "A fast quantum mechanical algorithm for database search", STOC 1996. [H2020] Lange, T., "PQCRYPTO project in the EU", April, 2015. [HOF15] Hoffstein, J., Pipher, J., Schanck, J., Silverman, J., Whyte, W., and Zhang, Z., "Choosing Parameters for NTRUEncrypt", 2015. [LIN11] Lindner, R., and Peikert, C., "Better Key Sizes (and Attacks) for LWE-Based Encryption", 2011. [MCBIT] Bernstein, D., Chou, T., and Schwabe, P., "McBits: Fast Constant-Time Code- Based Cryptography", 2013. [MCELI] McEliece, R., "A Public-Key Cryptosystem Based On Algebraic Coding Theory", 1978. [MDPC] Misoczki, R., Tillich, J., Sendrier, N., and Barreto, P., "MDPC-McEliece: New McEliece variants from Moderate Density Parity-Check codes", 2013. [NSA15] NSA, "NSA Suite B Cryptography", Aug 19, 2015. [NTRU-GIT] https://github.com/NTRUOpenSourceProject/NTRUEncrypt [PKCS1] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1.5", PKCS 1, November 1993 Schanck et al. Expires 20 March 2016 [Page 11] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] [PQCRY] PQCRYPTO, "Initial recommendations of long-term secure post-quantum systems". [QSHTLS] Schanck, J., Whyte, W., and Zhang, Z., "Quantum-Safe Hybrid (QSH) Ciphersuite for Transport Layer Security (TLS) version 1.3", draft-whyte-qsh-tls13-00, July 2015. [QSHTOR] Schanck, J., Whyte, W., and Zhang, Z., "A quantum-safe circuit-extension handshake for Tor", March 2015. [REAL] "RFC Editor Abbreviations List", September 2013, . [REG05] Regev, O., "On lattices, learning with errors, random linear codes, and cryptography", 2005. [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [SAFEC] Secure Architectures of Future Emerging Cryptography (SAFEcrypto). [SHOR97] Shor, P., "Polynomial-time algorithms for prime factorization and discrete logarithm problems", SIAM J. Computing 26 (1997), 1484-1509. Schanck et al. Expires 20 March 2016 [Page 12] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] [STE11] Stehle, D., and Steinfield, R., "Making NTRUEncrypt and NTRUSign as secure as worst-case problems over ideal lattices", 2011. [TLS1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-05, March 2015. [TPM15] Morgan, T., "Google Sees Long, Expensive Road Ahead For Quantum Computing", July 2015. 6.2. Informative References [RFC4366] Blake-Wilson, S., Nysrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. [RFC5990] Randall, J., Kaliski, B., Brainard, J. and Turner S., "Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 5990, September 2010. [RFC5859] Krawczyk, H., Eronen, P., "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5859, May 2010. Authors' Addresses John M. Schanck Security Innovation, US and University of Waterloo, Canada jschanck@securityinnovation.com William Whyte Security Innovation, US wwhyte@securityinnovation.com Zhenfei Zhang Security Innovation, US zzhang@securityinnovation.com Schanck et al. Expires 20 March 2016 [Page 13] INTERNET DRAFT PKC Selecting Criteria for QSH-TLS [date] Copyright Notice IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(ii), paragraph 3: 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. Schanck et al. Expires 20 March 2016 [Page 14]