3.1.5.1 Authentication Request Behavior
The following diagram illustrates the client logic for generating a Client NTP Request or Client ExtendedAuthenticator NTP Request message with authentication.
Figure 2: Authentication request generation
If the ExtendedAuthenticatorSupported ADM element is false, the client MUST construct a Client NTP Request message. The Client NTP Request message length is 68 bytes. The client sets the Authenticator field of the Client NTP Request message as described in section 2.2.1, writing the least significant 31 bits of the RID value into the least significant 31 bits of the Key Identifier subfield of the authenticator, and then writing the Key Selector value into the most significant bit of the Key Identifier subfield.<12>
If the ExtendedAuthenticatorSupported ADM element is true, the client MUST construct a Client ExtendedAuthenticator NTP Request message. The Client ExtendedAuthenticator NTP Request message length is 120 bytes. The client sets the fields of the message as follows:
Key Identifier: MUST be set to the RID ADM element.
Reserved: MUST be set to zero.
Flags: MUST be set to zero if the Key Selector ADM element is 0; otherwise, the USE_OLDKEY_VERSION bit MUST be set.
ClientHashIDHints: MUST be set to NTLM_PWD_HASH.
SignatureHashID: MUST be set to zero.
Crypto-Checksum: MUST be set to zero.
The client SHOULD set the Mode field of the request to Symmetric Active if the client is a time source. The syntax and semantics for the Mode field of the Client NTP Request message are specified in [RFC1305] Appendix A.<13>
The client sends the Client NTP Request message to the server as it does in the base Network Time Protocol, which is described in [RFC1305] section 3.4.2.
The following diagram illustrates the client logic for processing a Server NTP Response or Server ExtendedAuthenticator NTP Response message received in response to a Client NTP Request or Client ExtendedAuthenticator NTP Request message, respectively, that requested authentication.<14>
Figure 3: Authentication response processing
The response message length MUST be either 68 or 120 bytes. If the message length does not meet this requirement, the authentication fails.
The client MUST ignore the Key Identifier subfield of either response message.
If the response message length is 68 bytes, the client MUST validate the response as a Server NTP Response message, as follows:
The client uses the NetrLogonComputeClientDigest method (as specified in [MS-NRPC] section 3.5.4.8.3) to compute crypto-checksums for the first 48 bytes of the Server NTP Response message, with the following input parameters:
ServerName MUST be set to NULL.
DomainName MUST be set to the value of the Trusted Domain element.
Message MUST refer to the first 48 bytes of the response message.
MessageSize MUST be set to 48.
The NetrLogonComputeClientDigest method computes two crypto-checksums using the pair of passwords associated with the trusted account.
If the response message length is 120 bytes, the client MUST validate the response as a Server ExtendedAuthenticator NTP Response message, as follows:
The client MUST compute the NTOWFv1 (as specified in [MS-NLMP] section 3.3.1) of the current machine password and the NTOWFv1 of the previous machine password.
The client invokes the checksum generation algorithm (section 3.1.5.5) with the following inputs:
Key: The NTOWFv1 of the current machine password.
Label: The ANSI string "sntp-ms".
Context: The RID ADM element.
Message: The first 48 bytes of the response message.
The client invokes the checksum generation algorithm (section 3.1.5.5) with the following inputs:
Key: The NTOWFv1 of the previous machine password.
Label: The ANSI string "sntp-ms".
Context: The RID ADM element.
Message: The first 48 bytes of the response message.
The client then uses the two checksums resulting from the previous two algorithm invocations to validate the message as specified in the paragraph that follows.
The client compares each computed crypto-checksum with the Crypto-Checksum subfield in the response message. If the Crypto-Checksum subfield matches any of the computed crypto-checksums, the authentication succeeds. Otherwise, the authentication fails. A client MUST compare all computed crypto-checksums before determining that the authentication has failed; however, it SHOULD NOT continue to compare crypto-checksums after it has determined that at least one of its computed crypto-checksums matches the Crypto-Checksum subfield.
If authentication succeeds, the client continues processing the response to synchronize time the same way it occurs in the base NTP protocol, which is described in [RFC1305] section 3.4.3.
If authentication fails, the response MUST be ignored, and the client MUST NOT perform time synchronization using the response.
The following state diagram illustrates updates to the client's state elements based on success or failure of message authentication. The state changes in this diagram are applicable regardless of which response message format was received (Server NTP Response or Server ExtendedAuthenticator NTP Response).
Note In authenticated NTP, all state transitions are triggered by timer expiry. On expiration of the client polling timer, an authenticated NTP client attempts an authenticated NTP exchange with the NTP server. Based on the success or failure of that attempt, it updates state elements and transitions to the next state. The labels on the following arcs indicate the trigger of authentication success or failure that causes transition to the next state. For each trigger of authentication success or failure, there is an implicit trigger of "Timer Expiry" because it is the expiration of the polling timer that causes an authentication attempt. The "Timer Expiry" label has been omitted from the following arcs for clarity. Also note that the state element assignments in the state boxes are carried out upon entry into the state, not on exit.
Figure 4: Client element updates