Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications
RFC 3996
| Document | Type |
RFC
- Proposed Standard
(March 2005)
Errata
Updates RFC 2911
|
|
|---|---|---|---|
| Authors | Robert G. Herriot , Thomas N. Hastings , Harry Lewis | ||
| Last updated | 2020-01-21 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Scott Hollenbeck | |
| Send notices to | (None) |
RFC 3996
Internet Engineering Task Force (IETF) B. Haberman, Ed.
Request for Comments: 5906 JHU/APL
Category: Informational D. Mills
ISSN: 2070-1721 U. Delaware
June 2010
Network Time Protocol Version 4: Autokey Specification
Abstract
This memo describes the Autokey security model for authenticating
servers to clients using the Network Time Protocol (NTP) and public
key cryptography. Its design is based on the premise that IPsec
schemes cannot be adopted intact, since that would preclude stateless
servers and severely compromise timekeeping accuracy. In addition,
Public Key Infrastructure (PKI) schemes presume authenticated time
values are always available to enforce certificate lifetimes;
however, cryptographically verified timestamps require interaction
between the timekeeping and authentication functions.
This memo includes the Autokey requirements analysis, design
principles, and protocol specification. A detailed description of
the protocol states, events, and transition functions is included. A
prototype of the Autokey design based on this memo has been
implemented, tested, and documented in the NTP version 4 (NTPv4)
software distribution for the Unix, Windows, and Virtual Memory
System (VMS) operating systems at http://www.ntp.org.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5906.
Haberman & Mills Informational [Page 1]
RFC 5906 NTPv4 Autokey June 2010
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Haberman & Mills Informational [Page 2]
RFC 5906 NTPv4 Autokey June 2010
Table of Contents
1. Introduction ....................................................4
2. NTP Security Model ..............................................4
3. Approach ........................................................7
4. Autokey Cryptography ............................................8
5. Autokey Protocol Overview ......................................12
6. NTP Secure Groups ..............................................14
7. Identity Schemes ...............................................19
8. Timestamps and Filestamps ......................................20
9. Autokey Operations .............................................22
10. Autokey Protocol Messages .....................................23
10.1. No-Operation .............................................26
10.2. Association Message (ASSOC) ..............................26
10.3. Certificate Message (CERT) ...............................26
10.4. Cookie Message (COOKIE) ..................................27
10.5. Autokey Message (AUTO) ...................................27
10.6. Leapseconds Values Message (LEAP) ........................27
10.7. Sign Message (SIGN) ......................................27
10.8. Identity Messages (IFF, GQ, MV) ..........................27
11. Autokey State Machine .........................................28
11.1. Status Word ..............................................28
11.2. Host State Variables .....................................30
11.3. Client State Variables (all modes) .......................33
11.4. Protocol State Transitions ...............................34
11.4.1. Server Dance ......................................34
11.4.2. Broadcast Dance ...................................35
11.4.3. Symmetric Dance ...................................36
11.5. Error Recovery ...........................................37
12. Security Considerations .......................................39
12.1. Protocol Vulnerability ...................................39
12.2. Clogging Vulnerability ...................................40
13. IANA Considerations ...........................................42
13. References ....................................................42
13.1. Normative References .....................................42
13.2. Informative References ...................................43
Appendix A. Timestamps, Filestamps, and Partial Ordering .........45
Appendix B. Identity Schemes .....................................46
Appendix C. Private Certificate (PC) Scheme ......................47
Appendix D. Trusted Certificate (TC) Scheme ......................47
Appendix E. Schnorr (IFF) Identity Scheme ........................48
Appendix F. Guillard-Quisquater (GQ) Identity Scheme .............49
Appendix G. Mu-Varadharajan (MV) Identity Scheme .................51
Appendix H. ASN.1 Encoding Rules .................................54
Appendix I. COOKIE Request, IFF Response, GQ Response, MV
Response .............................................54
Appendix J. Certificates .........................................55
Haberman & Mills Informational [Page 3]
RFC 5906 NTPv4 Autokey June 2010
RFC 3996 IPP: The 'ippget' Delivery Method March 2005
3. MUST convert the associated 'ipp' URLs for use in IPP Get-
Notifications operation to their corresponding 'http' URL forms
for use in the HTTP layer, according to the rules in section 5,
"IPP URL Scheme", in [RFC2910]; and
4. MUST meet the security conformance requirements stated in section
18.5.
13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R., and J.
Wenn, "Internet Printing Protocol/1.1: Encoding and
Transport", RFC 2910, September 2000.
[RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S., and
P. Powell, "Internet Printing Protocol/1.1: Model and
Semantics", RFC 2911, September 2000.
[RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol
(IPP): Event Notifications and Subscriptions", RFC 3995,
March 2005.
14. Informative References
[RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner,
"Internet Printing Protocol/1.0: Encoding and
Transport", RFC 2565, April 1999.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and
P. Powell, "Internet Printing Protocol/1.0: Model and
Semantics", RFC 2566, April 1999.
[RFC2567] Wright, F., "Design Goals for an Internet Printing
Protocol", RFC 2567, April 1999.
[RFC2568] Zilles, S., "Rationale for the Structure of the Model
and Protocol for the Internet Printing Protocol", RFC
2568, April 1999.
[RFC2569] Herriot, R., Hastings, T., Jacobs, N., and J. Martin,
"Mapping between LPD and IPP Protocols", RFC 2569, April
1999.
Herriot, et al. Standards Track [Page 23]
RFC 3996 IPP: The 'ippget' Delivery Method March 2005
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2707] Bergman, R., Hastings, T., Isaacson, S., and H. Lewis,
"Job Monitoring MIB - V1.0", RFC 2707, November 1999.
[RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
Holst, "Internet Printing Protocol/1.1: Implementor's
Guide", RFC 3196, November 2001.
[RFC3997] Hastings, T., Ed., deBry, R., and H. Lewis, "Internet
Printing Protocol (IPP): Requirements for IPP
Notifications", RFC 3997, March 2005.
15. IANA Considerations
This section contains the exact information that the IANA has added
to the IPP Registries according to the procedures defined in
[RFC2911], section 6. These registrations have been published in the
http://www.iana.org/assignments/ipp-registrations registry.
15.1. Attribute Registrations
The following table lists the attributes defined in this document.
This has been registered according to the procedures in RFC 2911
[RFC2911] section 6.2.
Printer Description attributes: Reference Section
------------------------------- --------- -------
ippget-event-life (integer(15:MAX)) [RFC3996] 8.1
15.2. Delivery Method and Additional Keyword Attribute Value
Registrations for Existing Attributes
This section lists additional keyword attribute value registrations
for use with existing attributes defined in other documents. These
have been registered according to the procedures in [RFC2911],
section 6.1. According to [RFC3995], section 24.7.3, Pull Delivery
Method registrations are the keyword attribute value registrations
for the "notify-pull-method" and "notify-pull-method-supported"
attributes.
Herriot, et al. Standards Track [Page 24]
RFC 3996 IPP: The 'ippget' Delivery Method March 2005
Attribute (attribute syntax)
Values Reference Section
----------------------- --------- -------
notify-pull-method (type2 keyword) [RFC3995] 5.3.2
notify-pull-method-supported (1setOf type2 keyword)
[RFC3995] 5.3.2.1
ippget [RFC3996] 9.1
15.3. Additional Enum Attribute Values
The following table lists the enum attribute values defined in this
document. These have been registered according to the procedures in
[RFC2911], section 6.1.
Attribute (attribute syntax)
Value Name Reference Section
------ ----------------------------- --------- -------
operations-supported (1setOf type2 enum) [RFC2911] 4.4.15
0x001C Get-Notifications [RFC3996] 9.2
15.4. Operation Registrations
The following table lists the operations defined in this document.
This has been registered according to the procedures in RFC 2911
[RFC2911] section 6.4.
Operations: Reference Section
----------- --------- -------
Get-Notifications [RFC3996] 5
15.5. Status Code Registrations
The following table lists the status codes defined in this document.
This has been registered according to the procedures in [RFC2911],
section 6.6.
Status codes: Reference Section
------------- --------- -------
successful-ok-events-complete (0x0007) [RFC3996] 10.1
16. Internationalization Considerations
The IPP Printer MUST localize the "notify-text" attribute as
specified in section 14 of [RFC3995].
Herriot, et al. Standards Track [Page 25]
RFC 3996 IPP: The 'ippget' Delivery Method March 2005
In addition, when the client receives the Get-Notifications response,
it is expected to localize the attributes that have the 'keyword'
attribute syntax according to the charset and natural language
requested in the Get-Notifications request.
17. Security Considerations
The IPP Model and Semantics document [RFC2911, section 8] discusses
high-level security requirements (Client Authentication, Server
Authentication and Operation Privacy). The IPP Transport and
Encoding document [RFC2910, section 8] discusses the security
requirements for the IPP protocol. Client Authentication is the
mechanism by which the client proves its identity to the server in a
secure manner. Server Authentication is the mechanism by which the
server proves its identity to the client in a secure manner.
Operation Privacy is defined as a mechanism for protecting operations
from eavesdropping.
The 'ippget' Delivery Method with its Get-Notifications operations
leverages the security mechanism that are used in IPP/1.1 [RFC2910
and RFC2911] without adding any additional security mechanisms in
order to maintain the same security support as IPP/1.1.
The access control model for the Get-Notifications operation defined
in this document is the same as the access control model for the
Get-Job-Attributes operation (see [RFC2911], section 3.2.6). The
primary difference is that a Get-Notifications operation is directed
at Subscription Objects rather than at Job objects, and a returned
attribute group contains Event Notification attributes rather than
Job object attributes.
17.1. Notification Recipient Client Access Rights
The Notification Recipient client MUST have the following access
rights to the Subscription object(s) targeted by the Get-
Notifications operation request:
The authenticated user (see [RFC2911], section 8.3) performing
this operation MUST be (1) the owner of each Subscription Object
identified by the "notify-subscription-ids" operation attribute
(see section 5.1.1), (2) an operator or administrator of the
Printer (see [RFC2911], sections 1 and 8.5), or (3) otherwise
authorized by the Printer's administrator-configured security
policy to request Event Notifications from the target Subscription
Object(s). Furthermore, the Printer's security policy MAY limit
Herriot, et al. Standards Track [Page 26]
RFC 3996 IPP: The 'ippget' Delivery Method March 2005
the attributes returned by the Get-Notifications operation, in a
manner similar to that of the Get-Job-Attributes operation (see
[RFC2911], end of section 3.3.4.2).
17.2. Printer Security Threats
Because the Get-Notifications operation is sent in the same direction
as are Job Creation operations, usually by the same client, this
Event Notification Delivery Method poses no additional
authentication, authorization, privacy, firewall, or port assignment
issues above those for the IPP Get-Job-Attributes and Get-Printer-
Attributes operations (see [RFC2911], sections 3.2.6 and 3.2.5).
17.3. Notification Recipient Security Threats
Unwanted Events Notifications (spam): Unlike Push Event Notification
Delivery Methods in which the IPP Printer initiates the Event
Notification, with the Pull Delivery Method defined in this document,
the Notification Recipient is the client that initiates the Get-
Notifications operation (see section 5). Therefore, with this method
there is no chance of "spam" notifications.
Note: When a client stays connected to a Printer by using the Event
Wait Mode (see section 5.1.3) in order to receive Event Notifications
as they occur, it can close down the IPP connection at any time and
so can avoid future unwanted Event Notifications at any time.
It is true that the client has control over whether to ask for Event
Notifications. However, if the client subscribes to an event and
does a Get-Notifications request, it gets all events for the
Subscription Object in the sequence number range (see section 5.1.2),
not just those it wants. If a client subscribes to a Per-Printer
Subscription job event, such as 'job-completed', and someone then
starts and cancels thousands of jobs, the client would have to
receive these events in addition to those it is interested in. A
client can protect itself better by subscribing to its own jobs by
using a Per-Job Subscription, rather than create a Per-Printer
subscription whose Job events apply to all jobs.
17.4. Security Requirements for Printers
For the Get-Notifications operation defined in this document, the
same Printer conformance requirements apply for supporting and using
Client Authentication, Server Authentication and Operation Privacy as
stated in [RFC2910] section 8 for all IPP operations.
Herriot, et al. Standards Track [Page 27]
RFC 3996 IPP: The 'ippget' Delivery Method March 2005
1. Introduction
A distributed network service requires reliable, ubiquitous, and
survivable provisions to prevent accidental or malicious attacks on
the servers and clients in the network or the values they exchange.
Reliability requires that clients can determine that received packets
are authentic; that is, were actually sent by the intended server and
not manufactured or modified by an intruder. Ubiquity requires that
a client can verify the authenticity of a server using only public
information. Survivability requires protection from faulty
implementations, improper operation, and possibly malicious clogging
and replay attacks.
This memo describes a cryptographically sound and efficient
methodology for use in the Network Time Protocol (NTP) [RFC5905].
The various key agreement schemes [RFC4306][RFC2412][RFC2522]
proposed require per-association state variables, which contradicts
the principles of the remote procedure call (RPC) paradigm in which
servers keep no state for a possibly large client population. An
evaluation of the PKI model and algorithms, e.g., as implemented in
the OpenSSL library, leads to the conclusion that any scheme
requiring every NTP packet to carry a PKI digital signature would
result in unacceptably poor timekeeping performance.
The Autokey protocol is based on a combination of PKI and a pseudo-
random sequence generated by repeated hashes of a cryptographic value
involving both public and private components. This scheme has been
implemented, tested, and deployed in the Internet of today. A
detailed description of the security model, design principles, and
implementation is presented in this memo.
This informational document describes the NTP extensions for Autokey
as implemented in an NTPv4 software distribution available from
http://www.ntp.org. This description is provided to offer a basis
for future work and a reference for the software release. This
document also describes the motivation for the extensions within the
protocol.
2. NTP Security Model
NTP security requirements are even more stringent than most other
distributed services. First, the operation of the authentication
mechanism and the time synchronization mechanism are inextricably
intertwined. Reliable time synchronization requires cryptographic
keys that are valid only over designated time intervals; but, time
intervals can be enforced only when participating servers and clients
are reliably synchronized to UTC. In addition, the NTP subnet is
Haberman & Mills Informational [Page 4]
RFC 5906 NTPv4 Autokey June 2010
hierarchical by nature, so time and trust flow from the primary
servers at the root through secondary servers to the clients at the
leaves.
A client can claim authentic to dependent applications only if all
servers on the path to the primary servers are bona fide authentic.
In order to emphasize this requirement, in this memo, the notion of
"authentic" is replaced by "proventic", an adjective new to English
and derived from "provenance", as in the provenance of a painting.
Having abused the language this far, the suffixes fixable to the
various derivatives of authentic will be adopted for proventic as
well. In NTP, each server authenticates the next-lower stratum
servers and proventicates (authenticates by induction) the lowest
stratum (primary) servers. Serious computer linguists would
correctly interpret the proventic relation as the transitive closure
of the authentic relation.
It is important to note that the notion of proventic does not
necessarily imply the time is correct. An NTP client mobilizes a
number of concurrent associations with different servers and uses a
crafted agreement algorithm to pluck truechimers from the population
possibly including falsetickers. A particular association is
proventic if the server certificate and identity have been verified
by the means described in this memo. However, the statement "the
client is synchronized to proventic sources" means that the system
clock has been set using the time values of one or more proventic
associations and according to the NTP mitigation algorithms.
Over the last several years, the IETF has defined and evolved the
IPsec infrastructure for privacy protection and source authentication
in the Internet. The infrastructure includes the Encapsulating
Security Payload (ESP) [RFC4303] and Authentication Header (AH)
[RFC4302] for IPv4 and IPv6. Cryptographic algorithms that use these
headers for various purposes include those developed for the PKI,
including various message digest, digital signature, and key
agreement algorithms. This memo takes no position on which message
digest or digital signature algorithm is used. This is established
by a profile for each community of users.
It will facilitate the discussion in this memo to refer to the
reference implementation available at http://www.ntp.org. It
includes Autokey as described in this memo and is available to the
general public; however, it is not part of the specification itself.
The cryptographic means used by the reference implementation and its
user community are based on the OpenSSL cryptographic software
library available at http://www.openssl.org, but other libraries with
equivalent functionality could be used as well. It is important for
Haberman & Mills Informational [Page 5]
RFC 5906 NTPv4 Autokey June 2010
distribution and export purposes that the way in which these
algorithms are used precludes encryption of any data other than
incidental to the construction of digital signatures.
The fundamental assumption in NTP about the security model is that
packets transmitted over the Internet can be intercepted by those
other than the intended recipient, remanufactured in various ways,
and replayed in whole or part. These packets can cause the client to
believe or produce incorrect information, cause protocol operations
to fail, interrupt network service, or consume precious network and
processor resources.
In the case of NTP, the assumed goal of the intruder is to inject
false time values, disrupt the protocol or clog the network, servers,
or clients with spurious packets that exhaust resources and deny
service to legitimate applications. The mission of the algorithms
and protocols described in this memo is to detect and discard
spurious packets sent by someone other than the intended sender or
sent by the intended sender, but modified or replayed by an intruder.
There are a number of defense mechanisms already built in the NTP
architecture, protocol, and algorithms. The on-wire timestamp
exchange scheme is inherently resistant to spoofing, packet-loss, and
replay attacks. The engineered clock filter, selection, and
clustering algorithms are designed to defend against evil cliques of
Byzantine traitors. While not necessarily designed to defeat
determined intruders, these algorithms and accompanying sanity checks
have functioned well over the years to deflect improperly operating
but presumably friendly scenarios. However, these mechanisms do not
securely identify and authenticate servers to clients. Without
specific further protection, an intruder can inject any or all of the
following attacks.
1. An intruder can intercept and archive packets forever, as well as
all the public values ever generated and transmitted over the
net.
2. An intruder can generate packets faster than the server, network,
or client can process them, especially if they require expensive
cryptographic computations.
3. In a wiretap attack, the intruder can intercept, modify, and
replay a packet. However, it cannot permanently prevent onward
transmission of the original packet; that is, it cannot break the
wire, only tell lies and congest it. Except in the unlikely
cases considered in Section 12, the modified packet cannot arrive
at the victim before the original packet, nor does it have the
server private keys or identity parameters.
Haberman & Mills Informational [Page 6]
RFC 5906 NTPv4 Autokey June 2010
4. In a man-in-the-middle or masquerade attack, the intruder is
positioned between the server and client, so it can intercept,
modify, and replay a packet and prevent onward transmission of
the original packet. Except in unlikely cases considered in
Section 12, the middleman does not have the server private keys.
The NTP security model assumes the following possible limitations.
1. The running times for public key algorithms are relatively long
and highly variable. In general, the performance of the time
synchronization function is badly degraded if these algorithms
must be used for every NTP packet.
2. In some modes of operation, it is not feasible for a server to
retain state variables for every client. It is however feasible
to regenerated them for a client upon arrival of a packet from
that client.
3. The lifetime of cryptographic values must be enforced, which
requires a reliable system clock. However, the sources that
synchronize the system clock must be cryptographically
proventicated. This circular interdependence of the timekeeping
and proventication functions requires special handling.
4. Client security functions must involve only public values
transmitted over the net. Private values must never be disclosed
beyond the machine on which they were created, except in the case
of a special trusted agent (TA) assigned for this purpose.
Unlike the Secure Shell (SSH) security model, where the client must
be securely authenticated to the server, in NTP, the server must be
securely authenticated to the client. In SSH, each different
interface address can be bound to a different name, as returned by a
reverse-DNS query. In this design, separate public/private key pairs
may be required for each interface address with a distinct name. A
perceived advantage of this design is that the security compartment
can be different for each interface. This allows a firewall, for
instance, to require some interfaces to authenticate the client and
others not.
3. Approach
The Autokey protocol described in this memo is designed to meet the
following objectives. In-depth discussions on these objectives is in
the web briefings and will not be elaborated in this memo. Note that
here, and elsewhere in this memo, mention of broadcast mode means
multicast mode as well, with exceptions as noted in the NTP software
documentation [RFC5905].
Haberman & Mills Informational [Page 7]
RFC 5906 NTPv4 Autokey June 2010
1. It must interoperate with the existing NTP architecture model and
protocol design. In particular, it must support the symmetric
key scheme described in [RFC1305]. As a practical matter, the
reference implementation must use the same internal key
management system, including the use of 32-bit key IDs and
existing mechanisms to store, activate, and revoke keys.
2. It must provide for the independent collection of cryptographic
values and time values. An NTP packet is accepted for processing
only when the required cryptographic values have been obtained
and verified and the packet has passed all header sanity checks.
3. It must not significantly degrade the potential accuracy of the
NTP synchronization algorithms. In particular, it must not make
unreasonable demands on the network or host processor and memory
resources.
4. It must be resistant to cryptographic attacks, specifically those
identified in the security model above. In particular, it must
be tolerant of operational or implementation variances, such as
packet loss or disorder, or suboptimal configurations.
5. It must build on a widely available suite of cryptographic
algorithms, yet be independent of the particular choice. In
particular, it must not require data encryption other than that
which is incidental to signature and cookie encryption
operations.
6. It must function in all the modes supported by NTP, including
server, symmetric, and broadcast modes.
4. Autokey Cryptography
Autokey cryptography is based on the PKI algorithms commonly used in
the Secure Shell and Secure Sockets Layer (SSL) applications. As in
these applications, Autokey uses message digests to detect packet
modification, digital signatures to verify credentials, and public
certificates to provide traceable authority. What makes Autokey
cryptography unique is the way in which these algorithms are used to
deflect intruder attacks while maintaining the integrity and accuracy
of the time synchronization function.
Autokey, like many other remote procedure call (RPC) protocols,
depends on message digests for basic authentication; however, it is
important to understand that message digests are also used by NTP
when Autokey is not available or not configured. Selection of the
digest algorithm is a function of NTP configuration and is
transparent to Autokey.
Haberman & Mills Informational [Page 8]
RFC 5906 NTPv4 Autokey June 2010
The protocol design and reference implementation support both 128-bit
and 160-bit message digest algorithms, each with a 32-bit key ID. In
order to retain backwards compatibility with NTPv3, the NTPv4 key ID
space is partitioned in two subspaces at a pivot point of 65536.
Symmetric key IDs have values less than the pivot and indefinite
lifetime. Autokey key IDs have pseudo-random values equal to or
greater than the pivot and are expunged immediately after use.
Both symmetric key and public key cryptography authenticate as shown
in Figure 1. The server looks up the key associated with the key ID
and calculates the message digest from the NTP header and extension
fields together with the key value. The key ID and digest form the
message authentication code (MAC) included with the message. The
client does the same computation using its local copy of the key and
compares the result with the digest in the MAC. If the values agree,
the message is assumed authentic.
+------------------+
| NTP Header and |
| Extension Fields |
+------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Message Authentication Code |
\|/ \|/ + (MAC) +
******************** | +-------------------------+ |
* Compute Hash *<----| Key ID | Message Digest | +
******************** | +-------------------------+ |
| +-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+
\|/ \|/
+------------------+ +-------------+
| Message Digest |------>| Compare |
+------------------+ +-------------+
Figure 1: Message Authentication
Autokey uses specially contrived session keys, called autokeys, and a
precomputed pseudo-random sequence of autokeys that are saved in the
autokey list. The Autokey protocol operates separately for each
association, so there may be several autokey sequences operating
independently at the same time.
+-------------+-------------+--------+--------+
| Src Address | Dst Address | Key ID | Cookie |
+-------------+-------------+--------+--------+
Figure 2: NTPv4 Autokey
Haberman & Mills Informational [Page 9]
RFC 5906 NTPv4 Autokey June 2010
An autokey is computed from four fields in network byte order as
shown in Figure 2. The four values are hashed using the MD5
algorithm to produce the 128-bit autokey value, which in the
reference implementation is stored along with the key ID in a cache
used for symmetric keys as well as autokeys. Keys are retrieved from
the cache by key ID using hash tables and a fast lookup algorithm.
For use with IPv4, the Src Address and Dst Address fields contain 32
bits; for use with IPv6, these fields contain 128 bits. In either
case, the Key ID and Cookie fields contain 32 bits. Thus, an IPv4
autokey has four 32-bit words, while an IPv6 autokey has ten 32-bit
words. The source and destination addresses and key ID are public
values visible in the packet, while the cookie can be a public value
or shared private value, depending on the NTP mode.
The NTP packet format has been augmented to include one or more
extension fields piggybacked between the original NTP header and the
MAC. For packets without extension fields, the cookie is a shared
private value. For packets with extension fields, the cookie has a
default public value of zero, since these packets are validated
independently using digital signatures.
There are some scenarios where the use of endpoint IP addresses may
be difficult or impossible. These include configurations where
network address translation (NAT) devices are in use or when
addresses are changed during an association lifetime due to mobility
constraints. For Autokey, the only restriction is that the address
fields that are visible in the transmitted packet must be the same as
those used to construct the autokey list and that these fields be the
same as those visible in the received packet. (The use of
alternative means, such as Autokey host names (discussed later) or
hashes of these names may be a topic for future study.)
Haberman & Mills Informational [Page 10]
RFC 5906 NTPv4 Autokey June 2010
+-----------+-----------+------+------+ +---------+ +-----+------+
|Src Address|Dst Address|Key ID|Cookie|-->| | |Final|Final |
+-----------+-----------+------+------+ | Session | |Index|Key ID|
| | | | | Key ID | +-----+------+
\|/ \|/ \|/ \|/ | List | | |
************************************* +---------+ \|/ \|/
* COMPUTE HASH * *******************
************************************* *COMPUTE SIGNATURE*
| Index n *******************
\|/ |
+--------+ |
| Next | \|/
| Key ID | +-----------+
+--------+ | Signature |
Index n+1 +-----------+
Figure 3: Constructing the Key List
Figure 3 shows how the autokey list and autokey values are computed.
The key IDs used in the autokey list consist of a sequence starting
with a random 32-bit nonce (autokey seed) greater than or equal to
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.
The first 32 bits of the result in network byte order become the next
key ID. The MD5 hash of the autokey is the key value saved in the
key cache along with the key ID. The first 32 bits of the key become
the key ID for the next autokey assigned index 1.
Operations continue to generate the entire list. It may happen that
a newly generated key ID is less than the pivot or collides with
another one already generated (birthday event). When this happens,
which occurs only rarely, the key list is terminated at that point.
The lifetime of each key is set to expire one poll interval after its
scheduled use. In the reference implementation, the list is
terminated when the maximum key lifetime is about one hour, so for
poll intervals above one hour, a new key list containing only a
single entry is regenerated for every poll.
Haberman & Mills Informational [Page 11]
RFC 5906 NTPv4 Autokey June 2010
+------------------+
| NTP Header and |
| Extension Fields |
+------------------+
| |
\|/ \|/ +---------+
**************** +--------+ | Session |
* COMPUTE HASH *<---| Key ID |&17.5. Security Requirements for Clients
For the Get-Notifications operation defined in this document, the
same client conformance requirements apply for supporting and using
Client Authentication, Server Authentication, and Operation Privacy
as stated in [RFC2910], section 8, for all IPP operations.
18. Description of Base IPP Documents (Informative)
The base set of IPP documents includes the following:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementer's Guide [RFC3196]
Mapping between LPD and IPP Protocols [RFC2569]
"Design Goals for an Internet Printing Protocol" takes a broad look
at distributed printing functionality, and it enumerates real-life
scenarios that help clarify the features that need to be included in
a printing protocol for the Internet. It identifies requirements for
three types of users: end users, operators, and administrators. It
calls out a subset of end user requirements that are satisfied in
IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator operations have
been added to IPP/1.1.
"Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol" describes IPP from a high-level view, defines a
roadmap for the various documents that form the suite of IPP
specification documents, and gives background and rationale for the
IETF working group's major decisions.
"Internet Printing Protocol/1.1: Model and Semantics" describes a
simplified model with abstract objects, their attributes, and their
operations that are independent of encoding and transport. It
introduces a Printer and a Job object. The Job object optionally
supports multiple documents per Job. It also addresses security,
internationalization, and directory issues.
"Internet Printing Protocol/1.1: Encoding and Transport" is a formal
mapping of the abstract operations and attributes defined in the
model document onto HTTP/1.1 [RFC2616]. It defines the encoding
rules for a new Internet MIME media type called "application/ipp".
This document also defines the rules for transporting over HTTP a
message body whose Content-Type is "application/ipp". This document
defines the 'ipp' scheme for identifying IPP printers and jobs.
Herriot, et al. Standards Track [Page 28]
RFC 3996 IPP: The 'ippget' Delivery Method March 2005
"Internet Printing Protocol/1.1: Implementer's Guide" gives insight
and advice to implementers of IPP clients and IPP objects. It is
intended to help them understand IPP/1.1 and some of the
considerations that may assist them in the design of their client
and/or IPP object implementations. For example, a typical order of
processing requests is given, including error checking. Motivation
for some of the specification decisions is also included.
"Mapping between LPD and IPP Protocols" gives some advice to
implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations.
19. Contributors
Carl Kugler and Harry Lewis contributed the basic idea of in-band
"smart polling" coupled with multiple responses for a single
operation on the same connection, with one response for each event as
it occurs. Without their continual persuasion, we would not have
arrived at this Delivery Method specification and would not have been
able to agree on a single REQUIRED Delivery Method for IPP.
Carl Kugler
IBM Corporation
6300 Diagonal Highway
Boulder, CO 80301
EMail: kugler@us.ibm.com
Herriot, et al. Standards Track [Page 29]
RFC 3996 IPP: The 'ippget' Delivery Method March 2005
Authors' Addresses
Robert Herriot
Global Workflow Solutions
706 Colorado Ave.
Palo Alto, CA 94303
Phone: 650-324-4000
EMail: bob@herriot.com
Thomas N. Hastings
Xerox Corporation
710 S Aviation Blvd. ESAE 242
El Segundo CA 90245
Phone: 310-333-6413
Fax: 310-333-6342
EMail: hastings@cp10.es.xerox.com
Harry Lewis
IBM Corporation
6300 Diagonal Hwy
Boulder, CO 80301
Phone: (303) 924-5337
EMail: harryl@us.ibm.com
Herriot, et al. Standards Track [Page 30]
RFC 3996 IPP: The 'ippget' Delivery Method March 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Herriot, et al. Standards Track [Page 31]