draft-ietf-ntp-autokey-04.txt   draft-ietf-ntp-autokey-05.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 Intended status: Informational D. Mills
Expires: February 19, 2009 U. Delaware Expires: November 30, 2009 U. Delaware
August 18, 2008 May 29, 2009
Network Time Protocol Version 4 Autokey Specification Network Time Protocol Version 4 Autokey Specification
draft-ietf-ntp-autokey-04 draft-ietf-ntp-autokey-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering 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 February 19, 2009. This Internet-Draft will expire on November 30, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 3, line 11 skipping to change at page 4, line 4
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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 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 31, line 22 skipping to change at page 31, line 22
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) /* wait for synchronization */ 14 else if (!SYNC) /* synchronization wait */
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) /* leapsecond values exchange */ 18 else if (!LEAP) /* leap sec value 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.
skipping to change at page 32, line 24 skipping to change at page 32, line 24
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) /* wait for synchronization */ 14 else if (!SYNC) /* synchronization wait */
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) /* leapsecond values exchange */ 18 else if (!LEAP) /* leap sec value 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
skipping to change at page 33, line 20 skipping to change at page 33, line 20
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) /* wait for synchronization */ 16 else if (!SYNC) /* synchronization wait */
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) /* leapsecond values exchange */ 20 else if (!LEAP) /* leap sec value 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
skipping to change at page 37, line 17 skipping to change at page 37, line 17
IANA is requested to add to the Extension Field Types associated with 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 the NTP protocol (see [I-D.ietf-ntp-ntpv4-proto], section 16), the
values 1 through 7 for the Autokey PRotocol. values 1 through 7 for the Autokey PRotocol.
13. References 13. References
13.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-10 Algorithms Specification", draft-ietf-ntp-ntpv4-proto-11
(work in progress), July 2008. (work in progress), September 2008.
13.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.
skipping to change at page 52, line 4 skipping to change at line 2311
Phone: +1 443 778 1319 Phone: +1 443 778 1319
Email: brian@innovationslab.net Email: brian@innovationslab.net
Dr. David L. Mills Dr. David L. Mills
University of Delaware University of Delaware
Newark, DE 19716 Newark, DE 19716
US US
Phone: +1 302 831 8247 Phone: +1 302 831 8247
Email: mills@udel.edu Email: mills@udel.edu
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 13 change blocks. 
17 lines changed or deleted 25 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/