draft-ietf-ntp-autokey-05.txt   draft-ietf-ntp-autokey-06.txt 
Network Working Group B. Haberman, Ed. Network Working Group B. Haberman, Ed.
Internet-Draft JHU/APL Internet-Draft JHU/APL
Intended status: Informational D. Mills Obsoletes: RFC 1305 D. Mills
Expires: November 30, 2009 U. Delaware (if approved) U. Delaware
May 29, 2009 Intended status: Informational July 8, 2009
Expires: January 9, 2010
Network Time Protocol Version 4 Autokey Specification Network Time Protocol Version 4 Autokey Specification
draft-ietf-ntp-autokey-05 draft-ietf-ntp-autokey-06
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 30, 2009. This Internet-Draft will expire on January 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 13 skipping to change at page 3, line 13
http://www.ntp.org. http://www.ntp.org.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. NTP Security Model . . . . . . . . . . . . . . . . . . . . . . 4 2. NTP Security Model . . . . . . . . . . . . . . . . . . . . . . 4
3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Autokey Cryptography . . . . . . . . . . . . . . . . . . . . . 8 4. Autokey Cryptography . . . . . . . . . . . . . . . . . . . . . 8
5. NTP Secure Groups . . . . . . . . . . . . . . . . . . . . . . 11 5. NTP Secure Groups . . . . . . . . . . . . . . . . . . . . . . 11
6. Identity Schemes . . . . . . . . . . . . . . . . . . . . . . . 15 6. Identity Schemes . . . . . . . . . . . . . . . . . . . . . . . 15
7. Timestamps and Filestamps . . . . . . . . . . . . . . . . . . 16 7. Timestamps and Filestamps . . . . . . . . . . . . . . . . . . 17
8. Autokey Protocol Overview . . . . . . . . . . . . . . . . . . 18 8. Autokey Protocol Overview . . . . . . . . . . . . . . . . . . 18
9. Autokey Operations . . . . . . . . . . . . . . . . . . . . . . 20 9. Autokey Operations . . . . . . . . . . . . . . . . . . . . . . 20
10. Autokey Protocol Messages . . . . . . . . . . . . . . . . . . 21 10. Autokey Protocol Messages . . . . . . . . . . . . . . . . . . 22
10.1. No-Operation . . . . . . . . . . . . . . . . . . . . . . 24 11. No-Operation . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.2. Association Message (ASSOC) . . . . . . . . . . . . . . . 24 12. Association Message (ASSOC) . . . . . . . . . . . . . . . . . 25
10.3. Certificate Message (CERT) . . . . . . . . . . . . . . . 24 13. Certificate Message (CERT) . . . . . . . . . . . . . . . . . . 25
10.4. Cookie Message (COOKIE) . . . . . . . . . . . . . . . . . 24 14. Cookie Message (COOKIE) . . . . . . . . . . . . . . . . . . . 25
10.5. Autokey Message (AUTO) . . . . . . . . . . . . . . . . . 25 15. Autokey Message (AUTO) . . . . . . . . . . . . . . . . . . . . 25
10.6. Leapseconds Values Message (LEAP) . . . . . . . . . . . . 25 16. Leapseconds Values Message (LEAP) . . . . . . . . . . . . . . 26
10.7. Sign Message (SIGN) . . . . . . . . . . . . . . . . . . . 25 17. Sign Message (SIGN) . . . . . . . . . . . . . . . . . . . . . 26
10.8. Identity Messages (IFF, GQ, MV) . . . . . . . . . . . . . 25 18. Identity Messages (IFF, GQ, MV) . . . . . . . . . . . . . . . 26
11. Autokey State Machine . . . . . . . . . . . . . . . . . . . . 25 19. Autokey State Machine . . . . . . . . . . . . . . . . . . . . 26
11.1. Status Word . . . . . . . . . . . . . . . . . . . . . . . 25 20. Status Word . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.2. Host State Variables . . . . . . . . . . . . . . . . . . 27 21. Host State Variables . . . . . . . . . . . . . . . . . . . . . 28
11.3. Client State Variables (all modes) . . . . . . . . . . . 29 22. Client State Variables (all modes) . . . . . . . . . . . . . . 30
11.4. Protocol State Transitions . . . . . . . . . . . . . . . 30 23. Protocol State Transitions . . . . . . . . . . . . . . . . . . 31
11.4.1. Server Dance . . . . . . . . . . . . . . . . . . . . 30 24. Server Dance . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.4.2. Broadcast Dance . . . . . . . . . . . . . . . . . . . 31 25. Broadcast Dance . . . . . . . . . . . . . . . . . . . . . . . 32
11.4.3. Symmetric Dance . . . . . . . . . . . . . . . . . . . 32 26. Symmetric Dance . . . . . . . . . . . . . . . . . . . . . . . 33
11.5. Error Recovery . . . . . . . . . . . . . . . . . . . . . 33 27. Error Recovery . . . . . . . . . . . . . . . . . . . . . . . . 34
11.6. Security Considerations . . . . . . . . . . . . . . . . . 35 28. Security Considerations . . . . . . . . . . . . . . . . . . . 36
11.7. Protocol Vulnerability . . . . . . . . . . . . . . . . . 35 29. Protocol Vulnerability . . . . . . . . . . . . . . . . . . . . 36
11.8. Clogging Vulnerability . . . . . . . . . . . . . . . . . 36 30. Clogging Vulnerability . . . . . . . . . . . . . . . . . . . . 37
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 31. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 32. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
13.1. Normative References . . . . . . . . . . . . . . . . . . 37 32.1. Normative References . . . . . . . . . . . . . . . . . . 38
13.2. Informative References . . . . . . . . . . . . . . . . . 37 32.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Timestamps, Filestamps and Partial Ordering . . . . . 38 Appendix A. Timestamps, Filestamps and Partial Ordering . . . . . 39
Appendix B. Identity Schemes . . . . . . . . . . . . . . . . . . 39 Appendix B. Identity Schemes . . . . . . . . . . . . . . . . . . 41
Appendix C. Private Certificate (PC) Scheme . . . . . . . . . . . 40 Appendix C. Private Certificate (PC) Scheme . . . . . . . . . . . 41
Appendix D. Trusted Certificate (TC) Scheme . . . . . . . . . . . 40 Appendix D. Trusted Certificate (TC) Scheme . . . . . . . . . . . 42
Appendix E. Schnorr (IFF) Identity Scheme . . . . . . . . . . . . 41 Appendix E. Schnorr (IFF) Identity Scheme . . . . . . . . . . . . 42
Appendix F. Guillard-Quisquater (GQ) Identity Scheme . . . . . . 43 Appendix F. Guillard-Quisquater (GQ) Identity Scheme . . . . . . 44
Appendix G. Mu-Varadharajan (MV) Identity Scheme . . . . . . . . 45 Appendix G. Mu-Varadharajan (MV) Identity Scheme . . . . . . . . 46
Appendix H. ASN.1 Encoding Rules . . . . . . . . . . . . . . . . 47 Appendix H. ASN.1 Encoding Rules . . . . . . . . . . . . . . . . 49
H.1. COOKIE request, IFF response, GQ response, MV response . 48 Appendix I. COOKIE request, IFF response, GQ response, MV
H.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 48 response . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Appendix J. Certificates . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
A distributed network service requires reliable, ubiquitous and A distributed network service requires reliable, ubiquitous and
survivable provisions to prevent accidental or malicious attacks on survivable provisions to prevent accidental or malicious attacks on
the servers and clients in the network or the values they exchange. the servers and clients in the network or the values they exchange.
Reliability requires that clients can determine that received packets Reliability requires that clients can determine that received packets
are authentic; that is, were actually sent by the intended server and are authentic; that is, were actually sent by the intended server and
not manufactured or modified by an intruder. Ubiquity requires that not manufactured or modified by an intruder. Ubiquity requires that
a client can verify the authenticity of a server using only public a client can verify the authenticity of a server using only public
skipping to change at page 4, line 25 skipping to change at page 4, line 25
implementations, improper operation and possibly malicious clogging implementations, improper operation and possibly malicious clogging
and replay attacks. and replay attacks.
This memo describes a cryptographically sound and efficient This memo describes a cryptographically sound and efficient
methodology for use in the Network Time Protocol (NTP) methodology for use in the Network Time Protocol (NTP)
[I-D.ietf-ntp-ntpv4-proto]. The various key agreement schemes [I-D.ietf-ntp-ntpv4-proto]. The various key agreement schemes
[RFC2408][RFC2412][RFC2522] proposed require per-association state [RFC2408][RFC2412][RFC2522] proposed require per-association state
variables, which contradicts the principles of the remote procedure variables, which contradicts the principles of the remote procedure
call (RPC) paradigm in which servers keep no state for a possibly call (RPC) paradigm in which servers keep no state for a possibly
large client population. An evaluation of the PKI model and large client population. An evaluation of the PKI model and
algorithms as implemented in the OpenSSL library leads to the algorithms, e.g., as implemented in the OpenSSL library, leads to the
conclusion that any scheme requiring every NTP packet to carry a PKI conclusion that any scheme requiring every NTP packet to carry a PKI
digital signature would result in unacceptably poor timekeeping digital signature would result in unacceptably poor timekeeping
performance. performance.
The Autokey protocol is based on a combination of PKI and a pseudo- The Autokey protocol is based on a combination of PKI and a pseudo-
random sequence generated by repeated hashes of a cryptographic value random sequence generated by repeated hashes of a cryptographic value
involving both public and private components. This scheme has been involving both public and private components. This scheme has been
implemented, tested and deployed in the Internet of today. A implemented, tested and deployed in the Internet of today. A
detailed description of the security model, design principles and detailed description of the security model, design principles and
implementation is presented in this memo. implementation is presented in this memo.
skipping to change at page 5, line 33 skipping to change at page 5, line 33
client is synchronized to proventic sources" means that the system client is synchronized to proventic sources" means that the system
clock has been set using the time values of one or more proventic clock has been set using the time values of one or more proventic
associations and according to the NTP mitigation algorithms. associations and according to the NTP mitigation algorithms.
Over the last several years the IETF has defined and evolved the Over the last several years the IETF has defined and evolved the
IPSEC infrastructure for privacy protection and source authentication IPSEC infrastructure for privacy protection and source authentication
in the Internet. The infrastructure includes the Encapsulating in the Internet. The infrastructure includes the Encapsulating
Security Payload (ESP) [RFC2406] and Authentication Header (AH) Security Payload (ESP) [RFC2406] and Authentication Header (AH)
[RFC2402] for IPv4 and IPv6. Cryptographic algorithms that use these [RFC2402] for IPv4 and IPv6. Cryptographic algorithms that use these
headers for various purposes include those developed for the PKI, headers for various purposes include those developed for the PKI,
including MD5 message digests, RSA digital signatures and several including various message digest, digital signature and key agreement
variations of Diffie-Hellman key agreements. The fundamental algorithms. This memo takes no position on which message digest or
assumption in the security model is that packets transmitted over the which digital signature algorithm is used. This is established by a
Internet can be intercepted by other than the intended recipient, profile for each community of users.
remanufactured in various ways and replayed in whole or part. These
packets can cause the client to believe or produce incorrect It will facilitate the discussion in this memo to refer to the
information, cause protocol operations to fail, interrupt network reference implementation available at http://www.ntp.org. It
service or consume precious network and processor resources. includes Autokey as described in this memo and is available to the
general public; however, it is not part of the specification itself.
The cryptographic means used by the reference implementation and its
user community are based on the OpenSSL cryptographic software
library available at http://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.
The fundamental assumption in NTP 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 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 false time values, disrupt the protocol or clog the network, servers
or clients with spurious packets that exhaust resources and deny or clients with spurious packets that exhaust resources and deny
service to legitimate applications. The mission of the algorithms service to legitimate applications. The mission of the algorithms
and protocols described in this memo is to detect and discard and protocols described in this memo is to detect and discard
spurious packets sent by other than the intended sender or sent by spurious packets sent by other than the intended sender or sent by
the intended sender, but modified or replayed by an intruder. The the intended sender, but modified or replayed by an intruder.
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 There are a number of defense mechanisms already built in the NTP
architecture, protocol and algorithms. The on-wire timestamp architecture, protocol and algorithms. The on-wire timestamp
exchange scheme is inherently resistant to spoofing, packet loss and exchange scheme is inherently resistant to spoofing, packet loss and
replay attacks. The engineered clock filter, selection and replay attacks. The engineered clock filter, selection and
clustering algorithms are designed to defend against evil cliques of clustering algorithms are designed to defend against evil cliques of
Byzantine traitors. While not necessarily designed to defeat Byzantine traitors. While not necessarily designed to defeat
determined intruders, these algorithms and accompanying sanity checks determined intruders, these algorithms and accompanying sanity checks
have functioned well over the years to deflect improperly operating have functioned well over the years to deflect improperly operating
but presumably friendly scenarios. However, these mechanisms do not but presumably friendly scenarios. However, these mechanisms do not
skipping to change at page 6, line 32 skipping to change at page 6, line 42
net. net.
2. An intruder can generate packets faster than the server, network 2. An intruder can generate packets faster than the server, network
or client can process them, especially if they require expensive or client can process them, especially if they require expensive
cryptographic computations. cryptographic computations.
3. In a wiretap attack the intruder can intercept, modify and replay 3. In a wiretap attack the intruder can intercept, modify and replay
a packet. However, it cannot permanently prevent onward a packet. However, it cannot permanently prevent onward
transmission of the original packet; that is, it cannot break the transmission of the original packet; that is, it cannot break the
wire, only tell lies and congest it. Except in unlikely cases wire, only tell lies and congest it. Except in unlikely cases
considered in Section 11.6, the modified packet cannot arrive at considered in Section 28, the modified packet cannot arrive at
the victim before the original packet, nor does it have the the victim before the original packet, nor does it have the
server private keys or identity parameters. server private keys or identity parameters.
4. In a middleman or masquerade attack the intruder is positioned 4. In a middleman or masquerade attack the intruder is positioned
between the server and client, so it can intercept, modify and between the server and client, so it can intercept, modify and
replay a packet and prevent onward transmission of the original replay a packet and prevent onward transmission of the original
packet. Except in unlikely cases considered in Section 11.6, the packet. Except in unlikely cases considered in Section 28, the
middleman does not have the server private keys. middleman does not have the server private keys.
The NTP security model assumes the following possible limitations. The NTP security model assumes the following possible limitations.
1. The running times for public key algorithms are relatively long 1. The running times for public key algorithms are relatively long
and highly variable. In general, the performance of the time and highly variable. In general, the performance of the time
synchronization function is badly degraded if these algorithms synchronization function is badly degraded if these algorithms
must be used for every NTP packet. must be used for every NTP packet.
2. In some modes of operation it is not feasible for a server to 2. In some modes of operation it is not feasible for a server to
skipping to change at page 7, line 34 skipping to change at page 7, line 45
can be different for each interface. This allows a firewall, for can be different for each interface. This allows a firewall, for
instance, to require some interfaces to authenticate the client and instance, to require some interfaces to authenticate the client and
others not. others not.
3. Approach 3. Approach
The Autokey protocol described in this memo is designed to meet the The Autokey protocol described in this memo is designed to meet the
following objectives. In-depth discussions on these objectives is in following objectives. In-depth discussions on these objectives is in
the web briefings and will not be elaborated in this memo. Note that the web briefings and will not be elaborated in this memo. Note that
here and elsewhere in this memo mention of broadcast mode means here and elsewhere in this memo mention of broadcast mode means
multicast mode as well, with exceptions as noted in the NTPv4 multicast mode as well, with exceptions as noted in the NTP software
specification [I-D.ietf-ntp-ntpv4-proto]. documentation.
1. It must interoperate with the existing NTP architecture model and 1. It must interoperate with the existing NTP architecture model and
protocol design. In particular, it must support the symmetric protocol design. In particular, it must support the symmetric
key scheme described in [I-D.ietf-ntp-ntpv4-proto]. As a key scheme described in [RFC1305].
practical matter, the reference implementation must use the same
internal key management system, including the use of 32-bit key
IDs and existing mechanisms to store, activate and revoke keys.
2. It must provide for the independent collection of cryptographic 2. It must provide for the independent collection of cryptographic
values and time values. A NTP packet is accepted for processing values and time values. A NTP packet is accepted for processing
only when the required cryptographic values have been obtained only when the required cryptographic values have been obtained
and verified and the packet has passed all header sanity checks. and verified and the packet has passed all header sanity checks.
3. It must not significantly degrade the potential accuracy of the 3. It must not significantly degrade the potential accuracy of the
NTP synchronization algorithms. In particular, it must not make NTP synchronization algorithms. In particular, it must not make
unreasonable demands on the network or host processor and memory unreasonable demands on the network or host processor and memory
resources. resources.
skipping to change at page 8, line 31 skipping to change at page 8, line 39
Autokey cryptography is based on the PKI algorithms commonly used in Autokey cryptography is based on the PKI algorithms commonly used in
the Secure Shell and Secure Sockets Layer applications. As in these the Secure Shell and Secure Sockets Layer applications. As in these
applications Autokey uses message digests to detect packet applications Autokey uses message digests to detect packet
modification, digital signatures to verify credentials and public modification, digital signatures to verify credentials and public
certificates to provide traceable authority. What makes Autokey certificates to provide traceable authority. What makes Autokey
cryptography unique is the way in which these algorithms are used to cryptography unique is the way in which these algorithms are used to
deflect intruder attacks while maintaining the integrity and accuracy deflect intruder attacks while maintaining the integrity and accuracy
of the time synchronization function. of the time synchronization function.
NTPv3 and NTPv4 symmetric key cryptography uses keyed-MD5 message Autokey, like many other remote procedure call (RPC) protocols,
digests with a 128-bit private key and 32-bit key ID. In order to depends on message digests for basic authentication; however, it is
retain backward compatibility with NTPv3, the NTPv4 key ID space is important to understand that message digests are also used by NTP
when Autokey is not available or not configured. Selection of the
digest algorithm is a function of NTP configuration and is
transparent to Autokey.
The protocol design supports both 128-bit and 160-bit message digest
algorithms, each with a 32-bit key ID. The message digest algorthm
is a property of NTPv4 and is not specified in this memo. In order
to retain backward compatibility with NTPv3, the key ID space is
partitioned in two subspaces at a pivot point of 65536. Symmetric partitioned in two subspaces at a pivot point of 65536. Symmetric
key IDs have values less than the pivot and indefinite lifetime. key IDs have values less than the pivot and indefinite lifetime.
Autokey key IDs have pseudo-random values equal to or greater than Autokey key IDs have pseudo-random values equal to or greater than
the pivot and are expunged immediately after use. the pivot and are expunged immediately after use.
Both symmetric key and public key cryptography authenticate as shown Both symmetric key and public key cryptography authenticate as shown
in Figure 1. The server looks up the key associated with the key ID in Figure 1. The server looks up the key associated with the key ID
and calculates the message digest from the NTP header and extension and calculates the message digest from the NTP header and extension
fields together with the key value. The key ID and digest form the fields together with the key value. The key ID and digest form the
message authentication code (MAC) included with the message. The message authentication code (MAC) included with the message. The
client does the same computation using its local copy of the key and 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, compares the result with the digest in the MAC. If the values agree,
skipping to change at page 9, line 35 skipping to change at page 9, line 47
association, so there may be several autokey sequences operating association, so there may be several autokey sequences operating
independently at the same time. independently at the same time.
+-------------+-------------+--------+--------+ +-------------+-------------+--------+--------+
| Src Address | Dst Address | Key ID | Cookie | | Src Address | Dst Address | Key ID | Cookie |
+-------------+-------------+--------+--------+ +-------------+-------------+--------+--------+
Figure 2: NTPv4 Autokey Figure 2: NTPv4 Autokey
An autokey is computed from four fields in network byte order as An autokey is computed from four fields in network byte order as
shown in Figure 2. The four values are hashed by the MD5 message shown in Figure 2. The four values are hashed using the MD5
digest algorithm to produce the 128-bit autokey value, which in the algorithm to produce the 128-bit autokey value. For use with IPv4
reference implementation is stored along with the key ID in a cache the Src Address and Dst Address fields contain 32 bits; for use with
used for symmetric keys as well as autokeys. Keys are retrieved from IPv6 these fields contain 128 bits. In either case the Key ID and
the cache by key ID using hash tables and a fast lookup algorithm. 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
For use with IPv4 the Src Address and Dst Address fields contain 32 destination addresses and key ID are public values visible in the
bits; for use with IPv6 these fields contain 128 bits. In either packet, while the cookie can be a public value or shared private
case the Key ID and Cookie fields contain 32 bits. Thus, an IPv4 value, depending on the NTP mode.
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 shared private value, depending on the NTP mode.
The NTP packet format has been augmented to include one or more The NTP packet format has been augmented to include one or more
extension fields piggybacked between the original NTP header and the extension fields piggybacked between the original NTP header and the
MAC. For packets without extension fields, the cookie is a shared MAC. For packets without extension fields, the cookie is a shared
private value. For packets with extension fields, the cookie has a private value. For packets with extension fields, the cookie has a
default public value of zero, since these packets are validated default public value of zero, since these packets are validated
independently using digital signatures. independently using digital signatures.
There are some scenarios where the use of endpoint IP addresses may There are some scenarios where the use of endpoint IP addresses may
be difficult or impossible. These include configurations where be difficult or impossible. These include configurations where
skipping to change at page 10, line 51 skipping to change at page 11, line 11
The first 32 bits of the result in network byte order become the next The first 32 bits of the result in network byte order become the next
key ID. The MD5 hash of the autokey is the key value saved in the key ID. The MD5 hash of the autokey is the key value saved in the
key cache along with the key ID. The first 32 bits of the key become key cache along with the key ID. The first 32 bits of the key become
the key ID for the next autokey assigned index 1. the key ID for the next autokey assigned index 1.
Operations continue to generate the entire list. It may happen that Operations continue to generate the entire list. It may happen that
a newly generated key ID is less than the pivot or collides with a newly generated key ID is less than the pivot or collides with
another one already generated (birthday event). When this happens, another one already generated (birthday event). When this happens,
which occurs only rarely, the key list is terminated at that point. 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 The lifetime of each key is set to expire one poll interval after its
scheduled use. In the reference implementation, the list is scheduled use. The list is terminated when the maximum key lifetime
terminated when the maximum key lifetime is about one hour, so for is about one hour, so for poll intervals above one hour a new key
poll intervals above one hour a new key list containing only a single list containing only a single entry is regenerated for every poll.
entry is regenerated for every poll.
+------------------+ +------------------+
| NTP Header and | | NTP Header and |
| Extension Fields | | Extension Fields |
+------------------+ +------------------+
| | | |
\|/ \|/ +---------+ \|/ \|/ +---------+
**************** +--------+ | Session | **************** +--------+ | Session |
* COMPUTE HASH *<---| Key ID |<---| Key ID | * COMPUTE HASH *<---| Key ID |<---| Key ID |
**************** +--------+ | List | **************** +--------+ | List |
skipping to change at page 11, line 36 skipping to change at page 11, line 43
ID for that entry, collectively called the autokey values. The ID for that entry, collectively called the autokey values. The
autokey values are then signed for use later. The list is used in autokey values are then signed for use later. The list is used in
reverse order as shown in Figure 4, so that the first autokey used is reverse order as shown in Figure 4, so that the first autokey used is
the last one generated. the last one generated.
The Autokey protocol includes a message to retrieve the autokey The Autokey protocol includes a message to retrieve the autokey
values and verify the signature, so that subsequent packets can be values and verify the signature, so that subsequent packets can be
validated using one or more hashes that eventually match the last key validated using one or more hashes that eventually match the last key
ID (valid) or exceed the index (invalid). This is called the autokey ID (valid) or exceed the index (invalid). This is called the autokey
test in the following and is done for every packet, including those test in the following and is done for every packet, including those
with and without extension fields. In the reference implementation with and without extension fields. The most recent key ID received
the most recent key ID received is saved for comparison with the is saved for comparison with the first 32 bits in network byte order
first 32 bits in network byte order of the next following key value. of the next following key value. This minimizes the number of hash
This minimizes the number of hash operations in case a single packet operations in case a single packet is lost.
is lost.
5. NTP Secure Groups 5. NTP Secure Groups
NTP secure groups are used to define cryptographic compartments and NTP secure groups are used to define cryptographic compartments and
security hierarchies. A secure group consists of a number of hosts security hierarchies. A secure group consists of a number of hosts
dynamically assembled as a forest with roots the trusted hosts (THs) dynamically assembled as a forest with roots the trusted hosts (THs)
at the lowest stratum of the group. The THs do not have to be, but at the lowest stratum of the group. The THs do not have to be, but
often are, primary (stratum 1) servers. A trusted authority (TA), often are, primary (stratum 1) servers. A trusted authority (TA),
not necessarily a group host, generates private identity keys for not necessarily a group host, generates private identity keys for
servers and public identity keys for clients at the leaves of the servers and public identity keys for clients at the leaves of the
forest. The TA deploys the server keys to the THs and other forest. The TA deploys the server keys to the THs and other
designated servers using secure means and delivers the client keys by designated servers using secure means and posts the client keys on a
secure means. public web site.
For Autokey purposes all hosts belonging to a secure group have the For Autokey purposes all hosts belonging to a secure group have the
same group name but different host names, not necessarily related to same group name but different host names, not necessarily related to
the DNS names. The group name is used in the subject and issuer the DNS names. The group name is used in the subject and issuer
fields of the TH certificates; the host name is used in these fields fields of the TH certificates; the host name is used in these fields
for other hosts. Thus, all host certificates are self-signed. for other hosts. Thus, all host certificates are self-signed.
During the Autokey protocol a client requests the server to sign its During the Autokey protocol a client requests the server to sign its
certificate and caches the result. A certificate trail is certificate and caches the result. A certificate trail is
constructed by each host, possibly via intermediate hosts and ending constructed by each host, possibly via intermediate hosts and ending
at a TH. Thus, each host along the trail retrieves the entire trail at a TH. Thus, each host along the trail retrieves the entire trail
from its server(s) and provides this plus its own signed certificates from its server(s) and provides this plus its own signed certificates
to its clients. to its clients.
Secure groups can be configured as hierarchies where a TH of one Secure groups can be configured as hierarchies where a TH of one
group can be a client of one or more other groups operating at a group can be a client of one or more other groups operating at a
lower stratum. In one scenario, groups RED and GREEN can be lower stratum. In one scenario, THs for groups RED and GREEN can be
cryptographically distinct, but both be clients of group BLUE cryptographically distinct, but both be clients of group BLUE
operating at a lower stratum. In another scenario, group CYAN can be operating at a lower stratum. In another scenario, THs for group
a client of multiple groups YELLOW and MAGENTA, both operating at a CYAN can be clients of multiple groups YELLOW and MAGENTA, both
lower stratum. There are many other scenarios, but all must be operating at a lower stratum. There are many other scenarios, but
configured to include only acyclic certificate trails. all must be configured to include only acyclic certificate trails.
In Figure 5, the Alice group consists of THs Alice, which is also the In Figure 5, the Alice group consists of THs Alice, which is also the
TA, and Carol. Dependent servers Brenda and Denise have configured TA, and Carol. Dependent servers Brenda and Denise have configured
Alice and Carol, respectively, as their time sources. Stratum 3 Alice and Carol, respectively, as their time sources. Stratum 3
server Eileen has configured both Brenda and Denise as her time server Eileen has configured both Brenda and Denise as her time
sources. Public certificates are identified by the subject and sources. Public certificates are identified by the subject and
signed by the issuer. Note that the server keys have been previously signed by the issuer. Note that the server group keys have been
installed on Brenda and Denise and the client keys installed on all previously installed on Brenda and Denise and the client group keys
machines. installed on all machines.
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| Alice | | Brenda | | Denise | | Alice Group | | Brenda | | Denise |
| | | | | | | Alice | | | | |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
Certificate | | Alice | | | | Brenda| | | | Denise| | Certificate | | Alice | | | | Brenda| | | | Denise| |
+-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | +-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| Subject | | | Alice*| 1 | | | Alice | 4 | | | Carol | 4 | | Subject | | | Alice*| 1 | | | Alice | 4 | | | Carol | 4 |
+-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | +-+-+-+-+-+ | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| Issuer | S | | | | | | | Issuer | S | | | | | |
+-+-+-+-+-+ | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ | +-+-+-+-+-+ | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ |
| ||Alice|| 3 | | | Alice | | | | Carol | | | ||Alice|| 3 | | | Alice | | | | Carol | |
Group Key | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ | Group Key | +=======+ | | +-+-+-+-+ | | +-+-+-+-+ |
+=========+ +-------------+ | | Alice*| 2 | | | Carol*| 2 | +=========+ +-------------+ | | Alice*| 2 | | | Carol*| 2 |
|| Group || S | Carol | | +-+-+-+-+ | | +-+-+-+-+ | || Group || S | Alice Group | | +-+-+-+-+ | | +-+-+-+-+ |
+=========+ | | | | | | +=========+ | Carol | | | | |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
S = step | | Carol | | | | Brenda| | | | Denise| | S = step | | Carol | | | | Brenda| | | | Denise| |
* = trusted | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | * = trusted | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| | Carol*| 1 | | | Brenda| 1 | | | Denise| 1 | | | Carol*| 1 | | | Brenda| 1 | | | Denise| 1 |
| +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ | | +-+-+-+-+ |
| | | | | | | | | | | |
| +=======+ | | +=======+ | | +=======+ | | +=======+ | | +=======+ | | +=======+ |
| ||Alice|| 3 | | ||Alice|| 3 | | ||Alice|| 3 | | ||Alice|| 3 | | ||Alice|| 3 | | ||Alice|| 3 |
| +=======+ | | +=======+ | | +=======+ | | +=======+ | | +=======+ | | +=======+ |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
Stratum 1 Stratum 2 Stratum 1 Stratum 2
+---------------------------------------------+ +---------------------------------------------+
| Eileen | | Eileen |
| | | |
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
| | Eileen| | Eileen| | | | Eileen| | Eileen| |
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
| | Brenda| | Carol | 4 | | | Brenda| 4 | Carol | 4 |
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
| | | |
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
| | Alice | | Carol | | | | Alice | | Carol | |
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
| | Alice*| | Carol*| 2 | | | Alice*| 2 | Carol*| 2 |
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
| | | |
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
| | Brenda| | Denise| | | | Brenda| | Denise| |
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
| | Alice | | Carol | 2 | | | Alice | 2 | Carol | 2 |
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
| | | |
| +-+-+-+-+ | | +-+-+-+-+ |
| | Eileen| | | | Eileen| |
| +-+-+-+-+ | | +-+-+-+-+ |
| | Eileen| 1 | | | Eileen| 1 |
| +-+-+-+-+ | | +-+-+-+-+ |
| | | |
| +=======+ | | +=======+ |
| ||Alice|| 3 | | ||Alice|| 3 |
skipping to change at page 14, line 4 skipping to change at page 14, line 9
| | Eileen| 1 | | | Eileen| 1 |
| +-+-+-+-+ | | +-+-+-+-+ |
| | | |
| +=======+ | | +=======+ |
| ||Alice|| 3 | | ||Alice|| 3 |
| +=======+ | | +=======+ |
+---------------------------------------------+ +---------------------------------------------+
Stratum 3 Stratum 3
Figure 5: NTP Secure Groups Figure 5: NTP Secure Groups
The steps in hiking the certificate trails and verifying identity are The steps in hiking the certificate trails and verifying identity are
as follows. Note the step number in the description matches the step as follows. Note the step number in the description matches the step
number in the figure. number in the figure.
1. The servers start by loading the host key, sign key, self-signed 1. The girls start by loading the host key, sign key, self-signed
certificate and group key. They start the Autokey protocol by certificate and group key. Each client and server acting as a
exchanging host names and negotiating digest/signature schemes client They starts the Autokey protocol by retrieving the server
and identity schemes. host name and digest/signature. This is done using the ASSOC
exchange described later.
2. They continue to load certificates recursively until a self- 2. They continue to load certificates recursively until a self-
signed trusted certificate is found. Brenda and Denise signed trusted certificate is found. Brenda and Denise
immediately find trusted certificates for Alice and Carol, immediately find trusted certificates for Alice and Carol,
respectively, but Eileen will loop because neither Brenda nor respectively, but Eileen will loop because neither Brenda nor
Denise have their own certificates signed by either Alice or Denise have their own certificates signed by either Alice or
Carol. Carol. This is done using the CERT exchange described later.
3. Brenda and Denise continue with the selected identity schemes to 3. Brenda and Denise continue with the selected identity schemes to
verify that Alice and Carol have the correct group key previously verify that Alice and Carol have the correct group key previously
generated by Alice. If this succeeds, each continues in step 4. generated by Alice. This is done using one of the identity
schemes IFF, GQ or MV described later. If this succeeds, each
continues in step 4.
4. Brenda and Denise present their certificates for signature. If 4. Brenda and Denise present their certificates for signature using
this succeeds, either or both Brenda and Denise can now provide the SIGN exchange described later. If this succeeds, either or
these signed certificates to Eileen, which may be looping in step both Brenda and Denise can now provide these signed certificates
2. Eileen can now verify the trail via either Brenda or Denise to Eileen, which may be looping in step 2. Eileen can now verify
to the trusted certificates for Alice and Carol. Once this is the trail via either Brenda or Denise to the trusted certificates
done, Eileen can complete the protocol just as Brenda and Denise. for Alice and Carol. Once this is done, Eileen can complete the
protocol just as Brenda and Denise.
For various reasons it may be convenient for a server to have client For various reasons it may be convenient for a server to have client
keys for more than one group. For example, Figure 6 shows three keys for more than one group. For example, Figure 6 shows three
secure groups Alice, Helen and Carol arranged in a hierarchy. Hosts secure groups Alice, Helen and Carol arranged in a hierarchy. Hosts
A, B, C and D belong to Alice, R, S to Helen and X, Y and Z belong to A, B, C and D belong to Alice with A and B her THs. Hosts R and S
Carol. While not strictly necessary, hosts A, B and R are stratum 1 belong to Helen with R her TH. Hosts X and Y belong to Carol withi X
and presumed trusted, but the TA generating the identity keys could her TH. Note that the TH for a group is always the lowest stratum
be one of them or another not shown. and that the hosts of the combined groups form an acyclic graph.
Note also that the certificate trail for each group terminates on a
TH for that group.
***** ***** @@@@@ ***** ***** @@@@@
Stratum 1 * A * * B * @ R @ Stratum 1 * A * * B * @ R @
***** ***** @@@@@ ***** ***** @@@@@
\ / / \ / /
\ / / \ / /
***** @@@@@ ********* ***** @@@@@ *********
2 * C * @ S @ * Alice * 2 * C * @ S @ * Alice *
***** @@@@@ ********* ***** @@@@@ *********
/ \ / / \ /
skipping to change at page 16, line 11 skipping to change at page 16, line 11
stop on the trail must be an intrinsic capability of Autokey itself. stop on the trail must be an intrinsic capability of Autokey itself.
While the identity scheme described in [RFC2875] is based on a While the identity scheme described in [RFC2875] is based on a
ubiquitous Diffie-Hellman infrastructure, it is expensive to generate ubiquitous Diffie-Hellman infrastructure, it is expensive to generate
and use when compared to others described in Appendix B. In and use when compared to others described in Appendix B. In
principle, an ordinary public key scheme could be devised for this principle, an ordinary public key scheme could be devised for this
purpose, but the most stringent Autokey design requires that every purpose, but the most stringent Autokey design requires that every
challenge, even if duplicated, results in a different acceptable challenge, even if duplicated, results in a different acceptable
response. response.
There are five schemes now implemented in the NTPv4 reference 1. The scheme must have a relatively long lifetime, certainly longer
implementation to prove identity: (1) private certificate (PC), (2) than a typical certificate, and have no specific lifetime or
trusted certificate (TC), (3) a modified Schnorr algorithm (IFF aka expiration date. At the time the scheme is used the host has not
Identify Friendly or Foe), (4) a modified Guillou-Quisquater yet synchronized to a proventic source, so the scheme cannot
algorithm (GQ), and (5) a modified Mu-Varadharajan algorithm (MV). depend time..
Following is a summary description of each; details are given in
Appendix B. 2. As the scheme can be used many times where the data might be
exposed to potential intruders, the data must be either nonces or
encrypted nonces.
3. The scheme should allow designated servers to prove identity to
designated clients, but not allow clients acting as servers to
prove identity to dependent clients.
4. To the geatest extent possible, the scheme should represent a
zero-knowledge proof; that is, the client should be able to
verify the server has the correct group key, but without knowing
the key itself.
There are five schemes proposed 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). Not all of these provide the same level of
protection and one, TC, provides no protection but is included for
comparison. Which of these is is to be used must be specified in a
profile for this specification. Following is a brief summary
description of each; details are given in Appendix B.
The PC scheme involves a private certificate as group key. The The PC scheme involves a private certificate as group key. The
certificate is distributed to all other group members by secure means certificate is distributed to all other group members by secure means
and is never revealed outside the group. In effect, the private and is never revealed outside the group. In effect, the private
certificate is used as a symmetric key. This scheme is used certificate is used as a symmetric key. This scheme is used
primarily for testing and development and is not recommended for primarily for testing and development and is not recommended for
regular use and is not considered further in this memo. regular use and is not considered further in this memo.
All other schemes involve a conventional certificate trail as All other schemes involve a conventional certificate trail as
described in RFC 2510 [RFC2510]. This is the default scheme when an described in [RFC5280]. This is the default scheme when an identity
identity scheme is not specified. While the remaining identity scheme is not required. While the remaining identity schemes
schemes incorporate TC, it is not by itself considered further in incorporate TC, it is not by itself considered further in this memo.
this memo.
The three remaining schemes IFF, GQ and MV involve a The three remaining schemes IFF, GQ and MV involve a
cryptographically strong challenge-response exchange where an cryptographically strong challenge-response exchange where an
intruder cannot deduce the server key, even after repeated intruder cannot deduce the server key, even after repeated
observations of multiple exchanges. In addition, the MV scheme is observations of multiple exchanges. In addition, the MV scheme is
properly described as a zero-knowledge proof, because the client can properly described as a zero-knowledge proof, because the client can
verify the server has the correct group key without either the server verify the server has the correct group key without either the server
or client knowing its value. These schemes start when the client or client knowing its value. These schemes start when the client
sends a nonce to the server, which then rolls its own nonce, performs sends a nonce to the server, which then rolls its own nonce, performs
a mathematical operation and sends the results to the client. The a mathematical operation and sends the results to the client. The
skipping to change at page 17, line 6 skipping to change at page 17, line 26
7. Timestamps and Filestamps 7. Timestamps and Filestamps
While public key signatures provide strong protection against While public key signatures provide strong protection against
misrepresentation of source, computing them is expensive. This misrepresentation of source, computing them is expensive. This
invites the opportunity for an intruder to clog the client or server invites the opportunity for an intruder to clog the client or server
by replaying old messages or originating bogus messages. A client by replaying old messages or originating bogus messages. A client
receiving such messages might be forced to verify what turns out to receiving such messages might be forced to verify what turns out to
be an invalid signature and consume significant processor resources. be an invalid signature and consume significant processor resources.
In order to foil such attacks, every Autokey message carries a In order to foil such attacks, every Autokey message carries a
timestamp in the form of the NTP seconds when it was created. If the timestamp in the form of the NTP seconds when it was. If the system
system clock is synchronized to a proventic source, a signature is clock is synchronized to a proventic source, a signature is produced
produced with valid (nonzero) timestamp. Otherwise, there is no with valid (nonzero) timestamp. Otherwise, there is no signature and
signature and the timestamp is invalid (zero). The protocol detects the timestamp is invalid (zero). The protocol detects and discards
and discards extension fields with old or duplicate timestamps, extension fields with old or duplicate timestamps, before any values
before any values are used or signatures are verified. are used or signatures are verified.
Signatures are computed only when cryptographic values are created or Signatures are computed only when cryptographic values are created or
modified, which is by design not very often. Extension fields modified, which is by design not very often. Extension fields
carrying these signatures are copied to messages as needed, but the carrying these signatures are copied to messages as needed, but the
signatures are not recomputed. There are three signature types: signatures are not recomputed. There are three signature types:
1. Cookie signature/timestamp. The cookie is signed when created by 1. Cookie signature/timestamp. The cookie is signed when created by
the server and sent to the client. the server and sent to the client.
2. Autokey signature/timestamp. The autokey values are signed when 2. Autokey signature/timestamp. The autokey values are signed when
skipping to change at page 18, line 49 skipping to change at page 19, line 24
described below. described below.
o Identity exchange. The certificate trail is generally not o Identity exchange. The certificate trail is generally not
considered sufficient protection against middleman attacks unless considered sufficient protection against middleman attacks unless
additional protection such as the proof-of-possession scheme additional protection such as the proof-of-possession scheme
described in [RFC2875] is available, but this is expensive and described in [RFC2875] is available, but this is expensive and
requires servers to retain state. Autokey can use one of the requires servers to retain state. Autokey can use one of the
challenge/response identity schemes described in Appendix B. challenge/response identity schemes described in Appendix B.
Completion of this exchange lights the IFF bit as described below. Completion of this exchange lights the IFF bit as described below.
o Cookie exchange. The request includes the public key of the o Cookie exchange. The request includes the public key of the. The
server. The response includes the server cookie encrypted with response includes the server cookie encrypted with this key. The
this key. The client uses this value when constructing the key client uses this value when constructing the key list. Completion
list. Completion of this exchange lights the COOK bit as of this exchange lights the COOK bit as described below.
described below.
o Autokey exchange. The request includes either no data or the o Autokey exchange. The request includes either no data or the
autokey values in symmetric modes. The response includes the autokey values in symmetric modes. The response includes the
autokey values of the server. These values are used to verify the autokey values of the server. These values are used to verify the
autokey sequence. Completion of this exchange lights the AUT bit autokey sequence. Completion of this exchange lights the AUT bit
as described below. as described below.
o Sign exchange. This exchange is executed only when the client has o Sign exchange. This exchange is executed only when the client has
synchronized to a proventic source. The request includes the synchronized to a proventic source. The request includes the
self-signed client certificate. The server acting as CA self-signed client certificate. The server acting as CA
interprets the certificate as a X.509v3 certificate request. It interprets the certificate as a X.509v3 certificate request. It
extracts the subject, issuer, and extension fields, builds a new extracts the subject, issuer, and extension fields, builds a new
certificate with these data along with its own serial number and certificate with these data along with its own serial number and
expiration time, then signs it using its own private key and expiration time, then signs it using its own public key and
includes it in the response. The client uses the signed includes it in the response. The client uses the signed
certificate in its own role as server for dependent clients. certificate in its own role as server for dependent clients.
Completion of this exchange lights the SIGN bit as described Completion of this exchange lights the SIGN bit as described
below. below.
o Leapseconds exchange. This exchange is executed only when the o Leapseconds exchange. This exchange is executed only when the
client has synchronized to a proventic source. This exchange client has synchronized to a proventic source. This exchange
occurs when the server has the leapseconds values, as indicated in occurs when the server has the leapseconds values, as indicated in
the host status word. If so, the client requests the values and the host status word. If so, the client requests the values and
compares them with its own values, if available. If the server compares them with its own values, if available. If the server
skipping to change at page 21, line 47 skipping to change at page 22, line 20
The Autokey protocol data unit is the extension field, one or more of The Autokey protocol data unit is the extension field, one or more of
which can be piggybacked in the NTP packet. An extension field which can be piggybacked in the NTP packet. An extension field
contains either a request with optional data or a response with contains either a request with optional data or a response with
optional data. To avoid deadlocks, any number of responses can be optional data. To avoid deadlocks, any number of responses can be
included in a packet, but only one request. A response is generated included in a packet, but only one request. A response is generated
for every request, even if the requestor is not synchronized to a for every request, even if the requestor is not synchronized to a
proventic source, but most contain meaningful data only if the proventic source, but most contain meaningful data only if the
responder is synchronized to a proventic source. Some requests and responder is synchronized to a proventic source. Some requests and
most responses carry timestamped signatures. The signature covers most responses carry timestamped signatures. The signature covers
the entire extension field, including the timestamp and filestamp, the entire extension field, including the timestamp and filestamp,
where applicable. Only if the packet passes all extension field where applicable. Only if the packet has correct format, length and
tests are cycles spent to verify the signature. message digest are cycles spent to verify the signature.
The following terms: light, lit, etc. means the bit value is set to
1, while the terms dark, dim, etc. indicate that the bit value is set
to 0.
There are currently eight Autokey requests and eight corresponding There are currently eight Autokey requests and eight corresponding
responses. The NTP packet format is described in responses. The NTP packet format is described in
[I-D.ietf-ntp-ntpv4-proto] and the extension field format used for [I-D.ietf-ntp-ntpv4-proto] and the extension field format used for
these messages is illustrated in Figure 7. these messages is illustrated in Figure 7.
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E| Code | Field Type | Length | |R|E| Code | Field Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 42 skipping to change at page 23, line 35
/ Signature \ / Signature \
\ / \ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ / \ /
/ Padding (if needed) \ / Padding (if needed) \
\ / \ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: NTPv4 Extension Field Format Figure 7: NTPv4 Extension Field Format
Each extension field is zero-padded to a 4-octet boundary. The The Value and Signature fields are zero-padded to a 4-octet boundary.
Length field covers the entire extension field, including the Length The Length field covers the entire extension field including the
and Padding fields. While the minimum field length is 8 octets, a padding fields. While the minimum field length is 8 octets, a
maximum field length remains to be established. The reference maximum field length remains to be established.
implementation discards any packet with a field length more than 1024
octets.
The extension field parser initializes a pointer to the first octet One or more extension fields follow the NTP packet header and the
beyond the NTP header fields and calculates the number of octets last followed by the MAC. The extension field parser initializes a
remaining in the packet. If this value is 20 the remaining data is pointer to the first octet beyond the NTP packet header and
the MAC and parsing is complete. If greater than 20 an extension calculates the number of octets remaining to the end of the packet.
field is present. If the length is less than 4 or not a multiple of If this value is 20 (128-bit digest plus 4-octet key ID) or 22 (160-
4, a format error has occurred and the packet is discarded; bit digest plus 4-octet key ID), the remaining data are the MAC and
otherwise, the parser increments the pointer by the length and then parsing is complete. If greater than 22 an extension field is
present. If the length is less than 8 or not a multiple of 4, a
format error has occurred and the packet is discarded; otherwise, the
parser increments the pointer by the extension field length and then
uses the same rules as above to determine whether a MAC is present or uses the same rules as above to determine whether a MAC is present or
another extension field. another extension field.
In Autokey the 8-bit Field Type field is interpreted as the version In Autokey the 8-bit Field Type field is interpreted as the version
number, currently 2. For future versions values 1-7 have been number, currently 2. For future versions values 1-7 have been
reserved for Autokey; other values may be assigned for other reserved for Autokey; other values may be assigned for other
applications. The 6-bit Code field specifies the request or response applications. The 6-bit Code field specifies the request or response
operation. There are two flag bits: bit 0 is the Response Flag (R) operation. There are two flag bits: bit 0 is the Response Flag (R)
and bit 1 is the Error Flag (E); the Reserved field is unused and and bit 1 is the Error Flag (E); the Reserved field is unused and
should be set to 0. The remaining fields will be described later. 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 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 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 the R bit and E bit dim. The server returns a response with the same
value previously received from the server or 0 otherwise. The server operation code in the Code field and lights the R bit. The server
returns a response with the same operation code in the Code field and can also light the E bit in case of error. Note that it is not
lights the R bit. The server can also light the E bit in case of necessarily a protocol error to send an unsolicited response with no
error. The Association ID field is set to the association ID of the matching request. If the R bit is dim, the client sets the
server as a handle for subsequent exchanges. If for some reason the Association ID field to the client association ID which the servert
association ID value in a request does not match the association ID returns for verification. If the two values do not match, the
of any mobilized association, the server returns the request with response is discarded as if never sent. If the R bit is lit, the
both the R and E bits lit. Note that it is not necessarily a Association ID field is set the the server association ID obtained in
protocol error to send an unsolicited response with no matching the initial protocol exchange. If the Association ID field does not
request. match any mobilized association ID, the request is discarded as if
never sent.
In some cases not all fields may be present. For requests, until a In some cases not all fields may be present. For requests, until a
client has synchronized to a proventic source, signatures are not client has synchronized to a proventic source, signatures are not
valid. In such cases the Timestamp and Signature Length fields are 0 valid. In such cases the Timestamp and Signature Length fields are
and the Signature field is empty. Some request and error response zero and the Signature field is absent. Some request and error
messages carry no value or signature fields, so in these messages response messages carry no value or signature fields, so in these
only the first two words are present. messages only the first two words (8 octests) are present.
The Timestamp and Filestamp words carry the seconds field of an NTP The Timestamp and Filestamp words carry the seconds field of an NTP
timestamp. The timestamp establishes the signature epoch of the data timestamp. The timestamp establishes the signature epoch of the data
field in the message, while the filestamp establishes the generation field in the message, while the filestamp establishes the generation
epoch of the file that ultimately produced the data that is signed. epoch of the file that ultimately produced the data that is signed.
A signature and timestamp are valid only when the signing host is A signature and timestamp are valid only when the signing host is
synchronized to a proventic source; otherwise, the timestamp is zero. synchronized to a proventic source; otherwise, the timestamp is zero.
A cryptographic data file can only be generated if a signature is A cryptographic data file can only be generated if a signature is
possible; otherwise, the filestamp is zero, except in the ASSOC possible; otherwise, the filestamp is zero, except in the ASSOC
response message, where it contains the server status word. response message, where it contains the server status word.
As in all other TIP/IP protocol designs, all data are sent in network As in all other TCP/IP protocol designs, all data are sent in network
byte order. Unless specified otherwise in the descriptions to byte order. Unless specified otherwise in the descriptions to
follow, the data referred to are stored in the Value field. follow, the data referred to are stored in the Value field.
10.1. No-Operation 11. No-Operation
A No-operation request (Field Type 0) does nothing except return an A No-operation request (Code 0) does nothing except return an empty
empty response which can be used as a crypto-ping. response which can be used as a crypto-ping.
10.2. Association Message (ASSOC) 12. Association Message (ASSOC)
An Association Message (Field Type 1) is used in the parameter An Association Message (Code 1) is used in the parameter exchange to
exchange to obtain the host name and status word. The request obtain the host name and status word. The request contains the
contains the client status word in the Filestamp field and the client status word in the Filestamp field and the Autokey host name
Autokey host name in the Value field. The response contains the in the Value field. The response contains the server status word in
server status word in the Filestamp field and the Autokey host name the Filestamp field and the Autokey host name in the Value field.
in the Value field. The Autokey host name is not necessarily the DNS The Autokey host name is not necessarily the DNS host name. A valid
host name. A valid response lights the ENAB bit and possibly others response lights the ENAB bit and possibly others in the association
in the association status word. status word.
When multiple identity schemes are supported, the host status word When multiple identity schemes are supported, the host status word
determine which ones are available. In server and symmetric modes determine which ones are available. In server and symmetric modes
the response status word contains bits corresponding to the supported the response status word contains bits corresponding to the supported
schemes. In all modes the scheme is selected based on the client schemes. In all modes the scheme is selected based on the client
identity parameters which are loaded at startup. identity parameters which are loaded at startup.
10.3. Certificate Message (CERT) 13. Certificate Message (CERT)
A Certificate Message (Field Type 2) is used in the certificate A Certificate Message (Code 2) is used in the certificate exchange to
exchange to obtain a certificate by subject name. The request obtain a certificate by subject name. The request contains the
contains the subject name; the response contains the certificate subject name; the response contains the certificate encoded in X.509
encoded in X.509 format with ASN.1 syntax as described in Appendix H. format with ASN.1 syntax as described in Appendix H.
If the subject name in the response does not match the issuer name, If the subject name in the response does not match the issuer name,
the exchange continues with the issuer name replacing the subject the exchange continues with the issuer name replacing the subject
name in the request. The exchange continues until a trusted, self- name in the request. The exchange continues until a trusted, self-
signed certificate is found and lights the CERT bit in the signed certificate is found and lights the CERT bit in the
association status word. association status word.
10.4. Cookie Message (COOKIE) 14. Cookie Message (COOKIE)
The Cookie Message (Field Type 3) is used in server and symmetric The Cookie Message (Code 3) is used in server and symmetric modes to
modes to obtain the server cookie. The request contains the host obtain the server cookie. The request contains the host public key
public key encoded with ASN.1 syntax as described in Appendix H. The encoded with ASN.1 syntax as described in Appendix H. The response
response contains the cookie encrypted by the public key in the contains the cookie encrypted by the public key in the request. A
request. A valid response lights the COOKIE bit in the association valid response lights the COOKIE bit in the association status word.
status word.
10.5. Autokey Message (AUTO) 15. Autokey Message (AUTO)
The Autokey Message (Field Type 4) is used to obtain the autokey The Autokey Message (Code 4) is used to obtain the autokey values.
values. The request contains no value for a client or the autokey The request contains no value for a client or the autokey values for
values for a symmetric peer. The response contains two 32-bit words, a symmetric peer. The response contains two 32-bit words, the first
the first is the final key ID, while the second is the index of the is the final key ID, while the second is the index of the final key
final key ID. A valid response lights the AUTO bit in the ID. A valid response lights the AUTO bit in the association status
association status word. word.
10.6. Leapseconds Values Message (LEAP) 16. Leapseconds Values Message (LEAP)
The Leapseconds Values Message (Field Type 5) is used to obtain the The Leapseconds Values Message (Cpde 5) is used to obtain the
leapseconds values as parsed from the leapseconds table from NIST. leapseconds values as parsed from the leapseconds table from NIST.
The request contains no values. The response contains three 32-bit The request contains no values. The response contains three 32-bit
integers: first the NTP seconds of the latest leap event followed by integers: first the NTP seconds of the latest leap event followed by
the NTP seconds when the latest NIST table expires and then the TAI the NTP seconds when the latest NIST table expires and then the TAI
offset following the leap event. A valid response lights the LEAP offset following the leap event. A valid response lights the LEAP
bit in the association status word. bit in the association status word.
10.7. Sign Message (SIGN) 17. Sign Message (SIGN)
The Sign Message (Field Type 6) requests the server to sign and The Sign Message (Code 6) requests the server to sign and return a
return a certificate presented in the request. The request contains certificate presented in the request. The request contains the
the client certificate encoded in X.509 format with ASN.1 syntax as client certificate encoded in X.509 format with ASN.1 syntax as
described in Appendix H. The response contains the client described in Appendix H. The response contains the client
certificate signed by the server private key. A valid response certificate signed by the server private key. A valid response
lights the SIGN bit in the association status word. lights the SIGN bit in the association status word.
10.8. Identity Messages (IFF, GQ, MV) 18. Identity Messages (IFF, GQ, MV)
The Identity Messages (Field Type 7 (IFF), 8 (GQ), or 9 (MV)) The Identity Messages (Code 7 (IFF), 8 (GQ), or 9 (MV)) contains the
contains the client challenge, usually a 160- or 512-bit nonce. The client challenge, usually a 160- or 512-bit nonce. The response
response contains the result of the mathematical operation defined in contains the result of the mathematical operation defined in
Appendix B. The Response is encoded in ASN.1 syntax as described in Appendix B. The Response is encoded in ASN.1 syntax as described in
Appendix H. A valid response lights the VRFY bit in the association Appendix H. A valid response lights the VRFY bit in the association
status word. status word.
11. Autokey State Machine 19. Autokey State Machine
This section describes the formal model of the Autokey state machine, This section describes the formal model of the Autokey state machine,
its state variables and the state transition functions. its state variables and the state transition functions.
11.1. Status Word 20. Status Word
The server implements a host status word, while each client The server implements a host status word, while each client
implements an association status word. These words have the format implements an association status word. These words have the format
and content shown in Figure 8. The low order 16 bits of the status and content shown in Figure 8. The low order 16 bits of the status
word define the state of the Autokey dance, while the high order 16 word define the state of the Autokey dance, while the high order 16
bits specify the message digest/signature encryption scheme as bits specify the OID for one of the message digest/signature
encoded in the OpenSSL library. Bits 24-31 are reserved for server encryption schemes defined in [RFC3279]. Bits 24-31 are reserved for
use, while bits 16-23 are reserved for client use. In the host server use, while bits 16-23 are reserved for client use. In the
portion bits 24-27 specify the available identity schemes, while bits host portion bits 24-27 specify the available identity schemes, while
28-31 specify the server capabilities. There are two additional bits bits 28-31 specify the server capabilities. There are two additional
implemented separately. bits implemented separately.
1 2 3 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 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 | | Digest / Signature NID | Client | Ident | Host |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Status Word Figure 8: Status Word
The host status word is included in the ASSOC request and response The host status word is included in the ASSOC request and response
skipping to change at page 26, line 36 skipping to change at page 27, line 36
The host status bits are defined as follows: The host status bits are defined as follows:
o ENAB (31) Lit if the server implements the Autokey protocol. o ENAB (31) Lit if the server implements the Autokey protocol.
o LVAL (30) Lit if the server has installed leapseconds values, o LVAL (30) Lit if the server has installed leapseconds values,
either from the NIST leapseconds file or from another server. either from the NIST leapseconds file or from another server.
o Bits (28-29) are reserved - always dark. o Bits (28-29) are reserved - always dark.
o Bits 24-27 select which server identity schemes are available. o Bits 24-27 select which server identity schemes are available.
While specific coding for various schemes is yet to be determined, While specific coding for various schemes is yet to be determined
the schemes available in the reference implementation and by profile, the schemes described in Appendix B include the
described in Appendix B include the following: following:
* none - Trusted Certificate (TC) Scheme (default). * none - Trusted Certificate (TC) Scheme (default).
* PC (27) Private Certificate Scheme. * PC (27) Private Certificate Scheme.
* IFF (26) Schnorr aka Identify-Friendly-or-Foe Scheme. * IFF (26) Schnorr aka Identify-Friendly-or-Foe Scheme.
* GQ (25) Guillard-Quisquater Scheme. * GQ (25) Guillard-Quisquater Scheme.
* MV (24) Mu-Varadharajan Scheme. * MV (24) Mu-Varadharajan Scheme.
skipping to change at page 27, line 39 skipping to change at page 28, line 39
o SIGN (18) Lit when the host certificate is signed by the server. o SIGN (18) Lit when the host certificate is signed by the server.
o LEAP (17) Lit when the leapseconds values are received and o LEAP (17) Lit when the leapseconds values are received and
validated. validated.
o Bit 16 is reserved - always dark. o Bit 16 is reserved - always dark.
There are three additional bits: LIST, SYNC and PEER not included in There are three additional bits: LIST, SYNC and PEER not included in
the association status word. LIST is lit when the key list is the association status word. LIST is lit when the key list is
regenerated and dim when the autokey values have been transmitted. regenerated and dim when the autokey values have been transmitted.
This is necessary to avoid resource starvation (livelock) under some This is necessary to avoid livelock under some conditions. SYNC is
conditions. SYNC is lit when the client has synchronized to a lit when the client has synchronized to a proventic source and never
proventic source and never dim after that. PEER is lit when the dim after that. PEER is lit when the server has synchronized, as
server has synchronized, as indicated in the NTP header, and never indicated in the NTP header, and never dim after that.
dim after that.
11.2. Host State Variables 21. Host State Variables
Following is a list of host state variables. Following is a list of host state variables.
Host Name - The name of the host, by default the string returned by Host Name - The name of the host, by default the string returned by
the Unix gethostname() library function. In the reference the Unix gethostname() library function.
implementation this is a configurable value.
Host Status Word - This word is initialized when the host first Host Status Word - This word is initialized when the host first
starts up. The format is described above. starts up. The format is described above.
Host Key - The RSA public/private key pair used to encrypt/decrypt Host Key - The RSA public/private key pair used to encrypt/decrypt
cookies. This is also the default sign key. cookies. This is also the default sign key.
Sign Key - The RSA or DSA public/private key pair used to encrypt/ Sign Key - The RSA or DSA public/private key pair used to encrypt/
decrypt signatures when the host key is not used for this purpose. decrypt signatures when the host key is not used for this purpose.
skipping to change at page 29, line 42 skipping to change at page 30, line 41
Host Name Values. This is used to send ASSOC request and response Host Name Values. This is used to send ASSOC request and response
messages. It contains the host status word and host name. messages. It contains the host status word and host name.
Public Key Values - This is used to send the COOKIE request message. Public Key Values - This is used to send the COOKIE request message.
It contains the public encryption key used for the COOKIE response It contains the public encryption key used for the COOKIE response
message. message.
Leapseconds Values. This is used to send the LEAP response message. Leapseconds Values. This is used to send the LEAP response message.
In contains the leapseconds values in the LEAP message description. In contains the leapseconds values in the LEAP message description.
11.3. Client State Variables (all modes) 22. Client State Variables (all modes)
Following is a list of state variables used by the various dances in Following is a list of state variables used by the various dances in
all modes. all modes.
Association ID - The association ID used in responses. It is Association ID - The association ID used in responses. It is
assigned when the association is mobilized. assigned when the association is mobilized.
Association Status Word - The status word copied from the ASSOC Association Status Word - The status word copied from the ASSOC
response; subsequently modified by the state machine. response; subsequently modified by the state machine.
skipping to change at page 30, line 37 skipping to change at page 31, line 37
Send Autokey Values - The autokey values with signature and Send Autokey Values - The autokey values with signature and
timestamps. timestamps.
Key List - A sequence of key IDs starting with the autokey seed and Key List - A sequence of key IDs starting with the autokey seed and
each pointing to the next. It is computed, timestamped and signed at each pointing to the next. It is computed, timestamped and signed at
the next poll opportunity when the key list becomes empty. the next poll opportunity when the key list becomes empty.
Current Key Number - The index of the entry on the Key List to be Current Key Number - The index of the entry on the Key List to be
used at the next poll opportunity. used at the next poll opportunity.
11.4. Protocol State Transitions 23. Protocol State Transitions
The protocol state machine is very simple but robust. The state is The protocol state machine is very simple but robust. The state is
determined by the client status word bits defined above. The state determined by the client status word bits defined above. The state
transitions of the three dances are shown below. The capitalized transitions of the three dances are shown below. The capitalized
truth values represent the client status bits. All bits are truth values represent the client status bits. All bits are
initialized dark and are lit upon the arrival of a specific response initialized dark and are lit upon the arrival of a specific response
message as detailed above. message as detailed above.
11.4.1. Server Dance 24. Server Dance
The server dance begins when the client sends an ASSOC request to the The server dance begins when the client sends an ASSOC request to the
server. The clock is updated when PREV is lit and the dance ends server. The clock is updated when PREV is lit and the dance ends
when LEAP is lit. In this dance the autokey values are not used, so when LEAP is lit. In this dance the autokey values are not used, so
an autokey exchange is not necessary. Note that the SIGN and LEAP an autokey exchange is not necessary. Note that the SIGN and LEAP
requests are not issued until the client has synchronized to a requests are not issued until the client has synchronized to a
proventic source. Subsequent packets without extension fields are proventic source. Subsequent packets without extension fields are
validated by the autokey sequence. The following example and others validated by the autokey sequence. This example and others assumes
assume the IFF identity scheme has been selected in the parameter the IFF identity scheme has been selected in the parameter exchange..
exchange..
1 while (1) { 1 while (1) {
2 wait_for_next_poll; 2 wait_for_next_poll;
3 make_NTP_header; 3 make_NTP_header;
4 if (response_ready) 4 if (response_ready)
5 send_response; 5 send_response;
6 if (!ENB) /* parameter exchange */ 6 if (!ENB) /* parameter exchange */
7 ASSOC_request; 7 ASSOC_request;
8 else if (!CERT) /* certificate exchange */ 8 else if (!CERT) /* certificate exchange */
9 CERT_request(Host_Name); 9 CERT_request(Host_Name);
10 else if (!IFF) /* identity exchange */ 10 else if (!IFF) /* identity exchange */
11 IFF_challenge; 11 IFF_challenge;
12 else if (!COOK) /* cookie exchange */ 12 else if (!COOK) /* cookie exchange */
13 COOKIE_request; 13 COOKIE_request;
14 else if (!SYNC) /* synchronization wait */ 14 else if (!SYNC) /* wait for synchronization */
15 continue; 15 continue;
16 else if (!SIGN) /* sign exchange */ 16 else if (!SIGN) /* sign exchange */
17 SIGN_request(Host_Certificate); 17 SIGN_request(Host_Certificate);
18 else if (!LEAP) /* leap sec value exchange */ 18 else if (!LEAP) /* leapsecond values exchange */
19 LEAP_request; 19 LEAP_request;
20 send packet; 20 send packet;
21 } 21 }
Figure 9: Server Dance Figure 9: Server Dance
If the server refreshes the private seed, the cookie becomes invalid. If the server refreshes the private seed, the cookie becomes invalid.
The server responds to an invalid cookie with a crypto_NAK message, The server responds to an invalid cookie with a crypto_NAK message,
which causes the client to restart the protocol from the beginning. which causes the client to restart the protocol from the beginning.
11.4.2. Broadcast Dance 25. Broadcast Dance
The broadcast dance is similar to the server dance with the cookie The broadcast dance is similar to the server dance with the cookie
exchange replaced by the autokey values exchange. The broadcast exchange replaced by the autokey values exchange. The broadcast
dance begins when the client receives a broadcast packet including an dance begins when the client receives a broadcast packet including an
ASSOC response with the server association ID. This mobilizes a ASSOC response with the server association ID. This mobilizes a
client association in order to proventicate the source and calibrate client association in order to proventicate the source and calibrate
the propagation delay. The dance ends when the LEAP bit is lit, the propagation delay. The dance ends when the LEAP bit is lit,
after which the client sends no further packets. Normally, the after which the client sends no further packets. Normally, the
broadcast server includes an ASSOC response in each transmitted broadcast server includes an ASSOC response in each transmitted
packet. However, when the server generates a new key list, it packet. However, when the server generates a new key list, it
skipping to change at page 32, line 24 skipping to change at page 33, line 26
4 if (response_ready) 4 if (response_ready)
5 send_response; 5 send_response;
6 if (!ENB) /* parameters exchange */ 6 if (!ENB) /* parameters exchange */
7 ASSOC_request; 7 ASSOC_request;
8 else if (!CERT) /* certificate exchange */ 8 else if (!CERT) /* certificate exchange */
9 CERT_request(Host_Name); 9 CERT_request(Host_Name);
10 else if (!IFF) /* identity exchange */ 10 else if (!IFF) /* identity exchange */
11 IFF_challenge; 11 IFF_challenge;
12 else if (!AUT) /* autokey values exchange */ 12 else if (!AUT) /* autokey values exchange */
13 AUTO_request; 13 AUTO_request;
14 else if (!SYNC) /* synchronization wait */ 14 else if (!SYNC) /* wait for synchronization */
15 continue; 15 continue;
16 else if (!SIGN) /* sign exchange */ 16 else if (!SIGN) /* sign exchange */
17 SIGN_request(Host_Certificate); 17 SIGN_request(Host_Certificate);
18 else if (!LEAP) /* leap sec value exchange */ 18 else if (!LEAP) /* leapsecond values exchange */
19 LEAP_request; 19 LEAP_request;
20 send NTP_packet; 20 send NTP_packet;
21 } 21 }
Figure 10: Server Dance Figure 10: Server Dance
If a packet is lost and the autokey sequence is broken, the client If a packet is lost and the autokey sequence is broken, the client
hashes the current autokey until either it matches the previous hashes the current autokey until either it matches the previous
autokey or the number of hashes exceeds the count given in the autokey or the number of hashes exceeds the count given in the
autokey values. If the latter, the client sends an AUTO request to autokey values. If the latter, the client sends an AUTO request to
retrieve the autokey values. If the client receives a crypto-NAK retrieve the autokey values. If the client receives a crypto-NAK
during the dance, or if the association ID changes, the client during the dance, or if the association ID changes, the client
restarts the protocol from the beginning. restarts the protocol from the beginning.
11.4.3. Symmetric Dance 26. Symmetric Dance
The symmetric dance is intricately choreographed. It begins when the The symmetric dance is intricately choreographed. It begins when the
active peer sends an ASSOC request to the passive peer. The passive active peer sends an ASSOC request to the passive peer. The passive
peer mobilizes an association and both peers step a three-way dance peer mobilizes an association and both peers step a three-way dance
where each peer completes a parameter exchange with the other. Until where each peer completes a parameter exchange with the other. Until
one of the peers has synchronized to a proventic source (which could one of the peers has synchronized to a proventic source (which could
be the other peer) and can sign messages, the other peer loops be the other peer) and can sign messages, the other peer loops
waiting for a valid timestamp in the ensuing CERT response. waiting for a valid timestamp in the ensuing CERT response.
1 while (1) { 1 while (1) {
skipping to change at page 33, line 20 skipping to change at page 34, line 22
6 else if (!CERT) /* certificate exchange */ 6 else if (!CERT) /* certificate exchange */
7 CERT_request(Host_Name); 7 CERT_request(Host_Name);
8 else if (!IFF) /* identity exchange */ 8 else if (!IFF) /* identity exchange */
9 IFF_challenge; 9 IFF_challenge;
10 else if (!COOK && PEER) /* cookie exchange */ 10 else if (!COOK && PEER) /* cookie exchange */
11 COOKIE_request); 11 COOKIE_request);
12 else if (!AUTO) /* autokey values exchange */ 12 else if (!AUTO) /* autokey values exchange */
13 AUTO_request; 13 AUTO_request;
14 else if (LIST) /* autokey values response */ 14 else if (LIST) /* autokey values response */
15 AUTO_response; 15 AUTO_response;
16 else if (!SYNC) /* synchronization wait */ 16 else if (!SYNC) /* wait for synchronization */
17 continue; 17 continue;
18 else if (!SIGN) /* sign exchange */ 18 else if (!SIGN) /* sign exchange */
19 SIGN_request; 19 SIGN_request;
20 else if (!LEAP) /* leap sec value exchange */ 20 else if (!LEAP) /* leapsecond values exchange */
21 LEAP_request; 21 LEAP_request;
22 send NTP_packet; 22 send NTP_packet;
23 } 23 }
Figure 11: Symmetric Dance Figure 11: Symmetric Dance
Once a peer has synchronized to a proventic source, it includes Once a peer has synchronized to a proventic source, it includes
timestamped signatures in its messages. The other peer, which has timestamped signatures in its messages. The other peer, which has
been stalled waiting for valid timestamps, now mates the dance. It been stalled waiting for valid timestamps, now mates the dance. It
retrives the now nonzero cookie using a cookie exchange and then the retrives the now nonzero cookie using a cookie exchange and then the
updated autokey values using an autokey exchange. updated autokey values using an autokey exchange.
As in the broadcast dance, if a packet is lost and the autokey As in the broadcast dance, if a packet is lost and the autokey
sequence broken, the peer hashes the current autokey until either it sequence broken, the peer hashes the current autokey until either it
matches the previous autokey or the number of hashes exceeds the matches the previous autokey or the number of hashes exceeds the
count given in the autokey values. If the latter, the client sends count given in the autokey values. If the latter, the client sends
an AUTO request to retrive the autokey values. If the peer receives an AUTO request to retrive the autokey values. If the peer receives
a crypto-NAK during the dance, or if the association ID changes, the a crypto-NAK during the dance, or if the association ID changes, the
peer restarts the protocol from the beginning. peer restarts the protocol from the beginning.
11.5. Error Recovery 27. Error Recovery
The Autokey protocol state machine includes provisions for various The Autokey protocol state machine includes provisions for various
kinds of error conditions that can arise due to missing files, kinds of error conditions that can arise due to missing files,
corrupted data, protocol violations and packet loss or misorder, not corrupted data, protocol violations and packet loss or misorder, not
to mention hostile intrusion. This section describes how the to mention hostile intrusion. This section describes how the
protocol responds to reachability and timeout events which can occur protocol responds to reachability and timeout events which can occur
due to such errors. due to such errors.
A persistent NTP association is mobilized by an entry in the A persistent NTP association is mobilized by an entry in the
configuration file, while an ephemeral association is mobilized upon configuration file, while an ephemeral association is mobilized upon
skipping to change at page 34, line 47 skipping to change at page 35, line 51
is stepped or when the server seed is refreshed. is stepped or when the server seed is refreshed.
There are special cases designed to quickly respond to broken There are special cases designed to quickly respond to broken
associations, such as when a server restarts or refreshes keys. associations, such as when a server restarts or refreshes keys.
Since the client cookie is invalidated, the server rejects the next Since the client cookie is invalidated, the server rejects the next
client request and returns a crypto-NAK packet. Since the crypto-NAK client request and returns a crypto-NAK packet. Since the crypto-NAK
has no MAC, the problem for the client is to determine whether it is has no MAC, the problem for the client is to determine whether it is
legitimate or the result of intruder mischief. In order to reduce legitimate or the result of intruder mischief. In order to reduce
the vulnerability in such cases, the crypto-NAK, as well as all the vulnerability in such cases, the crypto-NAK, as well as all
responses, is believed only if the result of a previous packet sent responses, is believed only if the result of a previous packet sent
by the client is not a replay, as confirmed by the NTP on-wire by the client and not a replay, as confirmed by the NTP on-wire
protocol. While this defense can be easily circumvented by a protocol. While this defense can be easily circumvented by a
middleman, it does deflect other kinds of intruder warfare. middleman, it does deflect other kinds of intruder warfare.
There are a number of situations where some event happens that causes There are a number of situations where some event happens that causes
the remaining autokeys on the key list to become invalid. When one the remaining autokeys on the key list to become invalid. When one
of these situations happens, the key list and associated autokeys in of these situations happens, the key list and associated autokeys in
the key cache are purged. A new key list, signature and timestamp the key cache are purged. A new key list, signature and timestamp
are generated when the next NTP message is sent, assuming there is are generated when the next NTP message is sent, assuming there is
one. Following is a list of these situations: one. Following is a list of these situations:
1. When the cookie value changes for any reason. 1. When the cookie value changes for any reason.
2. When the poll interval is changed. In this case the calculated 2. When the poll interval is changed. In this case the calculated
expiration times for the keys become invalid. expiration times for the keys become invalid.
3. If a problem is detected when an entry is fetched from the key 3. If a problem is detected when an entry is fetched from the key
list. This could happen if the key was marked non-trusted or list. This could happen if the key was marked non-trusted or
timed out, either of which implies a software bug. timed out, either of which implies a software bug.
11.6. Security Considerations 28. Security Considerations
This section discusses the most obvious security vulnerabilities in This section discusses the most obvious security vulnerabilities in
the various Autokey dances. In the following discussion the the various Autokey dances. In the following discussion the
cryptographic algorithms and private values themselves are assumed cryptographic algorithms and private values themselves are assumed
secure; that is, a brute force cryptanalytic attack will not reveal secure; that is, a brute force cryptanalytic attack will not reveal
the host private key, sign private key, cookie value, identity the host private key, sign private key, cookie value, identity
parameters, server seed or autokey seed. In addition, an intruder parameters, server seed or autokey seed. In addition, an intruder
will not be able to predict random generator values. will not be able to predict random generator values.
11.7. Protocol Vulnerability 29. Protocol Vulnerability
While the protocol has not been subjected to a formal analysis, a few While the protocol has not been subjected to a formal analysis, a few
preliminary assertions can be made. In the client/server and preliminary assertions can be made. In the client/server and
symmetric dances the underlying NTP on-wire protocol is resistant to symmetric dances the underlying NTP on-wire protocol is resistant to
lost, duplicate and bogus packets, even if the clock is not lost, duplicate and bogus packets, even if the clock is not
synchronized, so the protocol is not vulnerable to a wiretapper synchronized, so the protocol is not vulnerable to a wiretapper
attack. A middleman attack, even if it could simulate a valid attack. The on-wire protocol is resistant to replays of both the
cookie, could not present a valid signature. client request packet and the server reply packet. A middleman
attack, even if it could simulate a valid cookie, could not prove
identity.
In the broadcast dance the client begins with a volley in client/ In the broadcast dance the client begins with a volley in client/
server mode to obtain the autokey values and signature, so has the server mode to obtain the autokey values and signature, so has the
same protection as in that mode. When continuing in receive-only same protection as in that mode. When continuing in receive-only
mode, a wiretapper cannot produce a key list with valid signed mode, a wiretapper cannot produce a key list with valid signed
autokey values. If it replays an old packet, the client will reject autokey values. If it replays an old packet, the client will reject
it by the timestamp check. The most it can do is manufacture a it by the timestamp check. The most it can do is manufacture a
future packet causing clients to repeat the autokey hash operations future packet causing clients to repeat the autokey hash operations
until exceeding the maximum key number. If this happens the until exceeding the maximum key number. If this happens the
broadcast client temporarily reverts to client mode to refresh the broadcast client temporarily reverts to client mode to refresh the
autokey values. autokey values.
By assumption, a middleman attacker that intercepts a packet cannot
break the wire or delay an intercepted packet. If this assumption is
removed, the middleman could intercept a broadcast packet and replace
the data and message digest without detection by the clients.
As mentioned previously in this memo, the TC identity scheme is
vulnerable to a middleman attack where an intruder could create a
bogus certificate trail. To foil this kind of attack, either the PC,
IFF, GQ or MV identity schemes must be used.
A client instantiates cryptographic variables only if the server is A client instantiates cryptographic variables only if the server is
synchronized to a proventic source. A server does not sign values or synchronized to a proventic source. A server does not sign values or
generate cryptographic data files unless synchronized to a proventic generate cryptographic data files unless synchronized to a proventic
source. This raises an interesting issue: how does a client generate source. This raises an interesting issue: how does a client generate
proventic cryptographic files before it has ever been synchronized to proventic cryptographic files before it has ever been synchronized to
a proventic source? [Who shaves the barber if the barber shaves a proventic source? [Who shaves the barber if the barber shaves
everybody in town who does not shave himself?] In principle, this everybody in town who does not shave himself?] In principle, this
paradox is resolved by assuming the primary (stratum 1) servers are paradox is resolved by assuming the primary (stratum 1) servers are
proventicated by external phenomenological means. proventicated by external phenomenological means.
11.8. Clogging Vulnerability 30. Clogging Vulnerability
A self-induced clogging incident cannot happen, since signatures are A self-induced clogging incident cannot happen, since signatures are
computed only when the data have changed and the data do not change computed only when the data have changed and the data do not change
very often. For instance, the autokey values are signed only when very often. For instance, the autokey values are signed only when
the key list is regenerated, which happens about once an hour, while the key list is regenerated, which happens about once an hour, while
the public values are signed only when one of them is updated during the public values are signed only when one of them is updated during
a dance or the server seed is refreshed, which happens about once per a dance or the server seed is refreshed, which happens about once per
day. day.
There are two clogging vulnerabilities exposed in the protocol There are two clogging vulnerabilities exposed in the protocol
skipping to change at page 36, line 45 skipping to change at page 38, line 17
In broadcast mode a client a decryption hazard exists when a In broadcast mode a client a decryption hazard exists when a
wiretapper replays autokey response messages at speed. Once wiretapper replays autokey response messages at speed. Once
synchronized to a proventic source, a legitimate extension field with synchronized to a proventic source, a legitimate extension field with
timestamp the same as or earlier than the most recently received of timestamp the same as or earlier than the most recently received of
that type is immediately discarded. This foils a middleman cut-and- that type is immediately discarded. This foils a middleman cut-and-
paste attack using an earlier response, for example. A legitimate paste attack using an earlier response, for example. A legitimate
extension field with timestamp in the future is unlikely, as that extension field with timestamp in the future is unlikely, as that
would require predicting the autokey sequence. However, this causes would require predicting the autokey sequence. However, this causes
the client to refresh and verify the autokey values and signature. the client to refresh and verify the autokey values and signature.
A determined middleman can modify a recent packet with an intentional A determined attacker can destabilize the on-wire protocol or an
bit error. A stateless server will return a crypto-NAK message which Autokey dance in various ways by replaying old messages before the
will cause the client to perform a general reset. The middleman can client or peer has synchronized for the first time. For instance,
do other things as well and have nothing to do with Autokey. replaying an old symmetric mode message before the peers have
synchronize will prevent the peers from ever synchronizing.
Replaying out of order Autokey messages in any mode during a dance
could prevent the dance from ever completing. There is nothing new
in these kinds of attack; a similar vulnerabily even exists in TCP.
12. IANA Considerations 31. IANA Considerations
IANA is requested to add to the Extension Field Types associated with This document has no IANA Actions.
the NTP protocol (see [I-D.ietf-ntp-ntpv4-proto], section 16), the
values 1 through 7 for the Autokey PRotocol.
13. References 32. References
13.1. Normative References 32.1. Normative References
[I-D.ietf-ntp-ntpv4-proto] [I-D.ietf-ntp-ntpv4-proto]
Burbank, J., "Network Time Protocol Version 4 Protocol And Burbank, J., "Network Time Protocol Version 4 Protocol And
Algorithms Specification", draft-ietf-ntp-ntpv4-proto-11 Algorithms Specification", draft-ietf-ntp-ntpv4-proto-11
(work in progress), September 2008. (work in progress), September 2008.
13.2. Informative References 32.2. Informative References
[DASBUCH] Mills, D., "Compouter Network Time Synchronization - the [DASBUCH] Mills, D., "Computer Network Time Synchronization - the
Network Time Protocol", 2006. Network Time Protocol", 2006.
[GUILLOU] Guillou, L. and J. Quisquatar, "A "paradoxical" identity- [GUILLOU] Guillou, L. and J. Quisquatar, "A "paradoxical" identity-
based signature scheme resulting from zero-knowledge", based signature scheme resulting from zero-knowledge",
1990. 1990.
[MV] Mu, Y. and V. Varadharajan, "Robust and secure [MV] Mu, Y. and V. Varadharajan, "Robust and secure
broadcasting", 2001. broadcasting", 2001.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
skipping to change at page 38, line 16 skipping to change at page 39, line 36
Protocol", RFC 2522, March 1999. Protocol", RFC 2522, March 1999.
[RFC2875] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof- [RFC2875] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-
of-Possession Algorithms", RFC 2875, July 2000. of-Possession Algorithms", RFC 2875, July 2000.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002. (CRL) Profile", RFC 3279, April 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
X.509 Public Key Infrastructure Certificate and Housley, R., and W. Polk, "Internet X.509 Public Key
Certificate Revocation List (CRL) Profile", RFC 3280, Infrastructure Certificate and Certificate Revocation List
April 2002. (CRL) Profile", RFC 5280, May 2008.
[SCHNORR] Schnorr, C., "Efficient signature generation for smart [SCHNORR] Schnorr, C., "Efficient signature generation for smart
cards", 1991. cards", 1991.
[STINSON] Stinson, D., "Cryptography - Theory and Practice", 1995. [STINSON] Stinson, D., "Cryptography - Theory and Practice", 1995.
Appendix A. Timestamps, Filestamps and Partial Ordering Appendix A. Timestamps, Filestamps and Partial Ordering
When the host starts, it reads the host key and host certificate When the host starts, it reads the host key and host certificate
files, which are required for continued operation. It also reads the files, which are required for continued operation. It also reads the
skipping to change at page 39, line 41 skipping to change at page 41, line 12
not be used to verify signatures if t --> B or E --> t, where t not be used to verify signatures if t --> B or E --> t, where t
is the current proventic time. Note that the public key is the current proventic time. Note that the public key
previously extracted from the certificate continues to be valid previously extracted from the certificate continues to be valid
for an indefinite time. This raises the interesting possibility for an indefinite time. This raises the interesting possibility
where a truechimer server with expired certificate or a where a truechimer server with expired certificate or a
falseticker with valid certificate are not detected until the falseticker with valid certificate are not detected until the
client has synchronized to a proventic source. client has synchronized to a proventic source.
Appendix B. Identity Schemes Appendix B. Identity Schemes
There are five identity schemes in the NTPv4 reference There are five identity schemes to be selected by profile: (1)
implementation: (1) private certificate (PC), (2) trusted certificate private certificate (PC), (2) trusted certificate (TC), (3) a
(TC), (3) a modified Schnorr algorithm (IFF - Identify Friend or modified Schnorr algorithm (IFF - Identify Friend or Foe), (4) a
Foe), (4) a modified Guillou-Quisquater algorithm (GQ), and (5) a modified Guillou-Quisquater algorithm (GQ), and (5) a modified Mu-
modified Mu-Varadharajan algorithm (MV). Varadharajan algorithm (MV).
The PC scheme is intended for testing and development and not The PC scheme is intended for testing and development and not
recommended for general use. The TC scheme uses a certificate trail, recommended for general use. The TC scheme uses a certificate trail,
but not an identity scheme. The IFF, GQ and MV identity schemes use but not an identity scheme. The IFF, GQ and MV identity schemes use
a cryptographically strong challenge-response exchange where an a cryptographically strong challenge-response exchange where an
intruder cannot learn the group key, even after repeated observations intruder cannot learn the group key, even after repeated observations
of multiple exchanges. These schemes begin when the client sends a of multiple exchanges. These schemes begin when the client sends a
nonce to the server, which then rolls its own nonce, performs a nonce to the server, which then rolls its own nonce, performs a
mathematical operation and sends the results to the client. The mathematical operation and sends the results to the client. The
client performs a second mathematical operation to prove the server client performs a second mathematical operation to prove the server
skipping to change at page 47, line 43 skipping to change at page 49, line 24
prime) to Alice. prime) to Alice.
3. Alice computes the session decryption key E^-1 = (g-bar-prime)^x- 3. Alice computes the session decryption key E^-1 = (g-bar-prime)^x-
hat_j (g-hat-prime)^x-bar_j mod p and verifies that r = E^-1 x. hat_j (g-hat-prime)^x-bar_j mod p and verifies that r = E^-1 x.
Appendix H. ASN.1 Encoding Rules Appendix H. ASN.1 Encoding Rules
Certain value fields in request and response messages contain data Certain value fields in request and response messages contain data
encoded in ASN.1 distinguished encoding rules (DER). The BNF grammar encoded in ASN.1 distinguished encoding rules (DER). The BNF grammar
for each encoding rule is given below along with the OpenSSL routine for each encoding rule is given below along with the OpenSSL routine
used for the encoding in the reference implementation. The object used for the encoding. The object identifiers for the encryption
identifiers for the encryption algorithms and message digest/ algorithms and message digest/signature encryption schemes are
signature encryption schemes are specified in [RFC3279]. The specified in [RFC3279]. The particular algorithms required for
particular algorithms required for conformance are not specified in conformance are not specified in this memo.
this memo.
H.1. COOKIE request, IFF response, GQ response, MV response Appendix I. COOKIE request, IFF response, GQ response, MV response
The value field of the COOKIE request message contains a sequence of The value field of the COOKIE request message contains a sequence of
two integers (n, e) encoded by the i2d_RSAPublicKey() routine in the two integers (n, e) encoded by the i2d_RSAPublicKey() routine in the
OpenSSL distribution. In the request, n is the RSA modulus in bits OpenSSL distribution. In the request, n is the RSA modulus in bits
and e is the public exponent. and e is the public exponent.
RSAPublicKey ::= SEQUENCE { RSAPublicKey ::= SEQUENCE {
n ::= INTEGER, n ::= INTEGER,
e ::= INTEGER e ::= INTEGER
} }
skipping to change at page 48, line 38 skipping to change at page 50, line 15
encoded by the i2d_DSAparams() routine in the OpenSSL library. In encoded by the i2d_DSAparams() routine in the OpenSSL library. In
the response, p is the hash of the encrypted challenge value and (q, the response, p is the hash of the encrypted challenge value and (q,
g) is the client portion of the decryption key. g) is the client portion of the decryption key.
DSAparameters ::= SEQUENCE { DSAparameters ::= SEQUENCE {
p ::= INTEGER, p ::= INTEGER,
q ::= INTEGER, q ::= INTEGER,
g ::= INTEGER g ::= INTEGER
} }
H.2. Certificates Appendix J. Certificates
Certificate extension fields are used to convey information used by Certificate extension fields are used to convey information used by
the identity schemes. While the semantics of these fields generally the identity schemes. While the semantics of these fields generally
conforms with conventional usage, there are subtle variations. The conforms with conventional usage, there are subtle variations. The
fields used by Autokey Version 2 include: fields used by Autokey Version 2 include:
o Basic Constraints. This field defines the basic functions of the o Basic Constraints. This field defines the basic functions of the
certificate. It contains the string "critical,CA:TRUE", which certificate. It contains the string "critical,CA:TRUE", which
means the field must be interpreted and the associated private key means the field must be interpreted and the associated private key
can be used to sign other certificates. While included for can be used to sign other certificates. While included for
skipping to change at page 49, line 22 skipping to change at page 50, line 48
the certificate is designated private or the string "trustRoot" if the certificate is designated private or the string "trustRoot" if
it is designated trusted. A private certificate is always it is designated trusted. A private certificate is always
trusted. trusted.
o Subject Key Identifier. This field contains the client identity o Subject Key Identifier. This field contains the client identity
key used in the GQ identity scheme. It is present only if the GQ key used in the GQ identity scheme. It is present only if the GQ
scheme is in use. scheme is in use.
The value field contains a X509v3 certificate encoded by the The value field contains a X509v3 certificate encoded by the
i2d_X509() routine in the OpenSSL distribution. The encoding follows i2d_X509() routine in the OpenSSL distribution. The encoding follows
the rules stated in [RFC3280], including the use of X509v3 extension the rules stated in [RFC5280], including the use of X509v3 extension
fields. fields.
Certificate ::= SEQUENCE { Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate, tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier, signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING signatureValue BIT STRING
} }
The signatureAlgorithm is the object identifier of the message The signatureAlgorithm is the object identifier of the message
digest/signature encryption scheme used to sign the certificate. The digest/signature encryption scheme used to sign the certificate. The
skipping to change at page 49, line 44 skipping to change at page 51, line 24
algorithm and the issuer private key. algorithm and the issuer private key.
TBSCertificate ::= SEQUENCE { TBSCertificate ::= SEQUENCE {
version EXPLICIT v3(2), version EXPLICIT v3(2),
serialNumber CertificateSerialNumber, serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier, signature AlgorithmIdentifier,
issuer Name, issuer Name,
validity Validity, validity Validity,
subject Name, subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo, subjectPublicKeyInfo SubjectPublicKeyInfo,
extensions EXPLICIT Extensions OPTIONAL extensions EXPLICIT Extensions (OPTIONAL)
} }
The serialNumber is an integer guaranteed to be unique for the The serialNumber is an integer guaranteed to be unique for the
generating host. The reference implementation uses the NTP seconds generating host. The signature is the object identifier of the
when the certificate was generated. The signature is the object message digest/signature encryption scheme used to sign the
identifier of the message digest/signature encryption scheme used to certificate. It must be identical to the signatureAlgorithm.
sign the certificate. It must be identical to the
signatureAlgorithm.
CertificateSerialNumber ::= INTEGER CertificateSerialNumber
SET { ::= INTEGER
Validity ::= SEQUENCE { Validity ::= SEQUENCE {
notBefore UTCTime, notBefore UTCTime,
notAfter UTCTime notAfter UTCTime
} }
}
The notBefore and notAfter define the period of validity as defined The notBefore and notAfter define the period of validity as defined
in Appendix B. in Appendix B.
SubjectPublicKeyInfo ::= SEQUENCE { SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier, algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING subjectPublicKey BIT STRING
} }
The AlgorithmIdentifier specifies the encryption algorithm for the The AlgorithmIdentifier specifies the encryption algorithm for the
subject public key. The subjectPublicKey is the public key of the subject public key. The subjectPublicKey is the public key of the
subject. subject.
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE { Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER, extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE, critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING extnValue OCTET STRING
} }
SET {
Name ::= SEQUENCE { Name ::= SEQUENCE {
OBJECT IDENTIFIER commonName OBJECT IDENTIFIER commonName
PrintableString HostName PrintableString HostName
} }
}
For trusted host certificates the subject and issuer HostName is the For trusted host certificates the subject and issuer HostName is the
NTP name of the group, while for all other host certificates the NTP name of the group, while for all other host certificates the
subject and issuer HostName is the NTP name of the host. In the subject and issuer HostName is the NTP name of the host. If these
reference implementation if these names are not explicitly specified, names are not explicitly specified, they default to the string
they default to the string returned by the Unix gethostname() routine returned by the Unix gethostname() routine (trailing NUL removed).
(trailing NUL removed). For other than self-signed certificates, the For other than self-signed certificates, the issuer HostName is the
issuer HostName is the unique DNS name of the host signing the unique DNS name of the host signing the certificate.
certificate.
Authors' Addresses Authors' Addresses
Brian Haberman (editor) Brian Haberman (editor)
The Johns Hopkins University Applied Physics Laboratory The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road 11100 Johns Hopkins Road
Laurel, MD 20723-6099 Laurel, MD 20723-6099
US US
Phone: +1 443 778 1319 Phone: +1 443 778 1319
 End of changes. 106 change blocks. 
306 lines changed or deleted 362 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/