draft-ietf-ntp-autokey-03.txt   draft-ietf-ntp-autokey-04.txt 
Network Working Group B. Haberman, Ed. Network Working Group B. Haberman, Ed.
Internet-Draft JHU/APL Internet-Draft JHU/APL
Obsoletes: RFC 1305 D. Mills Intended status: Informational D. Mills
(if approved) U. Delaware Expires: February 19, 2009 U. Delaware
Intended status: Informational June 9, 2008 August 18, 2008
Expires: December 11, 2008
Network Time Protocol Version 4 Autokey Specification Network Time Protocol Version 4 Autokey Specification
draft-ietf-ntp-autokey-03 draft-ietf-ntp-autokey-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 36 skipping to change at page 1, line 35
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 December 11, 2008. This Internet-Draft will expire on February 19, 2009.
Abstract Abstract
This memo describes the Autokey security model for authenticating This memo describes the Autokey security model for authenticating
servers to clients using the Network Time Protocol (NTP) and public servers to clients using the Network Time Protocol (NTP) and public
key cryptography. Its design is based on the premise that IPSEC key cryptography. Its design is based on the premise that IPSEC
schemes cannot be adopted intact, since that would preclude stateless schemes cannot be adopted intact, since that would preclude stateless
servers and severely compromise timekeeping accuracy. In addition, servers and severely compromise timekeeping accuracy. In addition,
PKI schemes presume authenticated time values are always available to PKI schemes presume authenticated time values are always available to
enforce certificate lifetimes; however, cryptographically verified enforce certificate lifetimes; however, cryptographically verified
skipping to change at page 2, line 29 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . 21
10.1. No-Operation . . . . . . . . . . . . . . . . . . . . . . 24 10.1. No-Operation . . . . . . . . . . . . . . . . . . . . . . 24
10.2. Association Message (ASSOC) . . . . . . . . . . . . . . . 24 10.2. Association Message (ASSOC) . . . . . . . . . . . . . . . 24
10.3. Certificate Message (CERT) . . . . . . . . . . . . . . . 24 10.3. Certificate Message (CERT) . . . . . . . . . . . . . . . 24
10.4. Cookie Message (COOKIE) . . . . . . . . . . . . . . . . . 24 10.4. Cookie Message (COOKIE) . . . . . . . . . . . . . . . . . 24
10.5. Autokey Message (AUTO) . . . . . . . . . . . . . . . . . 24 10.5. Autokey Message (AUTO) . . . . . . . . . . . . . . . . . 25
10.6. Leapseconds Values Message (LEAP) . . . . . . . . . . . . 25 10.6. Leapseconds Values Message (LEAP) . . . . . . . . . . . . 25
10.7. Sign Message (SIGN) . . . . . . . . . . . . . . . . . . . 25 10.7. Sign Message (SIGN) . . . . . . . . . . . . . . . . . . . 25
10.8. Identity Messages (IFF, GQ, MV) . . . . . . . . . . . . . 25 10.8. Identity Messages (IFF, GQ, MV) . . . . . . . . . . . . . 25
11. Autokey State Machine . . . . . . . . . . . . . . . . . . . . 25 11. Autokey State Machine . . . . . . . . . . . . . . . . . . . . 25
11.1. Status Word . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Status Word . . . . . . . . . . . . . . . . . . . . . . . 25
11.2. Host State Variables . . . . . . . . . . . . . . . . . . 27 11.2. Host State Variables . . . . . . . . . . . . . . . . . . 27
11.3. Client State Variables (all modes) . . . . . . . . . . . 29 11.3. Client State Variables (all modes) . . . . . . . . . . . 29
11.4. Protocol State Transitions . . . . . . . . . . . . . . . 30 11.4. Protocol State Transitions . . . . . . . . . . . . . . . 30
11.4.1. Server Dance . . . . . . . . . . . . . . . . . . . . 30 11.4.1. Server Dance . . . . . . . . . . . . . . . . . . . . 30
11.4.2. Broadcast Dance . . . . . . . . . . . . . . . . . . . 31 11.4.2. Broadcast Dance . . . . . . . . . . . . . . . . . . . 31
11.4.3. Symmetric Dance . . . . . . . . . . . . . . . . . . . 32 11.4.3. Symmetric Dance . . . . . . . . . . . . . . . . . . . 32
11.5. Error Recovery . . . . . . . . . . . . . . . . . . . . . 33 11.5. Error Recovery . . . . . . . . . . . . . . . . . . . . . 33
11.6. Security Considerations . . . . . . . . . . . . . . . . . 35 11.6. Security Considerations . . . . . . . . . . . . . . . . . 35
11.7. Protocol Vulnerability . . . . . . . . . . . . . . . . . 35 11.7. Protocol Vulnerability . . . . . . . . . . . . . . . . . 35
11.8. Clogging Vulnerability . . . . . . . . . . . . . . . . . 36 11.8. Clogging Vulnerability . . . . . . . . . . . . . . . . . 36
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 13.1. Normative References . . . . . . . . . . . . . . . . . . 37
14.1. Normative References . . . . . . . . . . . . . . . . . . 37 13.2. Informative References . . . . . . . . . . . . . . . . . 37
14.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Timestamps, Filestamps and Partial Ordering . . . . . 38 Appendix A. Timestamps, Filestamps and Partial Ordering . . . . . 38
Appendix B. Identity Schemes . . . . . . . . . . . . . . . . . . 39 Appendix B. Identity Schemes . . . . . . . . . . . . . . . . . . 39
Appendix C. Private Certificate (PC) Scheme . . . . . . . . . . . 40 Appendix C. Private Certificate (PC) Scheme . . . . . . . . . . . 40
Appendix D. Trusted Certificate (TC) Scheme . . . . . . . . . . . 40 Appendix D. Trusted Certificate (TC) Scheme . . . . . . . . . . . 40
Appendix E. Schnorr (IFF) Identity Scheme . . . . . . . . . . . . 41 Appendix E. Schnorr (IFF) Identity Scheme . . . . . . . . . . . . 41
Appendix F. Guillard-Quisquater (GQ) Identity Scheme . . . . . . 43 Appendix F. Guillard-Quisquater (GQ) Identity Scheme . . . . . . 43
Appendix G. Mu-Varadharajan (MV) Identity Scheme . . . . . . . . 45 Appendix G. Mu-Varadharajan (MV) Identity Scheme . . . . . . . . 45
Appendix H. ASN.1 Encoding Rules . . . . . . . . . . . . . . . . 47 Appendix H. ASN.1 Encoding Rules . . . . . . . . . . . . . . . . 47
H.1. COOKIE request, IFF response, GQ response, MV response . 48 H.1. COOKIE request, IFF response, GQ response, MV response . 48
H.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 48 H.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 48
skipping to change at page 4, line 37 skipping to change at page 4, line 37
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. NTP Security Model 2. NTP Security Model
NTP security requirements are even more stringent than most other NTP security requirements are even more stringent than most other
distributed services. First, the operation of the authentication distributed services. First, the operation of the authentication
mechanism and the time synchronization mechanism are inextricably mechanism and the time synchronization mechanism are inextricably
intertwined. Reliable time synchronization requires cryptographic intertwined. Reliable time synchronization requires cryptographic
keys which are valid only over a designated time intervals; but, time keys which are valid only over a designated time intervals; but, time
intervals can be enforced only when participating servers and clients intervals can be enforced only when participating servers and clients
are reliably synchronized to UTC. In addition, the NTP subnet is are reliably synchronized to UTC. In addition, the NTP subnet is
hierarchical by nature, so time and trust flow from the primary hierarchical by nature, so time and trust flow from the primary
skipping to change at page 7, line 38 skipping to change at page 7, line 34
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 NTP software multicast mode as well, with exceptions as noted in the NTPv4
documentation. specification [I-D.ietf-ntp-ntpv4-proto].
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 [RFC1305]. As a practical matter, the key scheme described in [I-D.ietf-ntp-ntpv4-proto]. As a
reference implementation must use the same internal key practical matter, the reference implementation must use the same
management system, including the use of 32-bit key IDs and internal key management system, including the use of 32-bit key
existing mechanisms to store, activate and revoke keys. 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 9, line 41 skipping to change at page 9, line 41
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 by the MD5 message
digest algorithm to produce the 128-bit autokey value, which in the digest algorithm to produce the 128-bit autokey value, which in the
reference implementation is stored along with the key ID in a cache reference implementation is stored along with the key ID in a cache
used for symmetric keys as well as autokeys. Keys are retrieved from used for symmetric keys as well as autokeys. Keys are retrieved from
the cache by key ID using hash tables and a fast lookup algorithm. the cache by key ID using hash tables and a fast lookup algorithm.
For use with IPv4 the Source Address and Dest Address fields contain For use with IPv4 the Src Address and Dst Address fields contain 32
32 bits; for use with IPv6 these fields contain 128 bits. In either bits; for use with IPv6 these fields contain 128 bits. In either
case the Key ID and Cookie fields contain 32 bits. Thus, an IPv4 case the Key ID and Cookie fields contain 32 bits. Thus, an IPv4
autokey has four 32-bit words, while an IPv6 autokey has ten 32-bit 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 words. The source and destination addresses and key ID are public
values visible in the packet, while the cookie can be a public value values visible in the packet, while the cookie can be a public value
or shared private value, depending on the NTP mode. 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
skipping to change at page 10, line 42 skipping to change at page 10, line 42
Index n+1 +-----------+ Index n+1 +-----------+
Figure 3: Constructing the Key List Figure 3: Constructing the Key List
Figure 3 shows how the autokey list and autokey values are computed. Figure 3 shows how the autokey list and autokey values are computed.
The key IDs used in the autokey list consists of a sequence starting The key IDs used in the autokey list consists of a sequence starting
with a random 32-bit nonce (autokey seed) equal to or greater than with a random 32-bit nonce (autokey seed) equal to or greater than
the pivot as the first key ID. The first autokey is computed as the pivot as the first key ID. The first autokey is computed as
above using the given cookie and autokey seed and assigned index 0. above using the given cookie and autokey seed and assigned index 0.
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
The MD5 hash of the autokey is the key value saved in the key cache key ID. The MD5 hash of the autokey is the key value saved in the
along with the key ID. The first 32 bits of the key become the key key cache along with the key ID. The first 32 bits of the key become
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. In the reference implementation, the list is
terminated when the maximum key lifetime is about one hour, so for terminated when the maximum key lifetime is about one hour, so for
poll intervals above one hour a new key list containing only a single poll intervals above one hour a new key list containing only a single
entry is regenerated for every poll. entry is regenerated for every poll.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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 posts the client keys on a designated servers using secure means and delivers the client keys by
public web site. secure means.
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
skipping to change at page 14, line 8 skipping to change at page 14, line 8
| ||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 girls start by loading the host key, sign key, self-signed 1. The servers start by loading the host key, sign key, self-signed
certificate and group key. They start the Autokey protocol by certificate and group key. They start the Autokey protocol by
exchanging host names and negotiating digest/signature schemes exchanging host names and negotiating digest/signature schemes
and identity schemes. and identity schemes.
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.
skipping to change at page 15, line 45 skipping to change at page 15, line 45
separately while preserving security separation. Host X can prove separately while preserving security separation. Host X can prove
identity in Carol to clients Y and Z, but cannot prove to anybody identity in Carol to clients Y and Z, but cannot prove to anybody
that it belongs to either Alice or Helen. that it belongs to either Alice or Helen.
6. Identity Schemes 6. Identity Schemes
A digital signature scheme provides secure server authentication, but A digital signature scheme provides secure server authentication, but
it does not provide protection against masquerade, unless the server it does not provide protection against masquerade, unless the server
identity is verified by other means. The PKI model requires a server identity is verified by other means. The PKI model requires a server
to prove identity to the client by a certificate trail, but to prove identity to the client by a certificate trail, but
independent means such as a drivers license are required for a CA to independent means such as a driver's license are required for a CA to
sign the server certificate. While Autokey supports this model by sign the server certificate. While Autokey supports this model by
default, in a hierarchical ad-hoc network, especially with server default, in a hierarchical ad-hoc network, especially with server
discovery schemes like NTP Manycast, proving identity at each rest discovery schemes like NTP Manycast, proving identity at each rest
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
skipping to change at page 17, line 6 skipping to change at page 17, line 6
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. If the system timestamp in the form of the NTP seconds when it was created. If the
clock is synchronized to a proventic source, a signature is produced system clock is synchronized to a proventic source, a signature is
with valid (nonzero) timestamp. Otherwise, there is no signature and produced with valid (nonzero) timestamp. Otherwise, there is no
the timestamp is invalid (zero). The protocol detects and discards signature and the timestamp is invalid (zero). The protocol detects
extension fields with old or duplicate timestamps, before any values and discards extension fields with old or duplicate timestamps,
are used or signatures are verified. before any values 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 18, line 49
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. The o Cookie exchange. The request includes the public key of the
response includes the server cookie encrypted with this key. The server. The response includes the server cookie encrypted with
client uses this value when constructing the key list. Completion this key. The client uses this value when constructing the key
of this exchange lights the COOK bit as described below. list. Completion of this exchange lights the COOK bit as
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 public key and expiration time, then signs it using its own private 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 49 skipping to change at page 21, line 50
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 passes all extension field
tests are cycles spent to verify the signature. tests 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
skipping to change at page 22, line 37 skipping to change at page 22, line 42
/ 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 Each extension field is zero-padded to a 4-octet boundary. The
Length field covers the entire extension field, including the Length Length field covers the entire extension field, including the Length
and Padding fields. While the minimum field length is 8 octets, a and 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. The reference
implementation discards any packet with a field length more than 1024 implementation discards any packet with a field length more than 1024
octets. octets.
The extension field parser initializes a pointer to the first octet The extension field parser initializes a pointer to the first octet
beyond the NTP header fields and calculates the number of octets beyond the NTP header fields and calculates the number of octets
remaining in the packet. If this value is 20 the remaining data are remaining in the packet. If this value is 20 the remaining data is
the MAC and parsing is complete. If greater than 20 an extension the MAC and parsing is complete. If greater than 20 an extension
field is present. If the length is less than 4 or not a multiple of field is present. If the length is less than 4 or not a multiple of
4, a format error has occurred and the packet is discarded; 4, a format error has occurred and the packet is discarded;
otherwise, the parser increments the pointer by the lengthuses uses otherwise, the parser increments the pointer by the length and then
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.
skipping to change at page 24, line 46 skipping to change at page 24, line 47
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) 10.4. Cookie Message (COOKIE)
The Cookie Message (Field Type 3) is used in server and symmetric The Cookie Message (Field Type 3) is used in server and symmetric
modes to obtain the server cookie. The request contains the host modes to obtain the server cookie. The request contains the host
public key encoded with ASN.1 syntax as described in Appendix H. The public key encoded with ASN.1 syntax as described in Appendix H. The
response contains the cookie encrypted by the public key in the response contains the cookie encrypted by the public key in the
request. A valid response lights the COOKIE bit in the associaton request. A valid response lights the COOKIE bit in the association
status word. status word.
10.5. Autokey Message (AUTO) 10.5. Autokey Message (AUTO)
The Autokey Message (Field Type 4) is used to obtain the autokey The Autokey Message (Field Type 4) is used to obtain the autokey
values. The request contains no value for a client or the autokey values. The request contains no value for a client or the autokey
values for a symmetric peer. The response contains two 32-bit words, values for a symmetric peer. The response contains two 32-bit words,
the first is the final key ID, while the second is the index of the the first is the final key ID, while the second is the index of the
final key ID. A valid response lights the AUTO bit in the final key ID. A valid response lights the AUTO bit in the
association status word. association status word.
skipping to change at page 27, line 34 skipping to change at page 27, 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 livelock under some conditions. SYNC is This is necessary to avoid resource starvation (livelock) under some
lit when the client has synchronized to a proventic source and never conditions. SYNC is lit when the client has synchronized to a
dim after that. PEER is lit when the server has synchronized, as proventic source and never dim after that. PEER is lit when the
indicated in the NTP header, and never dim after that. server has synchronized, as indicated in the NTP header, and never
dim after that.
11.2. Host State Variables 11.2. 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. In the reference
implementation this is a configurable value. 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
skipping to change at page 29, line 48 skipping to change at page 30, line 5
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.
Subject Name - The server host name copied from the ASSOC respones. Subject Name - The server host name copied from the ASSOC response.
Issuer Name - The host name signing the certificate. It is extracted Issuer Name - The host name signing the certificate. It is extracted
from the current server certificate upon arrival and used to request from the current server certificate upon arrival and used to request
the next host on the certificate trail. the next host on the certificate trail.
Server Public Key - The public key used to decrypt signatures. It is Server Public Key - The public key used to decrypt signatures. It is
extracted from the server host certificate. extracted from the server host certificate.
Server Message Digest - The digest/signature scheme determined in the Server Message Digest - The digest/signature scheme determined in the
parameter exchange. parameter exchange.
skipping to change at page 30, line 48 skipping to change at page 31, line 5
message as detailed above. message as detailed above.
11.4.1. Server Dance 11.4.1. 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. This example and others assumes validated by the autokey sequence. The following example and others
the IFF identity scheme has been selected in the parameter exchange.. assume the IFF identity scheme has been selected in the parameter
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);
skipping to change at page 31, line 39 skipping to change at page 31, line 43
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 11.4.2. 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 ssociation 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
includes an AUTO response instead. includes an AUTO response instead.
In the broadcast dance extension fields are used with every packet, In the broadcast dance extension fields are used with every packet,
so the cookie is always zero and no cookie exchange is necessary. As so the cookie is always zero and no cookie exchange is necessary. As
in the server dance, the clock is updated when PREV is lit and the in the server dance, the clock is updated when PREV is lit and the
dance ends when LEAP is lit. Note that the SIGN and LEAP requests dance ends when LEAP is lit. Note that the SIGN and LEAP requests
skipping to change at page 32, line 34 skipping to change at page 32, line 39
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
retrive 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 11.4.3. 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
skipping to change at page 33, line 34 skipping to change at page 33, line 34
20 else if (!LEAP) /* leapsecond values 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 a cookie exchange and then retrives the now nonzero cookie using a cookie exchange and then the
the updated autokey values using an autokey exchange. updated autokey values using an autokey exchange.
As in the broadcasst 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 tha 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 11.5. 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
skipping to change at page 34, line 25 skipping to change at page 34, line 25
counter defined in [I-D.ietf-ntp-ntpv4-proto]. At every poll counter defined in [I-D.ietf-ntp-ntpv4-proto]. At every poll
interval the reach register is shifted left, the low order bit is interval the reach register is shifted left, the low order bit is
dimmed and the high order bit is lost. At the same time the unreach dimmed and the high order bit is lost. At the same time the unreach
counter is incremented by one. If an arriving packet passes all counter is incremented by one. If an arriving packet passes all
authentication and sanity checks, the rightmost bit of the reach authentication and sanity checks, the rightmost bit of the reach
register is lit and the unreach counter is set to zero. If any bit register is lit and the unreach counter is set to zero. If any bit
in the reach register is lit, the server is reachable, otherwise it in the reach register is lit, the server is reachable, otherwise it
is unreachable. is unreachable.
When the first poll is sent from an association, the reach register When the first poll is sent from an association, the reach register
and unreach counter are set to zero. If the the unreach counter and unreach counter are set to zero. If the unreach counter reaches
reaches 16, the poll interval is doubled. In addition, if 16, the poll interval is doubled. In addition, if association is
association is persistent, it is demobilized. This reduces the persistent, it is demobilized. This reduces the network load for
network load for packets that are unlikely to elicit a response. packets that are unlikely to elicit a response.
At each state in the protocol the client expects a particular At each state in the protocol the client expects a particular
response from the server. A request is included in the NTP packet response from the server. A request is included in the NTP packet
sent at each poll interval until a valid response is received or a sent at each poll interval until a valid response is received or a
general reset occurs, in which case the protocol restarts from the general reset occurs, in which case the protocol restarts from the
beginning. A general reset also occurs for an association when an beginning. A general reset also occurs for an association when an
unrecoverable protocol error occurs. A general reset occurs for all unrecoverable protocol error occurs. A general reset occurs for all
associations when the system clock is first synchronized or the clock associations when the system clock is first synchronized or the clock
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 and not a replay, as confirmed by the NTP on-wire by the client is 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:
skipping to change at page 35, line 46 skipping to change at page 35, line 46
cookie, could not present a valid signature. cookie, could not present a valid signature.
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 tempoerarily revers to client mode to refresh the broadcast client temporarily reverts to client mode to refresh the
autokey values. autokey values.
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
skipping to change at page 37, line 7 skipping to change at page 37, line 7
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 middleman can modify a recent packet with an intentional
bit error. A stateless server will return a crypto-NAK message which bit error. A stateless server will return a crypto-NAK message which
will cause the client to perform a general reset. The middleman can will cause the client to perform a general reset. The middleman can
do other things as well and have nothing to do with Autokey. do other things as well and have nothing to do with Autokey.
12. IANA Considerations 12. IANA Considerations
Any IANA registries needed? IANA is requested to add to the Extension Field Types associated with
the NTP protocol (see [I-D.ietf-ntp-ntpv4-proto], section 16), the
13. Acknowledgements values 1 through 7 for the Autokey PRotocol.
...
14. References 13. References
14.1. Normative References 13.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-09 Algorithms Specification", draft-ietf-ntp-ntpv4-proto-10
(work in progress), February 2008. (work in progress), July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References 13.2. Informative References
[DASBUCH] Mills, D., ""Compouter Network Time Synchronization - the [DASBUCH] Mills, D., "Compouter 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)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
skipping to change at page 40, line 18 skipping to change at page 40, line 12
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
has the same group key as the client. has the same group key as the client.
Appendix C. Private Certificate (PC) Scheme Appendix C. Private Certificate (PC) Scheme
The PC scheme shown in Figure Figure 12 uses a private certificate as The PC scheme shown in Figure 12 uses a private certificate as the
the group key. group key.
Trusted Trusted
Authority Authority
Secure +-------------+ Secure Secure +-------------+ Secure
+--------------| Certificate |-------------+ +--------------| Certificate |-------------+
| +-------------+ | | +-------------+ |
| | | |
\|/ \|/ \|/ \|/
+-------------+ +-------------+ +-------------+ +-------------+
| Certificate | | Certificate | | Certificate | | Certificate |
skipping to change at page 40, line 45 skipping to change at page 40, line 39
A certificate is designated private when the X509v3 Extended Key A certificate is designated private when the X509v3 Extended Key
Usage extension field is present and contains "Private". The private Usage extension field is present and contains "Private". The private
certificate is distributed to all other group members by secret certificate is distributed to all other group members by secret
means, so in fact becomes a symmetric key. Private certificates are means, so in fact becomes a symmetric key. Private certificates are
also trusted, so there is no need for a certificate trail or identity also trusted, so there is no need for a certificate trail or identity
scheme. scheme.
Appendix D. Trusted Certificate (TC) Scheme Appendix D. Trusted Certificate (TC) Scheme
All other schemes involve a conventional certificate trail as shown All other schemes involve a conventional certificate trail as shown
in Figure Figure 13. in Figure 13.
Trusted Trusted
Host Host Host Host Host Host
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
+--->| Subject | +--->| Subject | +--->| Subject | +--->| Subject | +--->| Subject | +--->| Subject |
| +-----------+ | +-----------+ | +-----------+ | +-----------+ | +-----------+ | +-----------+
...---+ | Issuer |---+ | Issuer |---+ | Issuer | ...---+ | Issuer |---+ | Issuer |---+ | Issuer |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| Signature | | Signature | | Signature | | Signature | | Signature | | Signature |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
skipping to change at page 41, line 29 skipping to change at page 41, line 29
trusted certificate. A certificate is designated trusted when an trusted certificate. A certificate is designated trusted when an
X509v3 Extended Key Usage extension field is present and contains X509v3 Extended Key Usage extension field is present and contains
"trustRoot". If no identity scheme is specified in the parameter "trustRoot". If no identity scheme is specified in the parameter
exchange, this is the default scheme. exchange, this is the default scheme.
Appendix E. Schnorr (IFF) Identity Scheme Appendix E. Schnorr (IFF) Identity Scheme
The IFF scheme is useful when the group key is concealed, so that The IFF scheme is useful when the group key is concealed, so that
client keys need not be protected. The primary disadvantage is that client keys need not be protected. The primary disadvantage is that
when the server key is refreshed all hosts must update the client when the server key is refreshed all hosts must update the client
key. The scheme shown in Figure Figure 14 involves a set of public key. The scheme shown in Figure 14 involves a set of public
parameters and a group key including both private and public parameters and a group key including both private and public
components. The public component is the client key. components. The public component is the client key.
Trusted Trusted
Authority Authority
+------------+ +------------+
| Parameters | | Parameters |
Secure +------------+ Insecure Secure +------------+ Insecure
+-------------| Group Key |-----------+ +-------------| Group Key |-----------+
| +------------+ | | +------------+ |
skipping to change at page 43, line 20 skipping to change at page 43, line 20
Appendix F. Guillard-Quisquater (GQ) Identity Scheme Appendix F. Guillard-Quisquater (GQ) Identity Scheme
The GQ scheme is useful when the server key must be refreshed from The GQ scheme is useful when the server key must be refreshed from
time to time without changing the group key. The NTP utility time to time without changing the group key. The NTP utility
programs include the GQ client key in the X509v3 Subject Key programs include the GQ client key in the X509v3 Subject Key
Identifier extension field. The primary disadvantage of the scheme Identifier extension field. The primary disadvantage of the scheme
is that the group key must be protected in both the server and is that the group key must be protected in both the server and
client. A secondary disadvantage is that when a server key is client. A secondary disadvantage is that when a server key is
refreshed, old extension fields no longer work. The scheme is shown refreshed, old extension fields no longer work. The scheme is shown
in Figure Figure 16a involves a set of public parameters and group in Figure 16a involves a set of public parameters and group key used
key used to generate private server keys and client keys. to generate private server keys and client keys.
Trusted Trusted
Authority Authority
+------------+ +------------+
| Parameters | | Parameters |
Secure +------------+ Secure Secure +------------+ Secure
+-------------| Group Key |-----------+ +-------------| Group Key |-----------+
| +------------+ | | +------------+ |
\|/ \|/ \|/ \|/
+------------+ Challenge +------------+ +------------+ Challenge +------------+
skipping to change at page 44, line 14 skipping to change at page 44, line 14
these values could impersonate a legitimate server. The private these values could impersonate a legitimate server. The private
server key and public client key are constructed later. server key and public client key are constructed later.
The TA hides GQ parameters and keys in an OpenSSL RSA cuckoo The TA hides GQ parameters and keys in an OpenSSL RSA cuckoo
structure. The GQ parameters are identical to the RSA parameters, so structure. The GQ parameters are identical to the RSA parameters, so
the OpenSSL library can be used directly. When generating a the OpenSSL library can be used directly. When generating a
certificate, the server rolls random server key u (0 < u < n) and certificate, the server rolls random server key u (0 < u < n) and
client key its inverse obscured by the group key v = (u^-1)^b mod n. client key its inverse obscured by the group key v = (u^-1)^b mod n.
These values replace the private and public keys normally generated These values replace the private and public keys normally generated
by the RSA scheme. The client key is conveyed in a X.509 certificate by the RSA scheme. The client key is conveyed in a X.509 certificate
extension. The updated GQ structure shown in Figure Figure 17 is extension. The updated GQ structure shown in Figure 17 is written as
written as an RSA private key encoded in PEM. Unused structure an RSA private key encoded in PEM. Unused structure members are set
members are set to one. to one.
+---------------------------------+-------------+ +---------------------------------+-------------+
| GQ | RSA | Item | Include | | GQ | RSA | Item | Include |
+=========+==========+============+=============+ +=========+==========+============+=============+
| n | n | modulus | all | | n | n | modulus | all |
+---------+----------+------------+-------------+ +---------+----------+------------+-------------+
| b | e | group key | all | | b | e | group key | all |
+---------+----------+------------+-------------+ +---------+----------+------------+-------------+
| u | p | server key | server | | u | p | server key | server |
+---------+----------+------------+-------------+ +---------+----------+------------+-------------+
skipping to change at page 45, line 35 skipping to change at page 45, line 35
clients have no further information and, in particular, cannot clients have no further information and, in particular, cannot
masquerade as a server or TA. masquerade as a server or TA.
The scheme uses an encryption algorithm similar to El Gamal The scheme uses an encryption algorithm similar to El Gamal
cryptography and a polynomial formed from the expansion of product cryptography and a polynomial formed from the expansion of product
terms (x-x_1)(x-x_2)(x-x_3)...(x-x_n), as described in [MV]. The terms (x-x_1)(x-x_2)(x-x_3)...(x-x_n), as described in [MV]. The
paper has significant errors and serious omissions. The cryptosystem paper has significant errors and serious omissions. The cryptosystem
is constructed so that, for every encryption key E its inverse is is constructed so that, for every encryption key E its inverse is
(g-bar^x-hat_j)(g-hat^x-bar_j) mod p for every j. This remains true (g-bar^x-hat_j)(g-hat^x-bar_j) mod p for every j. This remains true
if both quantities are raised to the power k mod p. The difficulty if both quantities are raised to the power k mod p. The difficulty
in finding E is equivalent to the descrete log problem. in finding E is equivalent to the discrete log problem.
The scheme is shown in Figure Figure 18. The TA generates the The scheme is shown in Figure 18. The TA generates the parameters,
parameters, group key, server keys and client keys, one for each group key, server keys and client keys, one for each client, all of
client, all of which must be protected to prevent theft of service. which must be protected to prevent theft of service. Note that only
Note that only the TA has the group key, which is not known to either the TA has the group key, which is not known to either the servers or
the servers or clients. In this sense the MV scheme is a zero- clients. In this sense the MV scheme is a zero-knowledge proof.
knowledge proof.
Trusted Trusted
Authority Authority
+------------+ +------------+
| Parameters | | Parameters |
+------------+ +------------+
| Group Key | | Group Key |
+------------+ +------------+
| Server Key | | Server Key |
Secure +------------+ Secure Secure +------------+ Secure
skipping to change at page 46, line 28 skipping to change at page 46, line 28
| Parameters |<------------------------| Parameters | | Parameters |<------------------------| Parameters |
+------------+ +------------+ +------------+ +------------+
| Server Key |------------------------>| Client Key | | Server Key |------------------------>| Client Key |
+------------+ Response +------------+ +------------+ Response +------------+
Server Client Server Client
Figure 18: Mu-Varadharajan (MV) Identity Scheme Figure 18: Mu-Varadharajan (MV) Identity Scheme
The TA hides MV parameters and keys in OpenSSL DSA cuckoo structures. The TA hides MV parameters and keys in OpenSSL DSA cuckoo structures.
The MV parameters are identical to the DSA parameters, so the OpenSSL The MV parameters are identical to the DSA parameters, so the OpenSSL
library can be used directly. The structure shown in Figures below library can be used directly. The structure shown in the figures
are written to files as a DSA private key encoded in PEM. Unused below are written to files as a the fkey encoded in PEM. Unused
structure members are set to one. Figure Figure 19 shows the data structure members are set to one. The Figure 19 shows the data
structure used by the servers, while Figure Figure 20 shows the structure used by the servers, while Figure Figure 20 shows the
client data structure associated with each activation key. client data structure associated with each activation key.
+---------------------------------+-------------+ +---------------------------------+-------------+
| MV | DSA | Item | Include | | MV | DSA | Item | Include |
+=========+==========+============+=============+ +=========+==========+============+=============+
| p | p | modulus | all | | p | p | modulus | all |
+---------+----------+------------+-------------+ +---------+----------+------------+-------------+
| q | q | modulus | server | | q | q | modulus | server |
+---------+----------+------------+-------------+ +---------+----------+------------+-------------+
 End of changes. 46 change blocks. 
99 lines changed or deleted 94 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/