Appendix C. Authentication Issues

This appendix describes an optional authentication mechanism which can be used to verify the integrity of NTP messages and provide protection against message modification and replay attacks. The mechanism is based on the MD5 cryptographic hash function and uses a shared secret key between the peers. When authentication is enabled, an authenticator field containing a key identifier and message digest is appended to the NTP message.

The authentication mechanism provides the following security services:

1. Message Integrity: Ensures that the message has not been modified in transit.
2. Source Authentication: Verifies that the message originated from a legitimate peer possessing the shared secret key.
3. Replay Protection: When combined with the NTP timestamp mechanism, provides protection against replay attacks.

The authentication mechanism is optional and need not be implemented in all cases. However, when security is a concern, especially in environments where unauthorized time servers might inject false time information, the authentication mechanism provides an effective means of protection.

C.1. NTP Authentication Mechanism

The NTP authentication mechanism uses the MD5 cryptographic hash function to compute a message digest over the NTP message and a shared secret key. The message digest is appended to the NTP message in the authenticator field, along with a key identifier that specifies which key was used.

The authenticator field has the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Key Identifier                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         Message Digest                        |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key Identifier: This is a 32-bit unsigned integer that identifies the cryptographic key used to generate the message digest.

Message Digest: This is a 128-bit MD5 hash computed over the NTP message (up to but not including the authenticator field) and the shared secret key.

The shared secret keys are configured manually and stored in a key file accessible to the NTP daemon. Each key has a unique identifier and is represented as a 64-bit (8-octet) value. The format of the key is compatible with the DES encryption algorithm, although DES is not used directly in the authentication mechanism.

C.2. NTP Authentication Procedures

The authentication procedures are invoked during the transmit and receive operations. When authentication is enabled, the transmit procedure computes the message digest and appends the authenticator to the outgoing message. The receive procedure verifies the authenticator on incoming messages and sets the authenticated bit accordingly.

C.2.1. Encrypt Procedure

The encrypt procedure is called from the transmit procedure when authentication is enabled. It computes the MD5 message digest and appends the authenticator to the NTP message.

begin encrypt procedure
    if (peer.authenable = 0) exit;           /* authentication disabled */
    
    /* Append key identifier */
    pkt.keyid <- peer.hostkeyid;
    
    /* Compute MD5 digest over message and key */
    digest <- MD5(message || key[peer.hostkeyid]);
    
    /* Append digest to message */
    pkt.check <- digest;
    
end encrypt procedure

The MD5 computation is performed over the entire NTP message (including the NTP header and timestamp fields) followed by the shared secret key. The resulting 128-bit digest is appended to the message in the authenticator field.

C.2.2. Decrypt Procedure

The decrypt procedure is called from the receive procedure to verify the authenticator on incoming messages. It recomputes the message digest using the indicated key and compares it with the digest in the received message.

begin decrypt procedure
    if (peer.authenable = 0) begin           /* authentication disabled */
        peer.authentic <- 1;
        exit;
    endif
    
    /* Check if key identifier is valid */
    if (pkt.keyid not in sys.keys) begin
        peer.authentic <- 0;
        exit;
    endif
    
    /* Extract received digest */
    received_digest <- pkt.check;
    
    /* Compute expected digest */
    expected_digest <- MD5(message || key[pkt.keyid]);
    
    /* Compare digests */
    if (received_digest = expected_digest)
        peer.authentic <- 1;
    else
        peer.authentic <- 0;
        
end decrypt procedure

If the authentication succeeds (digests match), the authenticated bit (peer.authentic) is set to 1, indicating that the message originated from a legitimate peer. If authentication fails, the bit is set to 0, and depending on the configuration, the message may be rejected.

C.2.3. Control-Message Procedures

When the NTP control messages described in Appendix B are implemented with authentication, the same authentication mechanism is used. The encrypt and decrypt procedures are applied in the same manner as for regular NTP messages.

For control messages, authentication is particularly important because these messages can be used to read and modify internal variables of the NTP implementation. Without authentication, an attacker could potentially disrupt the time synchronization or extract sensitive information.

Implementation Considerations

The following considerations should be taken into account when implementing the authentication mechanism:

1. Key Management: The shared secret keys must be configured manually on all peers that will use authentication. Keys should be changed periodically to maintain security.

2. Performance Impact: Computing the MD5 digest adds processing overhead to each message. On systems with limited CPU resources, this may affect timing accuracy. Implementations should consider caching digest computations or using hardware acceleration when available.

3. Timestamp Precision: The encryption operation should be performed as close as possible to the actual message transmission to minimize the impact on timestamp accuracy. Some implementations precompute the digest offset to compensate for the encryption delay.

4. Key Identifier Space: The 32-bit key identifier space allows for a large number of keys, facilitating key rotation and supporting multiple authentication domains.

5. Backward Compatibility: Messages with and without authentication can coexist. Peers that do not support authentication simply ignore the authenticator field.

6. Security Limitations: The authentication mechanism protects against message modification and replay attacks but does not provide encryption of the message content. The time information itself is transmitted in clear text.

The authentication mechanism described here provides a practical balance between security and performance for most NTP deployments. For environments requiring stronger security guarantees, additional measures such as IPsec or other transport-layer security mechanisms may be appropriate.