| TOC |
|
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 March 28, 2008.
This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPSEC schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, PKI schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.
This memo includes the Autokey requirements analysis, design principles and protocol specification. A detailed description of the protocol states, events and transition functions is included. A prototype of the Autokey design based on this report has been implemented, tested and documented in the NTP Version 4 (NTPv4) software distribution for Unix, Windows and VMS at http://www.ntp.org.
1.
Introduction
1.1.
Requirements Notation
2.
NTP Security Model
3.
Approach
4.
Autokey Cryptography
5.
Secure Groups
6.
Identity Schemes
7.
Autokey Operations
8.
Public Key Signatures and Timestamps
9.
Autokey Protocol Overview
10.
Autokey State Machine
10.1.
Status Word
10.2.
Host State Variables
10.3.
Client State Variables (all modes)
10.4.
Server State Variables (broadcast and symmetric modes)
10.5.
Autokey Protocol Messages
10.5.1.
No-Operation
10.5.2.
Association Message (ASSOC)
10.5.3.
Certificate Message (CERT)
10.5.4.
Cookie Message (COOKIE)
10.5.5.
Autokey Message (AUTO)
10.5.6.
Leapseconds Table Message (LEAP)
10.5.7.
Sign Message (SIGN)
10.5.8.
Identity Messages (IFF, GQ, MV)
10.6.
Protocol State Transitions
10.6.1.
Server Dance
10.6.2.
Broadcast Dance
10.6.3.
Symmetric Dance
11.
Error Recovery
12.
Security Considerations
12.1.
Protocol Vulnerability
12.2.
Clogging Vulnerability
13.
IANA Considerations
14.
Acknowledgements
15.
References
15.1.
Normative References
15.2.
Informative References
Appendix A.
Cryptographic Key and Certificate Management
Appendix B.
Autokey Error Checking
B.1.
Packet Processing Rules
B.2.
Timestamps, Filestamps and Partial Ordering
Appendix C.
Certificates
Appendix D.
Identity Schemes
D.1.
Private Certificate (PC) Scheme
D.2.
Trusted Certificate (TC) Scheme
D.3.
Schnorr (IFF) Scheme
D.4.
Guillard-Quisquater (GQ)
D.5.
Mu-Varadharajan (MV) Identity Scheme
D.6.
Interoperability Issues
Appendix E.
ASN.1 Encoding Rules
E.1.
COOKIE request, IFF response, GQ response, MV response
E.2.
CERT response, SIGN request and response
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
A distributed network service requires reliable, ubiquitous and survivable provisions to prevent accidental or malicious attacks on the servers and clients in the network or the values they exchange. Reliability requires that clients can determine that received packets are authentic; that is, were actually sent by the intended server and not manufactured or modified by an intruder. Ubiquity requires that any client can verify the authenticity of any server using only public information. Survivability requires protection from faulty implementations, improper operation and possibly malicious clogging and replay attacks with or without data modification. These requirements are especially stringent with widely distributed network services, since damage due to failures can propagate quickly throughout the network, devastating archives, routing databases and monitoring systems and even bring down major portions of the network.
This memo describes a cryptographically sound and efficient methodology for use in the Network Time Protocol (NTP) [I‑D.ietf‑ntp‑ntpv4‑proto] (Kasch, W., Mills, D., and J. Burbank, “Network Time Protocol Version 4 Protocol And Algorithms Specification,” October 2009.). The various key agreement schemes [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.)[RFC2412] (Orman, H., “The OAKLEY Key Determination Protocol,” November 1998.)[RFC2522] (Karn, P. and W. Simpson, “Photuris: Session-Key Management Protocol,” March 1999.) proposed require per-association state variables, which contradicts the principles of the remote procedure call (RPC) paradigm in which servers keep no state for a possibly large client population. An evaluation of the PKI model and algorithms as implemented in the OpenSSL library leads to the conclusion that any scheme requiring every NTP packet to carry a PKI digital signature would result in unacceptably poor timekeeping performance. The Autokey protocol is based on a combination of PKI and a pseudo-random sequence generated by repeated hashes of a cryptographic value involving both public and private components. This scheme has been implemented, tested and widely deployed in the Internet of today. A detailed description of the security model, design principles and implementation experience is presented in this report.
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
NTP security requirements are even more stringent than most other distributed services. First, the operation of the authentication mechanism and the time synchronization mechanism are inextricably intertwined. Reliable time synchronization requires cryptographic media which are valid only over designated time intervals; but, time intervals can be enforced only when participating servers and clients are reliably synchronized to UTC. In addition, the NTP subnet is hierarchical by nature, so time and trust flow from the primary servers at the root through secondary servers to the clients at the leaves.
A client can claim authentic to dependent applications only if all servers on the path to the primary servers are bone-fide authentic. In order to emphasize this requirement, in this report the notion of "authentic" is replaced by "proventic", a noun new to English and derived from provenance, as in the provenance of a painting. Having abused the language this far, the suffixes fixable to the various noun and verb derivatives of authentic will be adopted for proventic as well. In NTP each server authenticates the next lower stratum servers and proventicates (authenticates by induction) the lowest stratum (primary) servers. Serious computer linguists would correctly interpret the proventic relation as the transitive closure of the authentic relation.
It is important to note that the notion of proventic does not necessarily imply the time is correct. A NTP client mobilizes a number of concurrent associations with different servers and uses crafted mitigation algorithm to pluck truechimers from the population possibly including falsetickers. A particular association is proventic if the server certificate and identity have been verified by the means described in this report. However, the statement "the client is synchronized to proventic sources" means that the system clock has been set using the time values of one or more proventic associations and according to the NTP mitigation algorithms. While a certificate authority (CA) must satisfy this requirement when signing a certificate request, the certificate itself can be stored in public directories and retrieved over unsecured network paths.
Over the last several years the IETF has defined and evolved the IPSEC infrastructure for privacy protection and source authentication in the Internet. The infrastructure includes the Encapsulating Security Payload (ESP) [RFC4303] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) and Authentication Header (AH) [RFC4302] (Kent, S., “IP Authentication Header,” December 2005.) for IPv4 and IPv6. Cryptographic algorithms that use these headers for various purposes include those developed for the PKI, including MD5 message digests, RSA digital signatures and several variations of Diffie-Hellman key agreements. The fundamental assumption in the security model is that packets transmitted over the Internet can be intercepted by other than the intended recipient, remanufactured in various ways and replayed in whole or part. These packets can cause the client to believe or produce incorrect information, cause protocol operations to fail, interrupt network service or consume precious network and processor resources.
In the case of NTP, the assumed goal of the intruder is to inject false time values, disrupt the protocol or clog the network, servers or clients with spurious packets that exhaust resources and deny service to legitimate applications. The mission of the algorithms and protocols described in this report is to detect and discard spurious packets sent by other than the intended sender or sent by the intended sender, but modified or replayed by an intruder. The cryptographic means of the reference implementation are based on the OpenSSL cryptographic software library available at www.openssl.org, but other libraries with equivalent functionality could be used as well. It is important for distribution and export purposes that the way in which these algorithms are used precludes encryption of any data other than incidental to the construction of digital signatures.
There are a number of defense mechanisms already built in the NTP architecture, protocol and algorithms. The fundamental timestamp exchange scheme is inherently resistant to spoofing and replay attacks. The engineered clock filter, selection and clustering algorithms are designed to defend against evil cliques of Byzantine traitors. While not necessarily designed to defeat determined intruders, these algorithms and accompanying sanity checks have functioned well over the years to deflect improperly operating but presumably friendly scenarios. However, these mechanisms do not securely identify and authenticate servers to clients. Without specific further protection, an intruder can inject any or all of the following attacks.
The NTP security model assumes the following possible limitations.
Unlike the Secure Shell security model, where the client must be securely authenticated to the server, in NTP the server must be securely authenticated to the client. In ssh each different interface address can be bound to a different name, as returned by a reverse-DNS query. In this design separate public/private key pairs may be required for each interface address with a distinct name. A perceived advantage of this design is that the security compartment can be different for each interface. This allows a firewall, for instance, to require some interfaces to authenticate the client and others not.
However, the NTP security model specifically assumes that access control is performed by means external to the protocol and that all time values and cryptographic values are public, so there is no need to associate each interface with different cryptographic values. To do so would create the possibility of a two-faced clock, which is ordinarily considered a Byzantine hazard. In other words, there is one set of private secrets for the host, not one for each interface. In the NTP design the host name, by default the string returned by the Unix gethostname() library function, represents all interface addresses. Since at least in some host configurations the host name may not be identifiable in a DNS query, the name must be either configured in advance or obtained directly from the server using the Autokey protocol.
| TOC |
The Autokey protocol described in this report is designed to meet the following objectives.
| TOC |
Autokey public key cryptography is based on the PKI algorithms commonly used in the Secure Shell and Secure Sockets Layer applications. As in these applications Autokey uses keyed message digests to detect packet modification, digital signatures to verify the source and public key algorithms to encrypt cookies. What makes Autokey cryptography unique is the way in which these algorithms are used to deflect intruder attacks while maintaining the integrity and accuracy of the time synchronization function.
NTPv3 and NTPv4 symmetric key cryptography uses keyed-MD5 message digests with a 128-bit private key and 32-bit key ID. In order to retain backward compatibility with NTPv3, the NTPv4 key ID space is partitioned in two subspaces at a pivot point of 65536. Symmetric key IDs have values less than the pivot and indefinite lifetime. Autokey key IDs have pseudo-random values equal to or greater than the pivot and are expunged immediately after use. Both symmetric key and public key cryptography authenticate as shown in Figure 1 (Message Authentication). The server looks up the key associated with the key ID and calculates the message digest from the NTP header and extension fields together with the key value. The key ID and digest form the message authentication code (MAC) included with the message. The client does the same computation using its local copy of the key and compares the result with the digest in the MAC. If the values agree, the message is assumed authentic.
+------------------+
| NTP Header and |
| Extension Fields |
+------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Message Authenticator Code |
\|/ \|/ + (MAC) +
******************** | +-------------------------+ |
* Compute Hash *<----| Key ID | Message Digest | +
******************** | +-------------------------+ |
| +-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+
\|/ \|/
+------------------+ +-------------+
| Message Digest |------>| Compare |
+------------------+ +-------------+
| Figure 1: Message Authentication |
There are three Autokey protocol variants corresponding to each of the three NTP modes: server, symmetric and broadcast. All three variants make use of specially contrived session keys, called autokeys, and a precomputed pseudo-random sequence of autokeys which are saved along with the key IDs in a key list. As in the original NTPv3 authentication scheme, the Autokey protocol operates separately for each association, so there may be several autokey sequences operating independently at the same time.
+-------------+-------------+--------+--------+ | Src Address | Dst Address | Key ID | Cookie | +-------------+-------------+--------+--------+
| Figure 2: NTPv4 Autokey |
An autokey is computed from four fields in network byte order as shown in Figure 2 (NTPv4 Autokey). The four values are hashed by the MD5 message digest algorithm to produce the 128-bit autokey value, which in the reference implementation is stored along with the key ID in a cache used for symmetric keys as well as autokeys. Keys are retrieved from the cache by key ID using hash tables and a fast lookup algorithm.
For use with IPv4, the Source Address and Dest Address fields contain 32 bits; for use with IPv6, these fields contain 128 bits. In either case the Key ID and Cookie fields contain 32 bits. Thus, an IPv4 autokey has four 32-bit words, while an IPv6 autokey has ten 32-bit words. The source and destination addresses and key ID are public values visible in the packet, while the cookie can be a public value or private value, depending on the mode.
The NTP packet format has been augmented to include one or more extension fields piggybacked between the original NTP header and the MAC at the end of the packet. For packets without extension fields, the cookie is a shared private value conveyed in encrypted form. For packets with extension fields, the cookie has a default public value of zero, since these packets can be validated independently using digital signatures.
There are some scenarios where the use of endpoint IP addresses may be difficult or impossible. These include configurations where network address translation (NAT) devices are in use or when addresses are changed during an association lifetime due to mobility constraints. For Autokey, the only restriction is that the address fields visible in the transmitted packet must be the same as those used to construct the autokey sequence and key list and that these fields be the same as those visible in the received packet.
For scenarios where the endpoint IP addresses are not available, an optional public identification value could be used instead of the addresses. Examples include the Interplanetary Internet, where bundles are identified by name rather than address. Specific provisions are for further study.
+-----------+-----------+------+------+ +---------+ +-----+------+
|Src Address|Dst Address|Key ID|Cookie|-->| | |Final|Final |
+-----------+-----------+------+------+ | Session | |Index|Key ID|
| | | | | Key ID | +-----+------+
\|/ \|/ \|/ \|/ | List | | |
************************************* +---------+ \|/ \|/
* COMPUTE HASH * *******************
************************************* *COMPUTE SIGNATURE*
| Index n *******************
\|/ |
+--------+ |
| Next | \|/
| Key ID | +-----------+
+--------+ | Signature |
Index n+1 +-----------+
| Figure 3: Constructing the Key List |
Figure 3 (Constructing the Key List) shows how the autokey list and autokey values are computed. The key list consists of a sequence of key IDs starting with a random 32-bit nonce (autokey seed) equal to or greater than the pivot as the first key ID. The first autokey is computed as above using the given cookie and the first 32 bits of the result in network byte order become the next key ID. Operations continue to generate the entire list. It may happen that a newly generated key ID is less than the pivot or collides with another one already generated (birthday event). When this happens, which occurs only rarely, the key list is terminated at that point. The lifetime of each key is set to expire one poll interval after its scheduled use. In the reference implementation the list is terminated when the maximum key lifetime is about one hour, so for poll intervals above one hour a new key list containing only a single entry is regenerated for every poll.
+------------------+ | NTP Header and | | Extension Fields | +------------------+ | | \|/ \|/ +---------+ **************** +--------+ | Session | * COMPUTE HASH *<---| Key ID |<---| Key ID | **************** +--------+ | List | | | +---------+ \|/ \|/ +----------------------------------+ | Message Authenticator Code (MAC) | +----------------------------------+
| Figure 4: Transmitting Messages |
The index of the last key ID in the list is saved along with the next key ID for that entry, collectively called the autokey values. The autokey values are then signed. The list is used in reverse order as shown in Figure 4 (Transmitting Messages), so that the first autokey used is the last one generated. The Autokey protocol includes a message to retrieve the autokey values and signature, so that subsequent packets can be validated using one or more hashes that eventually match the last key ID (valid) or exceed the index (invalid). This is called the autokey test in the following and is done for every packet, including those with and without extension fields. In the reference implementation the most recent key ID received is saved for comparison with the first 32 bits in network byte order of the next following key value. This minimizes the number of hash operations in case a single packet is lost.
| TOC |
A digital signature scheme provides an authentic certificate trail, but does not provide protection against masquerade, unless the server identity is verified by other means. The PKI security model assumes each host is able to verify the certificate trail to a trusted certificate authority (CA), where each ascendant host must prove identity to the immediately descendant host by independent means, such as a credit card number or PIN. While Autokey supports this model by default, in a hierarchical ad-hoc network, especially with server discovery schemes like NTP Manycast, proving identity at each rest stop on the trail must be an intrinsic capability of Autokey itself.
In the NTP security model every member of a closed group, such as might be operated by a timestamping service, be in possession of a secret group key. This could take the form of a private certificate or one or another identification schemes described in the literature and Appendix D (Identity Schemes). Certificate trails and identification schemes are at the heart of the NTP security model preventing masquerade and middleman attacks. The Autokey protocol operates to hike the trails and then run the identity schemes.
A NTP secure group consists of a number of hosts dynamically assembled as a forest with roots the trusted hosts at the lowest stratum of the group. The trusted hosts do not have to be, but often are, primary (stratum 1) servers. A trusted authority (TA), usually one of the trusted hosts, generates private and public identity media and deploys selected values to the group members. The identity values are of two kinds, encrypted private keys used by servers with dependent clients and nonencrypted public parameters used by all hosts, including those that are not group members, but depend on group members for authentication purposes.
Figure 5 (NTP Secure Groups)
+-------------+ +-------------+ +-------------+
| Alice | | Brenda | | Denise |
| | | | | |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
Certificate | | Alice | | | | Brenda| | | | Denise| |
+-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| Subject | | | Alice*| 1 | | | Alice | 4 | | | Carol | 4 |
+-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| Issuer | S | | | | | |
+-+-+-+-+-+ | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ |
| ||Alice|| 3 | | | Alice | | | | Carol | |
Group Key | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ |
+=========+ +-------------+ | | Alice*| 2 | | | Carol*| 2 |
|| Group || S | Carol | | +-+-+-+-+ | | +-+-+-+-+ |
+=========+ | | | | | |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
S = step | | Carol | | | | Brenda| | | | Denise| |
* = trusted | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| | Carol*| 1 | | | Brenda| 1 | | | Denise| 1 |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| | | | | |
| +=======+ | | +=======+ | | +=======+ |
| ||Alice|| 3 | | ||Alice|| 3 | | ||Alice|| 3 |
| +=======+ | | +=======+ | | +=======+ |
+-------------+ +-------------+ +-------------+
Stratum 1 Stratum 2
+---------------------------------------------+
| Eileen |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Eileen| | Eileen| |
| +-+-+-+-+ +-+-+-+-+ |
| | Brenda| | Carol | 4 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice | | Carol | |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice*| | Carol*| 2 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Brenda| | Denise| |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice | | Carol | 2 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ |
| | Eileen| |
| +-+-+-+-+ |
| | Eileen| 1 |
| +-+-+-+-+ |
| |
| +=======+ |
| ||Alice|| 3 |
| +=======+ |
+---------------------------------------------+
Stratum 3
| Figure 5: NTP Secure Groups |
The steps in hiking the certificate trails and verifying identity are as follows. Note the step number in the description matches the step number in the figure.
The NTP security model is based on multiple, hierarchical, overlapping security compartments or groups. The example above illustrates how groups can be used to construct closed compartments, depending on how the identity credentials are deployed. The rules can be summarized:
For various reasons it may be convenient for the trusted hosts to hold parameters for one or more groups operating at a lower stratum. For example, Figure 6 (Hierarchical Overlapping Groups) shows three secure groups Alice, Helen and Carol arranged in a hierarchy. Hosts A, B, C and D belong to the Alice group, hosts R and S to the Helen group and hosts X, Y and Z to the Carol group. While not strictly necessary, hosts A, B and R are stratum 1 and presumed trusted; the TA generating the group keys and parameters could be one of them or another not shown.
***** ***** @@@@@
Stratum 1 * A * * B * @ R @
***** ***** @@@@@
\ / /
\ / /
***** @@@@@ *********
2 * C * @ S @ * Alice *
***** @@@@@ *********
/ \ /
/ \ / @@@@@@@@@
***** ##### @ Helen @
3 * D * # X # @@@@@@@@@
***** #####
/ \ #########
/ \ # Carol #
##### ##### #########
4 # Y # # Z #
##### #####
| Figure 6: Hierarchical Overlapping Groups |
The intent of the design is to provide security separation, so that servers cannot masquerade as TAs and clients cannot masquerade as servers. Assume for example that Alice and Helen belong to national standards laboratories and their group keys are used to confirm identity between members of each group. Carol is a prominent corporation receiving standards products via broadcast satellite and requiring cryptographic authentication.
Perhaps under contract, host X belonging to the Carol group has rented group parameters for both Alice and Helen and has group keys for Carol. The Autokey protocol operates for each group separately while preserving security separation. Host X can prove identity in Carol to clients Y and Z, but cannot prove to anybody that it belongs to either Alice or Helen.
In some scenarios it would be desirable that servers cannot masquerade as the TA and clients cannot masquerade as servers. This can be assured using the MV identity scheme described later. It allows the same broadcast transmission to be authenticated by more than one key, one used internally by the laboratories (Alice and/or Helen) and the other handed out to clients like Carol. In the MV scheme these keys can be separately activated upon subscription and deactivated if the subscriber fails to pay the bill. In the MV scheme a key can be deactivated without requiring the other keys to be recomputed.
Figure 7 (Multiple Overlapping Groups) shows operational details where more than one group is involved, in this case Carol and Alice. As in the previous example, Brenda has configured Alice as her time source and Denise has configured Carol as her time source. Alice and Brenda have group keys and parameters for the Alice group; Carol and Denise have group keys and parameters for the Carol group. Eileen has parameters for both groups. The protocol operates as previously described to verify Alice to Brenda and Carol to Denise.
+-------------+ +-------------+ +-------------+
| Alice | | Brenda | | Denise |
| | | | | |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
Certificate | | Alice | | | | Brenda| | | | Denise| |
+-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| Subject | | | Alice*| 1 | | | Alice | 4 | | | Carol | 4 |
+-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| Issuer | S | | | | | |
+-+-+-+-+-+ | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ |
| ||Alice|| 3 | | | Alice | | | | Carol | |
Group Key | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ |
+=========+ +-------------+ | | Alice*| 2 | | | Carol*| 2 |
|| Group || S | Carol | | +-+-+-+-+ | | +-+-+-+-+ |
+=========+ | | | | | |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
S = step | | Carol | | | | Brenda| | | | Denise| |
* = trusted | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| | Carol*| 1 | | | Brenda| 1 | | | Denise| 1 |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| | | | | |
| +=======+ | | +=======+ | | +=======+ |
| ||Carol|| 3 | | ||Alice|| 3 | | ||Carol|| 3 |
| +=======+ | | +=======+ | | +=======+ |
+-------------+ +-------------+ +-------------+
Stratum 1 Stratum 2
+---------------------------------------------+
| Eileen |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Eileen| | Eileen| |
| +-+-+-+-+ +-+-+-+-+ |
| | Brenda| | Carol | 4 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice | | Carol | |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice*| | Carol*| 2 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ +-+-+-+-+ |
| | Brenda| | Denise| |
| +-+-+-+-+ +-+-+-+-+ |
| | Alice | | Carol | 2 |
| +-+-+-+-+ +-+-+-+-+ |
| |
| +-+-+-+-+ |
| | Eileen| |
| +-+-+-+-+ |
| | Eileen| 1 |
| +-+-+-+-+ |
| |
| +=======+ +=======+ |
| ||Alice|| ||Carol|| 3 |
| +=======+ +=======+ |
+---------------------------------------------+
Stratum 3
| Figure 7: Multiple Overlapping Groups |
The interesting case is Eileen, who may verify identity either via Brenda or Denise or both. To do that she uses the public pameters of either Alice and Carol or both. But, Eileen doesn't know which of the two parameters to use until hiking the certificate trail to find the trusted certificate of either Alice or Carol and then loading the associated parameters. This scenario can of course become even more complex as the number of servers and depth of the tree increase. The bottom line is that every host must have the parameters for all the lowest-stratum trusted hosts it is ever likely to find.
| TOC |
While the identity scheme described in [RFC2875] (Prafullchandra, H. and J. Schaad, “Diffie-Hellman Proof-of-Possession Algorithms,” July 2000.) is based on a ubiquitous Diffie-Hellman infrastructure, it is expensive to generate and use when compared to others described in Appendix D (Identity Schemes). There are five schemes now implemented in the NTPv4 reference implementation to prove identity: (1) private certificate (PC), (2) trusted certificate (TC), (3) a modified Schnorr algorithm (IFF aka Identify Friendly or Foe), (4) a modified Guillou-Quisquater algorithm (GQ), and (5) a modified Mu-Varadharajan algorithm (MV). Following is a summary description of each; details are given in Appendix D (Identity Schemes).
The PC scheme involves a private certificate as group key. A certificate is designated private by a X509 Version 3 extension field when generated by utility routines in the NTP software distribution. The certificate is distributed to all other group members by secure means and is never revealed outside the group. A client is marked trusted when the first signature is verified. In effect, the private certificate is used as a symmetric key. This scheme is cryptographically strong as long as the private certificate is protected; however, it can be very awkward to refresh the keys or certificate, since new values must be securely distributed to a possibly large population and activated simultaneously. It is included here primarily as a yardstick and protocol exercise.
All other schemes involve a conventional certificate trail as described in RFC 4210 [RFC4210] (Adams, C., Farrell, S., Kause, T., and T. Mononen, “Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP),” September 2005.), where each certificate is signed by an issuer one step closer to the trusted hosts, which have self-signed trusted certificates. A certificate is designated trusted by a X509 Version 3 extension field when generated by utility routines in the NTP software distribution. A host obtains the certificates of all other hosts along the trail ending at a trusted host, then requests the immediately ascendant host to sign its own certificate. Subsequently, these certificates are provided to descendent hosts by the Autokey protocol. In this scheme keys, parameters and certificates can be refreshed at any time, but a masquerade vulnerability remains unless a request to sign a client certificate is validated by some means such as reverse-DNS. If no specific identity scheme is specified, this is the default TC identity scheme.
The three remaining schemes IFF, GQ and MV involve a cryptographically strong challenge-response exchange where an intruder cannot learn the group key, even after repeated observations of multiple exchanges. In addition, the IFF and MV schemes are properly described as zero-knowledge proofs, because the client can verify the server has the group key without the client knowing its value.
These schemes start when the client sends a nonce to the server, which then rolls its own nonce, performs a mathematical operation and sends the results along with a message digest to the client. The client performs another mathematical operation and verifies the results match the message digest. The IFF scheme is used when the certificate is generated by a third party, such as a commercial service and in general has the same refreshment and distribution problems as PC. However, this scheme has the advantage that the group key is not known to the clients.
On the other hand, when certificates are generated by routines in the NTPv4 distribution, the GQ scheme may be a better choice. In this scheme the server further obscures the secret group key using a public/private key pair which can be refreshed at any time. The public member is conveyed in the certificate by a X509 Version 3 extension field which changes for each regeneration of key pair and certificate.
The MV scheme is perhaps the most interesting and flexible of the three challenge/response schemes. It can be used when a small number of servers provide synchronization to a large client population where there might be considerable risk of compromise between and among the servers and clients. The TA generates a deliciously intricate cryptosystem involving public and private encryption keys, together with a number of activation keys and associated private client decryption keys. The activation keys are used by the TA to activate and revoke individual client decryption keys without changing the decryption keys themselves.
The TA provides the server with a private encryption key and public decryption key. The server adjusts the keys by a nonce for each plaintext encryption, so they appear different on each use. The encrypted ciphertext and adjusted public decryption key are provided in the client message. The client computes the decryption key from its private decryption key and the public decryption key in the message.
| TOC |
The Autokey protocol has three variations or dances corresponding to the NTP server, symmetric and broadcast modes. The server dance was suggested by Steve Kent over lunch some time ago, but considerably modified since that meal. The server keeps no state for each client, but uses a fast algorithm and a 32-bit random private value (server seed) to regenerate the cookie upon arrival of a client packet. The cookie is calculated as the first 32 bits of the autokey computed from the client and server addresses, a key ID of zero and the server seed as cookie. The cookie is used for the actual autokey calculation by both the client and server and is thus specific to each client separately.
In previous Autokey versions the cookie was transmitted in clear on the assumption it was not useful to a wiretapper other than to launch an ineffective replay attack. However, a middleman could intercept the cookie and manufacture bogus messages acceptable to the client. In order to reduce the risk of such an attack, the Autokey Version 2 server encrypts the cookie using a public key supplied by the client. While requiring additional processor resources for the encryption, this makes it effectively impossible to spoof a cookie or masquerade as the server.
In the server dance the client uses the cookie and each key ID on the key list in turn to retrieve the autokey and generate the MAC in the NTP packet. The server uses the same values to generate the message digest and verifies it matches the MAC in the packet. It then generates the MAC for the response using the same values, but with the client and server addresses exchanged. The client generates the message digest and verifies it matches the MAC in the packet. In order to deflect old replays, the client verifies the key ID matches the last one sent. In this mode the sequential structure of the key list is not exploited, but doing it this way simplifies and regularizes the implementation while making it nearly impossible for an intruder to guess the next key ID.
In the broadcast dance clients normally do not send packets to the server, except when first starting up to verify credentials and calibrate the propagation delay. At the same time the client runs the broadcast dance to obtain the autokey values. The dance requires the association ID of the particular server association, since there can be more than one operating in the same server. For this purpose, the server packet includes the association ID in every response message sent and, when sending the first packet after generating a new key list, it sends the autokey values as well. After obtaining and verifying the autokey values, the client verifies further server packets using the autokey sequence.
The symmetric dance is similar to the server dance and keeps only a small amount of state between the arrival of a packet and departure of the reply. The key list for each direction is generated separately by each peer and used independently, but each is generated with the same cookie. The cookie is conveyed in a way similar to the server dance, except that the cookie is a random value. There exists a possible race condition where each peer sends a cookie request message before receiving the cookie response from the other peer. In this case, each peer winds up with two values, one it generated and one the other peer generated. The ambiguity is resolved simply by computing the working cookie as the EXOR of the two values.
Autokey choreography includes one or more exchanges, each with a specific purpose, that must be completed in order. The client obtains the server host name, digest/signature scheme and identity scheme in the parameter exchange. It recursively obtains and verifies certificates on the trail leading to a trusted certificate in the certificate exchange and verifies the server identity in the identity exchange. In the values exchange the client obtains the cookie and autokey values, depending on the particular dance. Finally, the client presents its self-signed certificate to the server for signature in the sign exchange.
Once the certificates and identity have been validated, subsequent packets are validated by digital signatures and autokey sequences. These packets are presumed to contain valid time values; however, unless the system clock has already been set by some other proventic means, it is not known whether these values actually represent a truechime or falsetick source. As the protocol evolves, the NTP associations continue to accumulate time values until a majority clique is available in a population of at least three servers. At this point the NTP mitigation algorithms cull the falsetickers and cluster outlyers from the population and the survivors are allowed to discipline the system clock.
The time values for truechimer sources form a proventic partial ordering relative to the applicable signature timestamps. This raises the interesting issue of how to mitigate between the timestamps of different associations. It might happen, for instance, that the timestamp of some Autokey message is ahead of the system clock by some presumably small amount. For this reason, timestamp comparisons between different associations and between associations and the system clock are avoided, except in the NTP intersection and clustering algorithms and when determining whether a certificate has expired.
Once the Autokey values have been instantiated, the dances are normally dormant. In all except the broadcast dance, packets are normally sent without extension fields, unless the packet is the first one sent after generating a new key list or unless the client has requested the cookie or autokey values. If for some reason the client clock is stepped, rather than slewed, all cryptographic and time values for all associations are purged and the dances in all associations restarted from scratch. This insures that stale values never propagate beyond a clock step. At intervals of about one day the reference implementation purges all associations, refreshes all signatures, garbage collects expired certificates and refreshes the server seed.
| TOC |
While public key signatures provide strong protection against misrepresentation of source, computing them is expensive. This invites the opportunity for an intruder to clog the client or server by replaying old messages or to originate bogus messages. A client receiving such messages might be forced to verify what turns out to be an invalid signature and consume significant processor resources.
In order to foil such attacks, every signed extension field carries a timestamp in the form of the NTP seconds at the signature epoch. The signature spans the entire extension field including the timestamp. If the Autokey protocol has verified a proventic source and the NTP algorithms have validated the time values, the system clock can be synchronized and signatures will then carry a nonzero (valid) timestamp. Otherwise the system clock is unsynchronized and signatures carry a zero (invalid) timestamp. The protocol detects and discards replayed extension fields with old or duplicate timestamps, as well as fabricated extension fields with bogus timestamps, before any values are used or signatures verified.
There are three signature types currently defined:
The most recent timestamp received of each type is saved for comparison. Once a valid signature with valid timestamp has been received, messages with invalid timestamps or earlier valid timestamps of the same type are discarded before the signature is verified. For signed messages this deflects replays that otherwise might consume significant processor resources. For other messages the Autokey protocol deflects message modification or replay by a wiretapper, but not necessarily by a middleman. In addition, the NTP protocol itself is inherently resistant to replays and consumes only minimal processor resources.
All cryptographic values used by the protocol are time sensitive and are regularly refreshed. In particular, files containing cryptographic basis values used by signature and encryption algorithms are regenerated from time to time. It is the intent that file regenerations occur without specific advance warning and without requiring prior distribution of the file contents. While cryptographic data files are not specifically signed, every file is associated with a filestamp in the form of the NTP seconds at the creation epoch. It is not the intent in this report to specify file formats or names or encoding rules; however, whatever conventions are used must support a NTP filestamp in one form or another. Additional details specific to the reference implementation are in Appendix A (Cryptographic Key and Certificate Management).
Filestamps and timestamps can be compared in any combination and use the same conventions. It is necessary to compare them from time to time to determine which are earlier or later. Since these quantities have a granularity only to the second, such comparisons are ambiguous if the values are in the same second. Thus, the ambiguity must be resolved for each comparison operation as described in Appendix B (Autokey Error Checking).
It is important that filestamps be proventic data; thus, they cannot be produced unless the producer has been synchronized to a proventic source. As such, the filestamps throughout the NTP subnet represent a partial ordering of all creation epochs and serve as means to expunge old data and insure new data are consistent. As the data are forwarded from server to client, the filestamps are preserved, including those for certificate files. Packets with older filestamps are discarded before spending cycles to verify the signature.
| TOC |
This section presents an overview of the three dances: server, broadcast and symmetric. Each dance is designed to be nonintrusive and to require no additional packets other than for regular NTP operations. The NTP and Autokey protocols operate independently and simultaneously and use the same packets. When the preliminary dance exchanges are complete, subsequent packets are validated by the autokey sequence and thus considered proventic as well. Autokey assumes hosts poll servers at a relatively low rate, such as once per minute or slower. In particular, it is assumed that a request sent at one poll opportunity will normally result in a response before the next poll opportunity; however the protocol is robust against a missed or duplicate response.
The Autokey protocol data unit is the extension field, one or more of which can be piggybacked in the NTP packet. An extension field contains either a request with optional data or a response with or without data. To avoid deadlocks, any number of responses can be included in a packet, but only one request. A response is generated for every request, even if the requestor is not synchronized to a proventic source, but contain meaningful data only if the responder is synchronized to a proventic source. Some requests and most responses carry timestamped signatures. The signature covers the entire extension field, including the timestamp and filestamp, where applicable. Only if the packet passes all extension field tests are cycles spent to verify the signature.
All dances begin with the parameter exchange where the host obtains the server host name and status word specifying the digest/signature scheme it will use and the identity schemes it supports. The dance continues with the certificate exchange where the host obtains and verifies the certificates along the trail to a trusted, self-signed certificate usually, but not necessarily, provided by a primary (stratum 1) server. Primary servers are by design proventic with trusted, self-signed certificates.
However, the certificate trail is not sufficient protection against middleman attacks unless an identity scheme such as described in Appendix D (Identity Schemes) or proof-of-possession scheme in [RFC2875] (Prafullchandra, H. and J. Schaad, “Diffie-Hellman Proof-of-Possession Algorithms,” July 2000.) is available. While the protocol for a generic challenge/response scheme is defined in this report, the choice of one or another required or optional identification schemes is yet to be determined. If all certificate signatures along the trail are verified and the server identity is confirmed, the host continues with the cookie and autokey exchanges as necessary to complete the protocol. Upon completion the host verifies packets using digital signatures and/or the autokey sequence.
Once synchronized to a proventic source, the host continues with the sign exchange where the server acting as CA signs the host certificate. The CA interprets the certificate as a X.509v3 certificate request, but verifies the signature if it is self-signed. The CA extracts the subject, issuer, extension fields and public key, then builds a new certificate with these data along with its own serial number and begin and end times, then signs it using its own public key. The host uses the signed certificate in its own role as CA for dependent clients.
A final exchange occurs when the server has the NIST leapseconds table, as indicated in the host status word. If so, the host requests the table and compares the filestamp with its own leapseconds table filestamp, if available. If the server table is newer than the host table, the host replaces its table with the server table. The host, acting as server, can now provide the most recent table to its dependent clients. In symmetric mode, this results in both peers having the newest table.
| TOC |
This section describes the formal model of the Autokey state machine, its state variables and the state transition functions.
| TOC |
Each server and client operating also as a server implements a host status word, while each client implements an association status word for each server. Both words have the format and content shown in Figure 8 (Status Word). The low order 16 bits of the status word define the state of the Autokey protocol, while the high order 16 bits specify the message digest/signature encryption scheme. as encoded in the OpenSSL library. Bits 24-31 of the status word are reserved for server use, while bits 16-23 are reserved for client association use. In the host portion bits 24-27 specify the available identity schemes, while bits 28-31 specify the server capabilities. There are four additional bits implemented separately.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest / Signature NID | Client | Ident | Host |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 8: Status Word |
The host status word is included in the ASSOC request and response messages. The client copies this word to the association status word and then lights additional status bits as the dance proceeds. Once enabled, these bits never come dim unless a general reset occurs and the protocol is restarted from the beginning. The status bits are defined as follows:
The PC scheme is exclusive of any other scheme. Otherwise, the IFF, GQ and MV bits can be lit in any combination.
The association status bits are defined as follows:
There are four additional status bits LST, LBK, DUP, and SYN not included in the status word. All except SYN are association properties, while SYN is a host property. These bits may be enabled (set to 1) or disabled (set to 0) as the protocol proceeds; all except LST are active whether or not the protocol is running. LST is enabled when the key list is regenerated and signed and comes dim after the autokey values have been transmitted. This is necessary to avoid livelock under some conditions. SYN is enabled when the client has synchronized to a proventic source and never dim after that. There are two error bits maintained by the NTP on-wire protocol:
These bits, which are described in Appendix B (Autokey Error Checking), are lit if the corresponding error has occurred for the current packet and dim otherwise.
| TOC |
Following is a list of state variables used by the server protocol.
| TOC |
Following is a list of state variables used by the client association protocol in all modes.
| TOC |
Following is a list of server state variables used in broadcast and symmetric modes.
| TOC |
There are currently eight Autokey requests and eight corresponding responses. The NTPv4 packet format is described in [I‑D.ietf‑ntp‑ntpv4‑proto] (Kasch, W., Mills, D., and J. Burbank, “Network Time Protocol Version 4 Protocol And Algorithms Specification,” October 2009.) and the extension field format used for these messages is illustrated in Figure 9 (NTPv4 Extension Field Format).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Filestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / / Value \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / / Signature \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / / Padding (if needed) \ \ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 9: NTPv4 Extension Field Format |
Each extension field is zero-padded to a 4-octet boundary. The Length field covers the entire extension field, including the Length and Padding fields. While the minimum field length is 8 octets, a maximum field length remains to be established. The reference implementation discards any packet with a total field length more than 1024 octets.
If an extension field is present, the parser examines the Length field. If the length is less than 4 or not a multiple of 4, a format error has occurred and the packet MUST be discarded; otherwise, the parser increments the pointer by the length value. The parser now uses the same rules as above to determine whether a MAC is present and/or another extension field.
The 8-bit Code field specifies the request or response operation, while the 4-bit Version Number (VN) field is 2 for the current protocol version. There are four flag bits: bit 0 is the Response Flag (R) and bit 1 is the Error Flag (E); the other two bits are presently unused and should be set to 0. The remaining fields will be described later.
In the most common protocol operations, a client sends a request to a server with an operation code specified in the Code field and both the R bit and E bit dim. The Association ID field is set to the value previously received from the server or 0 otherwise. The server returns a response with the same operation code in the Code field and lights the R bit. The server can also light the E bit in case of error. The Association ID field is set to the association ID of the server as a handle for subsequent exchanges. If for some reason the association ID value in a request does not match the association ID of any mobilized association, the server returns the request with both the R and E bits lit. Note that it is not necessarily a protocol error to send an unsolicited response with no matching request.
In some cases not all fields may be present. For requests, until a client has synchronized to a proventic source, signatures are not valid. In such cases the Timestamp and Signature Length fields are 0 and the Signature field is empty. Responses are generated only when the responder has synchronized to a proventic source; otherwise, an empty response message is sent. Some request and error response messages carry no value or signature fields, so in these messages only the first two words are present.
The Timestamp and Filestamp words carry the seconds field of an NTP timestamp. The Timestamp field establishes the signature epoch of the data field in the message, while the filestamp establishes the generation epoch of the file that ultimately produced the data that is signed. A signature and timestamp are valid only when the signing host is synchronized to a proventic source; otherwise, the timestamp is zero. A cryptographic data file can only be generated if a signature is possible; otherwise, the filestamp is zero, except in the ASSOC response message, where it contains the server status word.
| TOC |
A No-operation request (Field Type = 0) does nothing except return an empty reply which can be used as a crypto-ping.
| TOC |
An Association Message (Field Type = 1) is used in the parameter exchange to obtain the host name and related values. The request contains the host status word in the filestamp field. The response contains the server status word in the filestamp field and in addition the host name, which by default is the string returned by the Unix gethostname() library function. While minimum and maximum host name lengths remain to be established, the reference implementation uses the values 4 and 256, respectively. The remaining fields are defined previously in this report.
If the server response is acceptable and both server and client share the same identity scheme, ENB is lit. When the PC identity scheme is in use, the ASSOC response lights VAL, IFF, and SIG, since the PC exchange is complete at this point.
| TOC |
A Certificate Message (Field Type = 2) is used in the certificate exchange to obtain a certificates and related values by subject name. The request contains the subject name. For the purposes of interoperability with older Autokey versions, if only the first two words are sent, the request is for the server host certificate. The response contains the certificate encoded in X.509 format with ASN.1 syntax as described in Appendix E (ASN.1 Encoding Rules).
If the subject name in the response does not match the issuer name, the exchange continues with the issuer name replacing the subject name in the request. The exchange continues until either the subject name matches the issuer name, indicating a self-signed certificate, or the trst bit is set in the CIS, indicating a trusted certificate. If a trusted certificate is found, the client stops the exchange and lights VAL. If a self-signed certificate is found but not trusted, the protocol loops at polite intervals until one is found or timeout.
| TOC |
The Cookie Message (Field Type = 3) is used in server and symmetric modes to obtain the server cookie. The request contains the host public key encoded with ASN.1 syntax as described in Appendix E (ASN.1 Encoding Rules). The response contains the cookie encrypted by the public key in the request. The signature and timestamps are determined when the cookie is encrypted. If the response is valid, the client lights CKY.
| TOC |
The Autokey Message (Field Type = 4) is used to obtain the autokey values. The request contains no value. The response contains two 32-bit words in network order. The first word is the final key ID, while the second is the index of the final key ID. The signature and timestamps are determined when the key list is generated. If the response is valid, the client lights AUT.
| TOC |
The Leapseconds Table Message (Field Type = 5) is used to exchange leapseconds tables. The request and response messages have the same format, except that the R bit is dim in the request and lit in the response. Both the request and response contains the leapseconds table as parsed from the NIST leapseconds file. If the client already has a copy of the leapseconds data, it uses the one with the latest filestamp and discards the other. If the response is valid, the client lights LPT.
| TOC |
The Sign Message (Field Type = 6) requests the server to sign and return the certificate presented in the request. The request contains the client certificate encoded in X.509 format with ASN.1 syntax as described in Appendix E (ASN.1 Encoding Rules). The response contains the client certificate signed by the server private key. If the certificate is valid when received by the host, it is linked in the certificate list and SGN is lit.
| TOC |
The Identity Messages (Field Type = 7 (IFF), 8 (GQ), or 9 (MV)) contains the host challenge, usually a 160- or 512-bit nonce. The response contains the result of the mathematical operation defined in Appendix D (Identity Schemes). The Response is encoded in ASN.1 syntax as described in Appendix E (ASN.1 Encoding Rules). The response signature and timestamp are determined when the response is sent. If the response is valid, IFF is lit.
| TOC |
The protocol state machine is very simple but robust. The state is determined by the server status bits defined above. The state transitions of the three dances are shown below. The capitalized truth values represent the server status bits. All server bits are initialized dim and lit upon the arrival of a specific response message, as detailed above.
When the system clock is first set and about once per day after that, or when the system clock is stepped, the server seed is refreshed, signatures and timestamps updated and the protocol restarted in all associations. When the server seed is refreshed or a new certificate or leapseconds table is received, the public values timestamp is reset to the current time and all signatures are recomputed.
| TOC |
The server dance begins when the host sends an ASSOC request to the server. It ends when the first signature is verified and PRV is lit. Subsequent packets received without extension fields are validated by the autokey sequence. An optional LEAP exchange updates the leapseconds table. Note the order of the identity exchanges and that only the first one will be used if multiple schemes are available. Note also that the SIGN and LEAP requests are not issued until the client has synchronized to a proventic source.
while (1) {
wait_for_next_poll;
make_NTP_header;
if (response_ready)
send_response;
if (!ENB)
/ * parameters exchange */
ASSOC_request;
else if (!VAL)
/* certificate exchange */
CERT_request(Host_Name);
else if (IDN & GQ && !IFF)
/* GQ identity exchange */
GQ_challenge;
else if (IDN & IFF && !IFF)
/* IFF identity exchange */
IFF_challenge;
else if (!IFF)
/* TC identity exchange */
CERT_request(Issuer_Name);
else if (!CKY)
/* cookie exchange */
COOKIE_request;
else if (SYN && !SIG)
/* signe exchange */
SIGN_request(Host_Certificate);
else if (SYN && LPF & !LPT)
/* leapseconds exchange */
LEAP_request;
}
When the PC identity scheme is in use, the ASSOC response lights VAL, IFF, and SIG; the COOKIE response lights CKY and AUT; and the first valid signature lights PRV.
| TOC |
The only difference between the broadcast and server dances is the inclusion of an autokey values exchange following the cookie exchange. The broadcast dance begins when the host receives the first broadcast packet, which includes an ASSOC response with association ID. The host uses the association ID to initiate a server dance in order to calibrate the propagation delay.
The dance ends when the first signature is verified and PRV is lit. Subsequent packets received without extension fields are validated by the autokey sequence. An optional LEAP exchange updates the leapseconds table. When the server generates a new key list, the server replaces the ASSOC response with an AUTO response in the first packet sent.
while (1) {
wait_for_next_poll;
make_NTP_header;
if (response_ready)
send_response;
if (!ENB)
/* parameters exchange */
ASSOC_request;
else if (!VAL)
/* certificate exchange */
CERT_request(Host_Name);
else if (IDN & GQ && !IFF)
/* GQ identity exchange */
GQ_challenge;
else if (IDN & IFF && !IFF)
/* IFF identity exchange */
IFF_challenge;
else if (!IFF)
/* TC identity exchange */
CERT_request(Issuer_Name);
else if (!CKY)
/* cookie exchange */
COOKIE_request;
else if (!AUT)
/* autokey values exchange */
AUTO_request;
else if (SYN &&! SIG)
/* sign exchange */
SIGN_request(Host_Certificate);
else if (SYN && LPF & !LPT)
/* leapseconds exchange */
LEAP_request;
}
When the PC identity scheme is in use, the ASSOC response sets VAL, IFF, and SIG to 1; the COOKIE response sets CKY and AUT to 1; and the first valid signature set PRV to 1.
| TOC |
The symmetric dance is intricately choreographed. It begins when the active peer sends an ASSOC request to the passive peer. The passive peer mobilizes an association and both peers step the same dance from the beginning. Until the active peer is synchronized to a proventic source (which could be the passive peer) and can sign messages, the passive peer loops waiting for the timestamp in the ASSOC response to be lit. Until then, the active peer dances the server steps, but skips the sign, cookie and leapseconds exchanges.
while (1) {
wait_for_next_poll;
make_NTP_header;
if (!ENB)
/* parameters exchange */
ASSOC_request;
else if (!VAL)
/* certificate exchange */
CERT_request(Host_Name);
else if (IDN & GQ && !IFF)
/* GQ identity exchange */
GQ_challenge;
else if (IDN & IFF && !IFF)
/* IFF identity exchange */
IFF_challenge;
else if (!IFF)
/* TC identity exchange */
CERT_request(Issuer_Name);
else if (SYN && !SIG)
/* sign exchange */
SIGN_request(Host_Certificate);
else if (SYN && !CKY)
/* cookie exchange */
COOKIE_request;
else if (!LST)
/* autokey values response */
AUTO_response;
else if (!AUT)
/* autokey values exchange */
AUTO_request;
else if (SYN && LPF & !LPT)
/* leapseconds exchange */
LEAP_request;
}
When the PC identity scheme is in use, the ASSOC response lights VAL, IFF, and SIG; the COOKIE response lights CKY and AUT; and the first valid signature lights PRV.
Once the active peer has synchronized to a proventic source, it includes timestamped signatures with its messages. The first thing it does after lighting timestamps is dance the sign exchange so that the passive peer can survive the default identity exchange, if necessary. This is pretty weird, since the passive peer will find the active certificate signed by its own public key.
The passive peer, which has been stalled waiting for the active timestamps to be lit, now mates the dance. The initial value of the cookie is zero. If a COOKIE response has not been received by either peer, the next message sent is a COOKIE request. The recipient rolls a random cookie, lights CKY and returns the encrypted cookie. The recipient decrypts the cookie and lights CKY. It is not a protocol error if both peers happen to send a COOKIE request at the same time. In this case both peers will have two values, one generated by itself and the other received from the other peer. In such cases the working cookie is constructed as the EXOR of the two values.
At the next packet transmission opportunity, either peer generates a new key list and lights LST; however, there may already be an AUTO request queued for transmission and the rules say no more than one request in a packet. When available, either peer sends an AUTO response and dims LST. The recipient initializes the autokey values and lights LST and AUT. Subsequent packets received without extension fields are validated by the autokey sequence.
The above description assumes the active peer synchronizes to the passive peer, which itself is synchronized to some other source, such as a radio clock or another NTP server. In this case, the active peer is operating at a stratum level one greater than the passive peer and so the passive peer will not synchronize to it unless it loses its own sources and the active peer itself has another source. Various other intricate scenarios are possible.
| TOC |
The Autokey protocol state machine includes provisions for various kinds of error conditions that can arise due to missing files, corrupted data, protocol violations and packet loss or misorder, not to mention hostile intrusion. This section describes how the protocol responds to reachability and timeout events which can occur due to such errors. Appendix B (Autokey Error Checking) contains an extended discussion on error checking and timestamp validation.
A persistent NTP association is mobilized by an entry in the configuration file, while an ephemeral association is mobilized upon the arrival of a broadcast, manycast or symmetric active packet with no matching association. If necessary, a general reset reinitializes all association variables to the initial state when first mobilized. In addition, if the association is ephemeral, the association is demobilized and all resources acquired are returned to the system.
Every NTP association has two variables which maintain the liveness state of the protocol, the 8-bit reachability register defined in [RFC1305] (Mills, D., “Network Time Protocol (Version 3) Specification, Implementation,” March 1992.) and the watchdog timer, which is new in NTPv4. At every poll interval the reachability register is shifted left, the low order bit is dimmed and the high order bit is lost. At the same time the watchdog counter is incremented by one. If an arriving packet passes all authentication and sanity checks, the rightmost bit of the reachability register is lit and the watchdog counter is set to zero. If any bit in the reachability register is lit, the server is reachable, otherwise it is unreachable.
When the first poll is sent from an association, the reachability register and watchdog counter are zero. If the watchdog counter reaches a preset threshold before the server becomes reachable, a general reset occurs. This resets the protocol and clears any acquired resources before trying again. If the association is ephemerable, it is demobilized; otherwise, the poll interval is doubled. This reduces the network load for packets that are unlikely to elicit a response.
At each state in the protocol the client expects a particular response from the server. A request is included in the NTP packet sent at each poll interval until a valid response is received or a general reset occurs, in which case the protocol restarts from the beginning. A general reset also occurs for an association when an unrecoverable protocol error occurs. A general reset occurs for all associations when the system clock is first synchronized or the clock is stepped or when the server seed is refreshed.
There are special cases designed to quickly respond to broken associations, such as when a server restarts or refreshes keys. Since the client cookie is invalidated, the server rejects the next client request and returns a crypto-NAK packet. A cryoti-NAK packet has a runt MAC with a key ID of zero and no message digest. The problem for the host is to determine whether it is legitimate or the result of intruder mischief. This is done using the NTPv4 on-wire protocol, which requites the crypto-NAK, as well as all responses, to be believed only if the result of a previous packet sent by the host and not a replay, as confirmed by the LBK and DUP status bits described above. While this defense can be easily circumvented by a middleman, it does deflect other kinds of intruder warfare.
There are a number of situations where some event happens that causes the remaining autokeys on the key list to become invalid. When one of these situations happens, the key list and associated autokeys in the key cache are purged. A new key list, signature and timestamp are generated when the next NTP message is sent, assuming there is one. Following is a list of these situations:
| TOC |
This section discusses the most obvious security vulnerabilities in the various Autokey dances. First, some observations on the particular engineering parameters of the Autokey protocol are in order. The number of bits in some cryptographic values are considerably smaller than would ordinarily be expected for strong cryptography. One of the reasons for this is the need for compatibility with previous NTP versions; another is the need for small and constant latencies and minimal processing requirements. Therefore, what the scheme gives up on the strength of these values must be regained by agility in the rate of change of the cryptographic basis values. Thus, autokeys are used only once and seed values are regenerated frequently. However, in most cases even a successful cryptanalysis of these values compromises only a particular association and does not represent a danger to the general population.
Throughout the following discussion the cryptographic algorithms and private values themselves are assumed secure; that is, a brute force cryptanalytic attack will not reveal the host private key, sign private key, cookie value, identity parameters, server seed or autokey seed. In addition, an intruder will not be able to predict random generator values or predict the next autokey. On the other hand, the intruder can remember the totality of all past values for all packets ever sent. Ordinarily, the timestamp/filestamp provisions will make such possesions unusable.
| TOC |
While the protocol has not been subjected to a formal analysis, a few preliminary assertions can be made. The protocol cannot loop forever in any state, since the watchdog counter and general reset insure that the association variables will eventually be purged and the protocol restarted from the beginning. However, if something is seriously wrong, the timeout/restart cycle could continue indefinitely until whatever is wrong is fixed. This is not a clogging hazard, as the timeout period is very long compared to expected network delays.
The LBK and DUP bits described in the main body and Appendix B (Autokey Error Checking) are effective whether or not cryptographic means are in use. The DUP bit deflects duplicate packets in any mode, while the LBK bit deflects bogus packets in all except broadcast mode. All packets must have the correct MAC, as verified with correct key ID and cookie. In all modes the next key ID cannot be predicted by a wiretapper, so are of no use for cryptanalysis.
As long as the client has validated the server certificate trail, a wiretapper cannot produce a convincing signature and cannot produce cryptographic values acceptable to the client. As long as the identity values are not compromised, a middleman cannot masquerade as a legitimate group member and produce convincing certificates or signatures. In server and symmetric modes after the preliminary exchanges have concluded, extension fields are no longer used, a client validates the packet using the autokey sequence. A wiretapper cannot predict the next Key IDs, so cannot produce a valid MAC. A middleman cannot successfully modify and replay a message, since he does not know the cookie and without the cookie cannot produce a valid MAC.
In broadcast mode a wiretapper cannot produce a key list with signed autokey values that a client will accept. The most it can do is replay an old packet causing clients to repeat the autokey hash operations until exceeding the maximum key number. However, a middleman could intercept an otherwise valid broadcast packet and produce a bogus packet with acceptable MAC, since in this case it knows the key ID before the clients do. Of course, the middleman key list would eventually be used up and clients would discover the ruse when verifying the signature of the autokey values. There does not seem to be a suitable defense against this attack.
During the exchanges where extension fields are in use, the cookie is a public value rather than a shared secret and an intruder can easily construct a packet with a valid MAC, but not a valid signature. In the certificate and identity exchanges an intruder can generate fake request messages which may evade server detection; however, the LBK and DUP bits minimize the client exposure to the resulting rogue responses. A wiretapper might be able to intercept a request, manufacture a fake response and loft it swiftly to the client before the real server response. A middleman could do this without even being swift. However, once the identity exchange has completed and the PRV bit lit, these attacks are readily deflected.
A client instantiates cryptographic variables only if the server is synchronized to a proventic source. A server does not sign values or generate cryptographic data files unless synchronized to a proventic source. This raises an interesting issue: how does a client generate proventic cryptographic files before it has ever been synchronized to a proventic source? [Who shaves the barber if the barber shaves everybody in town who does not shave himself?] In principle, this paradox is resolved by assuming the primary (stratum 1) servers are proventicated by external phenomenological means.
There is a significant vulnerability in the underlying NTP on-wire protocol. Until confirming the first exchange when a host first comes up, an intruder can replay an old message, which cause the LBK and DUP bits to be reset. If the intruder does this repeatedly, the host may never synchronize. This vulnerability is the same as with TCP.
| TOC |
There are two clogging vulnerabilities exposed in the protocol design: an encryption attack where the intruder hopes to clog the victim server with needless cookie or signature encryptions or identity calculations, and a decryption attack where the intruder attempts to clog the victim client with needless cookie or verification decryptions. Autokey uses public key cryptography and the algorithms that perform these functions consume significant processor resources.
In order to reduce exposure to decryption attacks the LBK and DUP bits deflect bogus and replayed packets before invoking any cryptographic operations. In order to reduce exposure to encryption attacks, signatures are computed only when the data have changed. For instance, the autokey values are signed only when the key list is regenerated, which happens about once an hour, while the public values are signed only when one of them changes or the server seed is refreshed, which happens about once per day.
In some Autokey dances the protocol precludes server state variables on behalf of an individual client, so a request message must be processed and the response message sent without delay. The identity, cookie and sign exchanges are particularly vulnerable to a clogging attack, since these exchanges can involve expensive cryptographic algorithms as well as digital signatures. A determined intruder could replay identity, cookie or sign requests at high rate, which may very well be a useful munition for an encryption attack. Ordinarily, these requests are seldom used, except when the protocol is restarted or the server seed or public values are refreshed.
Once synchronized to a proventic source, a legitimate extension field with timestamp the same as or earlier than the most recent received of that type is immediately discarded. This foils a middleman cut-and-paste attack using an earlier AUTO response, for example. A legitimate extension field with timestamp in the future is unlikely, as that would require predicting the autokey sequence. In either case the extension field is discarded before expensive signature computations. This defense is most useful in symmetric mode, but a useful redundancy in other modes.
The client is vulnerable to a certificate clogging attack until declared proventic, after which CERT responses are discarded. Before that, a determined intruder could flood the client with bogus certificate responses and force spurious signature verifications, which of course would fail. The intruder could flood the server with bogus certificate requests and cause similar mischief. Once declared proventic, further certificate responses are discard, so these attacks would fail. The intruder could flood the server with replayed sign requests and cause the server to verify the request and sign the response, although the client would drop the response due invalid timestamp.
An interesting adventure is when an intruder replays a recent packet with an intentional bit error. A stateless server will return a crypto-NAK message which the client will notice and discard, since the LBK bit is lit. However, a legitimate crypto-NAK is sent if the server has just refreshed the server seed. In this case the LBK bit is dim and the client performs a general reset and restarts the protocol as expected. Another adventure is to replay broadcast mode packets at high rate. These will be rejected by the clients by the timestamp check and before consuming signature cycles.
In broadcast and symmetric modes the client must include the association ID in the AUTO request. Since association ID values for different invocations of the NTP daemon are randomized over the 16-bit space, it is unlikely that a bogus request would match a valid association with different IP addresses, for example, and cause confusion.
| TOC |
Any IANA registries needed?
| TOC |
...
| TOC |
| TOC |
| [I-D.ietf-ntp-ntpv4-proto] | Kasch, W., Mills, D., and J. Burbank, “Network Time Protocol Version 4 Protocol And Algorithms Specification,” draft-ietf-ntp-ntpv4-proto-13 (work in progress), October 2009 (TXT). |
| TOC |
| [GUILLOU] | Guillou, L. and J. Quisquatar, “A "paradoxical" identity-based signature scheme resulting from zero-knowledge,” 1990. |
| [MU] | Mu, Y. and V. Varadharajan, “Robust and secure broadcasting,” 2001. |
| [RFC1305] | Mills, D., “Network Time Protocol (Version 3) Specification, Implementation,” RFC 1305, March 1992 (TXT, PDF). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC2412] | Orman, H., “The OAKLEY Key Determination Protocol,” RFC 2412, November 1998 (TXT, HTML, XML). |
| [RFC2522] | Karn, P. and W. Simpson, “Photuris: Session-Key Management Protocol,” RFC 2522, March 1999 (TXT). |
| [RFC2875] | Prafullchandra, H. and J. Schaad, “Diffie-Hellman Proof-of-Possession Algorithms,” RFC 2875, July 2000 (TXT). |
| [RFC3279] | Bassham, L., Polk, W., and R. Housley, “Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 3279, April 2002 (TXT). |
| [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, April 2002 (TXT). |
| [RFC4210] | Adams, C., Farrell, S., Kause, T., and T. Mononen, “Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP),” RFC 4210, September 2005 (TXT). |
| [RFC4302] | Kent, S., “IP Authentication Header,” RFC 4302, December 2005 (TXT). |
| [RFC4303] | Kent, S., “IP Encapsulating Security Payload (ESP),” RFC 4303, December 2005 (TXT). |
| [RFC4306] | Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” RFC 4306, December 2005 (TXT). |
| [SCHNORR] | Schnorr, C., “Efficient signature generation for smart cards,” 1991. |
| [STINSON] | Stinson, D., “Cryptography - Theory and Practice,” 1995. |
| TOC |
This appendix describes how cryptographic keys and certificates are generated and managed in the NTPv4 reference implementation. These means are not intended to become part of any standard that may be evolved from this report, but to serve as an example of how these functions can be implemented and managed in a typical operational environment.
The ntp-keygen utility program in the NTPv4 software library generates public/private key files, certificate files and identity key/parameter files. By default the modulus of all encryption and identity keys is 512 bits. All random cryptographic data are based on a pseudo-random number generator seeded in such a way that random values are exceedingly unlikely to repeat. The files are in ASN.1 format, encrypted is necessary, then PEM encoded in printable ASCII format suitable for mailing as MIME objects.
Every file has a filestamp, which is a string of decimal digits representing the NTP seconds when the file was created. The file name is formed from the concatenation of the host name, filestamp and constant strings, so files can be copied from one environment to another while preserving the original filestamp. The file header includes the file name and date and generation time in printable ASCII. The utility assumes the host is synchronized to a proventic source at the time of generation, so that filestamps are proventic data. This raises an interesting circularity issue that will not be further explored here.
The generated files are typically stored in NFS mounted file systems, with files containing private keys obscured to all but root. Symbolic links are installed from default file names assumed by the NTP daemon to the selected files. Since the files of successive generations and different hosts have unique names, there is no possibility of name collisions.
Public/private host and sign keys and certificates must be generated by the host to which they belong. The host key must be RSA, since it is used to encrypt the cookie, as well as encrypt signatures by default. The optional sign key can be RSA or DSA, since it is used only to encrypt signatures. In principle, certificates could be generated directly by OpenSSL utility programs, as long as the symbolic links are consistent.
Identity keys and parameters must be generated by the ntp-keygen utility, since they have proprietary formats. Since these are private to the group, they are generated by one host acting as a trusted authority and then distributed to all other members of the group by secure means.
Certificates are usually, but not necessarily, generated by the host to which they belong. The ntp-keygen utility generates self-signed X.509v3 host certificate files with optional extension fields. Certificate requests are not used, since the certificate itself is used as a request to be signed. OpenSSL X.509v3 certificates are generated as an OpenSSL structure, which is then PEM encoded in ASN.1 syntax and written to the host certificate file. The string returned by the Unix gethostname() routine is used by default for both the subject and issuer fields. The serial number and begin time fields are derived from the filestamp; the end time is one year hence. The host certificate is signed by the sign key or host key if a sign key is not present.
An important design goal is to make cryptographic data refreshment as simple and intuitive as possible, so it can be driven by scripts on a periodic basis. When the ntp-keygen utility is run for the first time, it creates by default a RSA host key file and RSA-MD5 host certificate file and necessary symbolic links. After that, it creates a new certificate file and symbolic link using the existing host key. The program run with given options creates identity key/parameter files for one or more IFF, GQ or MV identity schemes. The key files must then be securely copied to all other group members and symbolic links installed from the default names to the installed files. In the GQ scheme the next and each subsequent time the ntp-keygen utility runs, it automatically creates or updates the private/public identity key files and certificate file using the existing identity parameters.
| TOC |
Exhaustive examination of possible vulnerabilities at the various processing steps of the NTPv3 protocol as specified in [RFC1305] (Mills, D., “Network Time Protocol (Version 3) Specification, Implementation,” March 1992.) have resulted in a revised list of packet sanity tests. There are 12 tests in the NTPv4 reference implementation, called TEST1 through TEST12, which are performed in a specific order designed to gain maximum diagnostic information while protecting against an accidental or malicious clogging attacks. These tests are described in detail in the NTP software documentation. Those relevant to the Autokey protocol are described in this appendix.
The sanity tests are classified in four tiers. The first tier deflects access control and message digest violations. The second, represented by the autokey sequence, deflects spoofed or replayed packets. The third, represented by timestamped digital signatures, binds cryptographic values to verifiable credentials. The fourth deflects packets with invalid NTP header fields or out of bounds time values. However, the tests in this last group do not directly affect cryptographic protocol vulnerability, so are beyond the scope of discussion here.
| TOC |
Every arriving NTP packet is checked enthusiastically for format, content and protocol errors. Some packet header fields are checked by the main NTP code path both before and after the Autokey protocol engine cranks. These include the NTP version number, overall packet length and extension field lengths. The total length of all extension fields may be no longer than 1024 octets in the reference implementation. Packets failing any of these checks are discarded immediately. Packets denied by the access control mechanism will be discarded later, but processing continues temporarily in order to gather further information useful for error recovery and reporting.
Next, the cookie and session key are determined and the MAC computed as described above. If the MAC fails to match the value included in the packet, the action depends on the mode and the type of packet. Packets failing the MAC check will be discarded later, but processing continues temporarily in order to gather further information useful for error recovery and reporting.
The NTP transmit and receive timestamps are in effect nonces, since an intruder cannot effectively guess either value in advance. To minimize the possibility that an intruder can guess the nonces, the low order unused bits in all timestamps are obscured with random values. If the transmit timestamp matches the transmit timestamp in the last packet received, the packet is a duplicate, so the DUP bit is lit. If the packet mode is not broadcast and the last transmit timestamp does not match the originate timestamp in the packet, either it was delivered out of order or an intruder has injected a rogue packet, so the LBK bit is lit. Packets with either the DUP or LBK bit will be discarded later, but processing continues temporarily in order to gather further information useful for error recovery and reporting.
Further indicators of the server and client state are apparent from the transmit and receive timestamps of both the packet and the association. The quite intricate rules take into account these and the above error indicators They are designed to discriminate between legitimate cases where the server or client are in inconsistent states and recoverable, and when an intruder is trying to destabilize the protocol or force consumption of needless resources. The exact behavior is beyond the scope of discussion, but is clearly described in the source code documentation.
Next, the Autokey protocol engine is cranked and the dances evolve as described above. Some requests and all responses have value fields which carry timestamps and filestamps. When the server or client is synchronized to a proventic source, most requests and responses with value fields carry signatures with valid timestamps. When not synchronized to a proventic source, value fields carry an invalid (zero) timestamp and the signature field and signature length word are omitted.
The extension field parser checks that the Autokey version number, operation code and field length are valid. If the error bit is lit in a request, the request is discarded without response; if an error is discovered in processing the request, or if the responder is not synchronized to a proventic source, the response contains only the first two words of the request with the response and error bits lit. For messages with signatures, the parser requires that timestamps and filestamps are valid and not a replay, that the signature length matches the certificate public key length and only then verifies the signature. Errors are reported via the security logging facility.
All certificates must have correct ASN.1 encoding, supported digest/signature scheme and valid subject, issuer, public key and, for self-signed certificates, valid signature. While the begin and end times can be checked relative to the filestamp and each other, whether the certificate is valid relative to the actual time cannot be determined until the client is synchronized to a proventic source and the certificate is signed and verified by the server.
When the protocol starts the only response accepted is ASSOC with valid timestamp, after which the server status word must be nonzero. ASSOC responses are discarded if this word is nonzero. The only responses accepted after that and until the PRV bit is lit are CERT, IFF and GQ. Once identity is confirmed and IFF is lit, these responses are no longer accepted, but all other responses are accepted only if in response to a previously sent request and only in the order prescribed in the protocol dances. Additional checks are implemented for each request type and dance step.
| TOC |
When the host starts, it reads the host key and certificate files, which are required for continued operation. It also reads the sign key and leapseconds file, when available. When reading these files the host checks the file formats and filestamps for validity; for instance, all filestamps must be later than the time the UTC timescale was established in 1972 and the certificate filestamp must not be earlier than its associated sign key filestamp. In general, at the time the files are read, the host is not synchronized, so it cannot determine whether the filestamps are bogus other than these simple checks.
In the following the relation A --> B is Lamport's "happens before" relation, which is true if event A happens before event B. When timestamps are compared to timestamps, the relation is false if A <--> B; that is, false if the events are simultaneous. For timestamps compared to filestamps and filestamps compared to filestamps, the relation is true if A <--> B. Note that the current time plays no part in these assertions except in (6) below; however, the NTP protocol itself insures a correct partial ordering for all current time values.
The following assertions apply to all relevant responses:
| TOC |
Certificate extension fields are used to convey information used by the identity schemes, such as whether the certificate is private, trusted or contains a public identity key. While the semantics of these fields generally conforms with conventional usage, there are subtle variations. The fields used by Autokey Version 2 include:
| TOC |
The Internet infrastructure model described in [RFC4210] (Adams, C., Farrell, S., Kause, T., and T. Mononen, “Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP),” September 2005.) is based on certificate trails where a subject proves identity to a certificate authority (CA) who then signs the subject certificate using the CA issuer key. The CA in turn proves identity to the next CA and obtains its own signed certificate. The trail continues to a CA with a self-signed trusted root certificate independently validated by other means. If it is possible to prove identity at each step, each certificate along the trail can be considered trusted relative to the identity scheme and trusted root certificate.
The important issue with respect to NTP is the cryptographic strength of the identity scheme, since if a middleman could compromise it, the trail would have a security breach. In electric mail and commerce the identity scheme can be based on handwritten signatures, photographs, fingerprints and other things very hard to counterfeit. As applied to NTP subnets and identity proofs, the scheme must allow a client to securely verify that a server knows the same secret that it does, presuming the secret was previously instantiated by secure means, but without revealing the secret to members outside the group.
While the identity scheme described in RFC-2875 [RFC2875] (Prafullchandra, H. and J. Schaad, “Diffie-Hellman Proof-of-Possession Algorithms,” July 2000.) is based on a ubiquitous Diffie-Hellman infrastructure, it is expensive to generate and use when compared to others described in this appendix. There are five schemes now implemented in the NTPv4 reference implementation to prove identity: (1) private certificate (PC), (2) trusted certificate (TC), (3) a modified Schnorr algorithm (IFF aka Identify Friendly or Foe), (4) a modified Guillou-Quisquater algorithm (GQ), and (5) a modified Mu-Varadharajan algorithm (MV). The available schemes are selected during the key generation phase, with the particular scheme selected during the parameter exchange.
The IFF, GQ and MV schemes involve a cryptographically strong challenge-response exchange where an intruder cannot learn the group key, even after repeated observations of multiple exchanges. These schemes begin when the client sends a nonce to the server, which then rolls its own nonce, performs a mathematical operation and sends the results along with a message digest to the client. The client performs a second mathematical operation to produce a digest that must match the one included in the message. To the extent that a server can prove identity to a client without either knowing the group key, a scheme is properly described as a zero-knowledge proof.
| TOC |
The PC scheme shown in Figure Figure 10 (Private Certificate (PC) Identity Scheme) involves the use of a private certificate as group key. A certificate is designated private by a X509 Version 3 extension field when generated by utility routines in the NTP software distribution. The certificate is distributed to all other group members by secure means and is never revealed outside the group. A client is marked trusted in the Parameter Exchange and authentic when the first signature is verified. This scheme is cryptographically strong as long as the private certificate is protected; however, it can be very awkward to refresh the keys or certificate, since new values must be securely distributed to a possibly large population and activated simultaneously.
Trusted
Authority
Secure +-------------+ Secure
+--------------| Certificate |-------------+
| +-------------+ |
| |
\|/ \|/
+-------------+ +-------------+
| Certificate | | Certificate |
+-------------+ +-------------+
Server Client
| Figure 10: Private Certificate (PC) Identity Scheme |
The PC scheme uses a private certificate as group key. A certificate is designated private for the purpose of the this scheme if the CIS Private bit is lit. The certificate is distributed to all other group members by secret means and never revealed outside the group. There is no identity exchange, since the certificate itself is the group key. Therefore, when the parameter exchange completes the VAL, IFF and SGN bits are lit in the server status word. When the following cookie exchange is complete, the PRV bit is lit and operation continues as described in the main body of this report.
| TOC |
All other schemes involve a conventional certificate trail as shown in Figure Figure 11 (Private Certificate (PC) Identity Scheme). As described in RFC-4210 [RFC4210] (Adams, C., Farrell, S., Kause, T., and T. Mononen, “Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP),” September 2005.), each certificate is signed by an issuer one step closer to the trusted host, which has a self-signed trusted certificate, A certificate is designated trusted by a X509 Version 3 extension field when generated by utility routines in the NTP software distribution. A host obtains the certificates of all other hosts along the trail leading to a trusted host by the Autokey protocol, then requests the immediately ascendant host to sign its certificate. Subsequently, these certificates are provided to descendent hosts by the Autokey protocol. In this scheme keys and certificates can be refreshed at any time, but a masquerade vulnerability remains unless a request to sign a client certificate is validated by some means such as reverse-DNS. If no specific identity scheme is specified in the Identification Exchange, this is the default TC scheme.
Trusted
Host Host Host
+-----------+ +-----------+ +-----------+
+--->| Subject | +--->| Subject | +--->| Subject |
| +-----------+ | +-----------+ | +-----------+
...---+ | Issuer |---+ | Issuer |---+ | Issuer |
+-----------+ +-----------+ +-----------+
| Signature | | Signature | | Signature |
+-----------+ +-----------+ +-----------+
| Figure 11: Private Certificate (PC) Identity Scheme |
The TC identification exchange follows the parameter exchange in which the VAL bit is lit. It involves a conventional certificate trail and a sequence of certificates, each signed by an issuer one stratum level lower than the client, and terminating at a trusted certificate, as described in [RFC4210] (Adams, C., Farrell, S., Kause, T., and T. Mononen, “Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP),” September 2005.). A certificate is designated trusted for the purpose of the TC scheme if the CIS Trust bit is lit and the certificate is self-signed. Such would normally be the case when the trail ends at a primary (stratum 1) server, but the trail can end at a secondary server if the security model permits this.
When a certificate is obtained from a server, or when a certificate is signed by a server, A CIS for the new certificate is pushed on the certificate list, but only if the certificate filestamp is greater than any with the same subject name and issuer name already on the list. The list is then scanned looking for signature opportunities. If a CIS issuer name matches the subject name of another CIS and the issuer certificate is verified using the public key of the subject certificate, the CIS Sign bit is lit in the issuer CIS. Furthermore, if the Trust bit is lit in the subject CIS, the Trust bit is lit in the issuer CIS.
The client continues to follow the certificate trail to a self-signed certificate, lighting the Sign and Trust bits as it proceeds. If it finds a self-signed certificate with Trust bit lit, the client lights the IFF and PRV bits and the exchange completes. It can, however, happen that the client finds a self-signed certificate with Trust bit dark. This can happen when a server is just coming up, has synchronized to a proventic source, but has not yet completed the Sign exchange. This is considered a temporary condition, so the client simply retries at poll opportunities until the server certificate is signed.
| TOC |
The Schnorr (IFF) identity scheme is useful when certificates are generated by means other than the NTP software library, such as a trusted public authority. In this case a X.509v3 extension field might not be available to convey the identity public key. The scheme involves a set of parameters which persist for the life of the scheme. New generations of these parameters must be securely transmitted to all members of the group before use. The scheme is self contained and independent of new generations of host keys, sign keys and certificates.
Certificates can be generated by the OpenSSL library or an external public certificate authority, but conveying an arbitrary public value in a certificate extension field might not be possible. The TA generates IFF parameters and keys and distributes them by secure means to all servers, then removes the group key and redistributes these data to dependent clients. Without the group key a client cannot masquerade as a legitimate server.
The IFF parameters are generated by OpenSSL routines normally used to generate DSA keys. By happy coincidence, the mathematical principles on which IFF is based are similar to DSA, but only the moduli p, q and generator g are used in identity calculations. The parameters hide in a DSA cuckoo structure and use the same members. The values are used by an identity scheme based on DSA cryptography and described in [SCHNORR] (Schnorr, C., “Efficient signature generation for smart cards,” 1991.) and [STINSON] (Stinson, D., “Cryptography - Theory and Practice,” 1995.) p. 285. The p is a 512-bit prime, g a generator of the multiplicative group Zp* and q a 160-bit prime that divides (p-1) and is a qth root of 1 mod p; that is, g^q mod p. The TA rolls a private random group key b (0 < b < q), then computes public client key v = g^(q-b) mod p. The TA distributes (p, q, g, b) to all servers using secure means and (p, q, g, v) to all clients not necessarily using secure means.
Trusted
Authority
+------------+
| Parameters |
Secure +------------+ Insecure
+-------------| Group Key |-----------+
| +------------+ |
| | Client Key | |
| +------------+ |
\|/ \|/
+------------+ Challenge +------------+
| Parameters |<------------------------| Parameters |
+------------+ +------------+
| Group Key |------------------------>| Client Key |
+------------+ Response +------------+
Server Client
| Figure 12: Schnorr (IFF) Identity Scheme |
The IFF identity scheme is shown in Figure Figure 12 (Schnorr (IFF) Identity Scheme). The TA generates a DSA parameter structure for use as IFF parameters. The IFF parameters are identical to the DSA parameters, so the OpenSSL library DSA parameter generation routine can be used directly. The DSA parameter structure shown in Table Figure 13 (IFF Identity Scheme Parameters) is written to a file as a DSA private key encoded in PEM. Unused structure members are set to one.
+----------------------------------+-------------+ | IFF | DSA | Item | Include | +=========+==========+=============+=============+ | p | p | modulus | all | +---------+----------+-------------+-------------+ | q | q | modulus | all | +---------+----------+-------------+-------------+ | g | g | generator | all | +---------+----------+-------------+-------------+ | b | priv_key | group key | server | +---------+----------+-------------+-------------+ | v | pub_key | client keys | client | +---------+----------+-------------+-------------+
| Figure 13: IFF Identity Scheme Parameters |
Alice challenges Bob to confirm identity using the following protocol exchange.
If the hashes match, Alice knows that Bob has the group key b. Besides making the response shorter, the hash makes it effectively impossible for an intruder to solve for b by observing a number of these messages. The signed response binds this knowledge to Bob's private key and the public key previously received in his certificate. On success the IFF and PRV bits are lit in the server status word.
| TOC |
The Guillou-Quisquater (GQ) identity scheme is useful when certificates are generated using the NTP software library. These routines convey the GQ public key in a X.509v3 extension field. The scheme involves a set of parameters which persist for the life of the scheme and a private/public identity key, which is refreshed each time a new certificate is generated. The utility inserts the client key in an X.509 extension field when the certificate is generated. The client key is used when computing the response to a challenge. The TA generates the GQ parameters and keys and distributes them by secure means to all group members. The scheme is self contained and independent of new generations of host keys and sign keys and certificates.
The GQ parameters are generated by OpenSSL routines normally used to generate RSA keys. By happy coincidence, the mathematical principles on which GQ is based are similar to RSA, but only the modulus n is used in identity calculations. The parameters hide in a RSA cuckoo structure and use the same members. The values are used in an identity scheme based on RSA cryptography and described in [GUILLOU] (Guillou, L. and J. Quisquatar, “A "paradoxical" identity-based signature scheme resulting from zero-knowledge,” 1990.) and [STINSON] (Stinson, D., “Cryptography - Theory and Practice,” 1995.) p. 300 (with errors). The 512-bit public modulus n=pq, where p and q are secret large primes. The TA rolls random group key b (0 < b < n) and distributes (n, b) to all group members using secure means. The private server key and public client key are constructed later.
Trusted
Authority
+------------+
| Parameters |
Secure +------------+ Secure
+-------------| Group Key |-----------+
| +------------+ |
\|/ \|/
+------------+ Challenge +------------+
| Parameters |<------------------------| Parameters |
+------------+ +------------+
| Group Key | | Group Key |
+------------+ Response +------------+
| Server Key |------------------------>| Client Key |
+------------+ +------------+
Server Client
| Figure 14: Schnorr (IFF) Identity Scheme |
The GQ identity scheme is shown in Figure Figure 14 (Schnorr (IFF) Identity Scheme). When generating new certificates, the server rolls new random private server key u (0 < u < n) and public client key its inverse obscured by the group key v = (u^-1)^b mod n. These values replace the private and public keys normally generated by the RSA scheme. In addition, the public client key is conveyed in a X.509 certificate extension. The updated GQ structure shown in Figure Figure 15 (IFF Identity Scheme Parameters) is written as an RSA private key encoded in PEM. Unused structure members are set to one.
+---------------------------------+-------------+ | GQ | RSA | Item | Include | +=========+==========+============+=============+ | n | n | modulus | all | +---------+----------+------------+-------------+ | b | e | group key | server | +---------+----------+------------+-------------+ | u | p | server key | server | +---------+----------+------------+-------------+ | v | q | client key | client | +---------+----------+------------+-------------+
| Figure 15: IFF Identity Scheme Parameters |
Alice challenges Bob to confirm identity using the following exchange.
If the hashes match, Alice knows that Bob has the group key b. Besides making the response shorter, the hash makes it effectively impossible for an intruder to solve for b by observing a number of these messages. The signed response binds this knowledge to Bob's private key and the public key previously received in his certificate. Further evidence is the certificate containing the public identity key, since this is also signed with Bob's private key. On success the IFF and PRV bits are lit in the server status word.
| TOC |
The Mu-Varadharajan (MV) scheme was originally intended to encrypt broadcast transmissions to receivers which do not transmit. There is one encryption key for the broadcaster and a separate decryption key for each receiver. It operates something like a pay-per-view satellite broadcasting system where the session key is encrypted by the broadcaster and the decryption keys are held in a tamper proof set-top box. We don't use it this way, but read on.
The MV scheme is perhaps the most interesting and flexible of the three challenge/response schemes. It can be used when a small number of servers provide synchronization to a large client population where there might be considerable risk of compromise between and among the servers and clients. The TA generates an intricate cryptosystem involving public and private encryption keys, together with a number of activation keys and associated private client decryption keys. The activation keys are used by the TA to activate and revoke individual client decryption keys without changing the decryption keys themselves.
The TA provides the server with a private encryption key and public decryption key. The server adjusts the keys by a nonce for each plaintext encryption, so they appear different on each use. The encrypted ciphertext and adjusted public decryption key are provided in the client message. The client computes the decryption key from its private decryption key and the public decryption key in the message.
In the MV scheme the activation keys are known only to the TA. The TA decides which keys to activate and provides to the servers a private encryption key E and public decryption keys g-bar and g-hat which depend on the activated keys. The servers have no additional information and, in particular, cannot masquerade as a TA. In addition, the TA provides to each client j individual private decryption keys x-bar_j and x-hat_j , which do not need to be changed if the TA activates or deactivates this key. The clients have no further information and, in particular, cannot masquerade as a server or TA.
The MV values hide in a DSA cuckoo structure which uses the same parameters, but generated in a different way. The values are used in an encryption scheme similar to El Gamal cryptography and a polynomial formed from the expansion of product terms (x-x_1)*(x-x_2)*(x-x_3)*...*(x-x_n), as described in [MU] (Mu, Y. and V. Varadharajan, “Robust and secure broadcasting,” 2001.). The paper has significant errors and serious omissions.
Trusted
Authority
+------------+
| Parameters |
+------------+
| Group Key |
+------------+
| Server Key |
Secure +------------+ Secure
+-------------| Client Key |-----------+
| +------------+ |
\|/ \|/
+------------+ Challenge +------------+
| Parameters |<------------------------| Parameters |
+------------+ +------------+
| Server Key |------------------------>| Client Key |
+------------+ Response +------------+
Server Client
| Figure 16: Mu-Varadharajan (MV) Identity Scheme |
The MV identity scheme is shown in Figure Figure 16 (Mu-Varadharajan (MV) Identity Scheme). The TA writes the server parameters, private encryption key and public decryption keys for all servers as a DSA private key encoded in PEM, as shown in the Figure Figure 17 (MV Scheme Server Parameters).
+---------------------------------+-------------+ | MV | DSA | Item | Include | +=========+==========+============+=============+ | p | p | modulus | all | +---------+----------+------------+-------------+ | q | q | modulus | server | +---------+----------+------------+-------------+ | E | g | private | server | | | | encrypt | | +---------+----------+------------+-------------+ | g-bar | priv_key | public | server | | | | decrypt | | +---------+----------+------------+-------------+ | g-hat | pub_key | public | server | | | | decrypt | | +---------+----------+------------+-------------+
| Figure 17: MV Scheme Server Parameters |
The TA writes the client parameters and private decryption keys for each client as a DSA private key encoded in PEM. It is used only by the designated recipient(s) who pay a suitably outrageous fee for its use. Unused structure members are set to one, as shown in Table Figure 18 (MV Scheme Client Parameters),
+---------------------------------+-------------+ | MV | DSA | Item | Include | +=========+==========+============+=============+ | p | p | modulus | all | +---------+----------+------------+-------------+ | x-bar_j | priv_key | public | client | | | | decrypt | | +---------+----------+------------+-------------+ | x-hat_j | pub_key | public | client | | | | decrypt | | +---------+----------+------------+-------------+
| Figure 18: MV Scheme Client Parameters |
The devil is in the details. Let q be the product of n distinct primes s'_j (j = 1...n), where each s'_j, also called an activation key, has m significant bits. Let prime p = 2q + 1, so that q and each s'_j divide p-1 and p has M=nm+1 significant bits. Let g be the generator of the multiplicative group Zp*; that is, gcd(g, p-1) = 1 and g^q = 1 mod p. We do modular arithmetic over Zq and then project into Zp* as powers of g. Sometimes we have to compute an inverse b^-1 of random b in Zq, but for that purpose we require gcd(b, q) = 1. We expect M to be in the 500-bit range and n relatively small, like 30. The TA uses a nasty probabilistic algorithm to generate the cryptosystem.
Once the cryptosystem parameters have been determined, the TA sets up a specific instance of the scheme as follows.
Alice challenges Bob to confirm identity using the following exchange.
| TOC |
A specific combination of authentication scheme (none, symmetric key, Autokey), digest/signature scheme and identity scheme (PC, TC, IFF, GQ, MV) is called a cryptotype, although not all combinations are possible. There may be management configurations where the servers and clients may not all support the same cryptotypes. A secure NTPv4 subnet can be configured in several ways while keeping in mind the principles explained in this section. Note however that some cryptotype combinations may successfully interoperate with each other, but may not represent good security practice.
The cryptotype of an association is determined at the time of mobilization, either at configuration time or some time later when a packet of appropriate cryptotype arrives. When a client, broadcast or symmetric active association is mobilized at configuration time, it can be designated non-authentic, authenticated with symmetric key or authenticated with some Autokey scheme, and subsequently it will send packets with that cryptotype. When a responding server, broadcast client or symmetric passive association is mobilized, it is designated with the same cryptotype as the received packet.
When multiple identity schemes are supported, the parameter exchange determines which one is used. The request message contains bits corresponding to the schemes it supports, while the response message contains bits corresponding to the schemes it supports. The client matches the server bits with its own and selects a compatible identity scheme. The server is driven entirely by the client selection and remains stateless. When multiple selections are possible, the order from most secure to least is GC, IFF, TC. Note that PC does not interoperate with any of the others, since they require the host certificate which a PC server will not reveal.
Following the principle that time is a public value, a server responds to any client packet that matches its cryptotype capabilities. Thus, a server receiving a non-authenticated packet will respond with a non-authenticated packet, while the same server receiving a packet of a cryptotype it supports will respond with packets of that cryptotype. However, new broadcast or manycast client associations or symmetric passive associations will not be mobilized unless the server supports a cryptotype compatible with the first packet received. By default, non-authenticated associations will not be mobilized unless overridden in a decidedly dangerous way.
Some examples may help to reduce confusion. Client Alice has no specific cryptotype selected. Server Bob supports both symmetric key and Autokey cryptography. Alice's non-authenticated packets arrive at Bob, who replies with non-authenticated packets. Cathy has a copy of Bob's symmetric key file and has selected key ID 4 in packets to Bob. If Bob verifies the packet with key ID 4, he sends Cathy a reply with that key. If authentication fails, Bob sends Cathy a thing called a crypto-NAK, which tells her something broke. She can see the evidence using the utility programs of the NTP software library.
Symmetric peers Bob and Denise have rolled their own host keys, certificates and identity parameters and lit the host status bits for the identity schemes they can support. Upon completion of the parameter exchange, both parties know the digest/signature scheme and available identity schemes of the other party. They do not have to use the same schemes, but each party must use the digest/signature scheme and one of the identity schemes supported by the other party.
It should be clear from the above that Bob can support all the girls at the same time, as long as he has compatible authentication and identification credentials. Now, Bob can act just like the girls in his own choice of servers; he can run multiple configured associations with multiple different servers (or the same server, although that might not be useful). But, wise security policy might preclude some cryptotype combinations; for instance, running an identity scheme with one server and no authentication with another might not be wise.
| TOC |
Certain value fields in request and response messages contain data encoded in ASN.1 distinguished encoding rules (DER). The BNF grammar for each encoding rule is given below along with the OpenSSL routine used for the encoding in the reference implementation. The object identifiers for the encryption algorithms and message digest/signature encryption schemes are specified in [RFC3279] (Bassham, L., Polk, W., and R. Housley, “Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002.). The particular algorithms required for conformance are not specified in this report.
| TOC |
The value field of the COOKIE request message contains a sequence of two integers (n, e) encoded by the i2d_RSAPublicKey() routine in the OpenSSL distribution. In the request, n is the RSA modulus in bits and e is the public exponent.
RSAPublicKey ::= SEQUENCE {
n ::= INTEGER,
e ::= INTEGER
}
The IFF and GQ responses contain a sequence of two integers (r, s) encoded by the i2d_DSA_SIG() routine in the OpenSSL distribution. In the responses, r is the challenge response and s is the hash of the private value.
DSAPublicKey ::= SEQUENCE {
r ::= INTEGER,
s ::= INTEGER
}
The MV response contains a sequence of three integers (p, q, g) encoded by the i2d_DSAparams() routine in the OpenSSL library. In the response, p is the hash of the encrypted challenge value and (q, g) is the client portion of the decryption key.
DSAparameters ::= SEQUENCE {
p ::= INTEGER,
q ::= INTEGER,
g ::= INTEGER
}
| TOC |
The value field contains a X509v3 certificate encoded by the i2d_X509() routine in the OpenSSL distribution. The encoding follows the rules stated in [RFC3280] (Housley, R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002.), including the use of X509v3 extension fields.
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
The signatureAlgorithm is the object identifier of the message digest/signature encryption scheme used to sign the certificate. The signatureValue is computed by the certificate issuer using this algorithm and the issuer private key.
TBSCertificate ::= SEQUENCE {
version EXPLICIT v3(2),
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
extensions EXPLICIT Extensions OPTIONAL
}
The serialNumber is an integer guaranteed to be unique for the generating host. The reference implementation uses the NTP seconds when the certificate was generated. The signature is the object identifier of the message digest/signature encryption scheme used to sign the certificate. It must be identical to the signatureAlgorithm.
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore UTCTime,
notAfter UTCTime
}
The notBefore and notAfter define the period of validity as defined in Appendix D (Identity Schemes).
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
The AlgorithmIdentifier specifies the encryption algorithm for the subject public key. The subjectPublicKey is the public key of the subject.
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
}
Name ::= SEQUENCE {
OBJECT IDENTIFIER commonName
PrintableString HostName
}
For all certificates, the subject HostName is the unique DNS name of the host to which the public key belongs. The reference implementation uses the string returned by the Unix gethostname() routine (trailing NUL removed). For other than self-signed certificates, the issuer HostName is the unique DNS name of the host signing the certificate.
| TOC |
| Brian Haberman (editor) | |
| The Johns Hopkins University Applied Physics Laboratory | |
| 11100 Johns Hopkins Road | |
| Laurel, MD 20723-6099 | |
| US | |
| Phone: | +1 443 778 1319 |
| Email: | brian@innovationslab.net |
| Dr. David L. Mills | |
| University of Delaware | |
| Newark, DE 19716 | |
| US | |
| Phone: | +1 302 831 8247 |
| Email: | mills@udel.edu |
| TOC |
Copyright © The IETF Trust (2007).
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, THE IETF TRUST 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.
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.