draft-ietf-ntp-autokey-02.txt   draft-ietf-ntp-autokey-03.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 Obsoletes: RFC 1305 D. Mills
(if approved) U. Delaware (if approved) U. Delaware
Intended status: Informational June 9, 2008
Expires: September 2, 2008 Expires: December 11, 2008
Network Time Protocol Version 4 Autokey Specification Network Time Protocol Version 4 Autokey Specification
draft-ietf-ntp-autokey-02 draft-ietf-ntp-autokey-03
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 36
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 September 2, 2008. This Internet-Draft will expire on December 11, 2008.
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 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 23 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) . . . . . . . . . . . . . . . . . 24
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
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 22, line 9 skipping to change at page 22, line 9
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type | Length | |R|E| Code | Field Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID | | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filestamp | | Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Length | | Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ / \ /
skipping to change at page 23, line 6 skipping to change at page 23, line 6
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 are
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 lengthuses uses
the same rules as above to determine whether a MAC is present or the same rules as above to determine whether a MAC is present or
another extension field. another extension field.
The 8-bit Code field specifies the request or response operation, In Autokey the 8-bit Field Type field is interpreted as the version
while the 4-bit Version Number (VN) field is 2 for the current number, currently 2. For future versions values 1-7 have been
protocol version. There are four flag bits: bit 0 is the Response reserved for Autokey; other values may be assigned for other
Flag (R) and bit 1 is the Error Flag (E); the other two bits are applications. The 6-bit Code field specifies the request or response
presently unused and should be set to 0. The remaining fields will operation. There are two flag bits: bit 0 is the Response Flag (R)
be described later. 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.
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 Association ID field is set to the
value previously received from the server or 0 otherwise. The server value previously received from the server or 0 otherwise. The server
returns a response with the same operation code in the Code field and returns a response with the same operation code in the Code field and
lights the R bit. The server can also light the E bit in case of lights the R bit. The server can also light the E bit in case of
error. The Association ID field is set to the association ID of the error. The Association ID field is set to the association ID of the
server as a handle for subsequent exchanges. If for some reason the server as a handle for subsequent exchanges. If for some reason the
association ID value in a request does not match the association ID association ID value in a request does not match the association ID
skipping to change at page 37, line 22 skipping to change at page 37, line 22
14. References 14. References
14.1. Normative References 14.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-09
(work in progress), February 2008. (work in progress), February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References 14.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
 End of changes. 8 change blocks. 
12 lines changed or deleted 20 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/