Share via

4 Protocol Examples

  • Article

The following example shows a successful authenticated time synchronization sequence using the NTP Authentication Extensions between a client and a server.

Note that the following packet diagrams illustrate the entire NTP packet, not just the Authenticator field in the NTP Authentication Extensions. The NTP data format is defined in the base NTP protocol, as specified in [RFC1305] Appendix A. The Authenticator field related to the NTP Authentication Extensions is specified in section 2.2. The packet diagrams use fictitious values for the Key Identifier and Crypto-Checksum fields.

Message sequence

Figure 7: Message sequence

  1. The client waits for the client polling timer to expire.

  2. The client composes a Client NTP Request message. It sets the Key Identifier subfield of the extension part with the RID and the Key Selector value, and sets the Crypto-Checksum subfield to 0. The client sends the Client NTP Request message to the server.


    0


    1


    2


    3


    4


    5


    6


    7


    8


    9

    1
    0


    1


    2


    3


    4


    5


    6


    7


    8


    9

    2
    0


    1


    2


    3


    4


    5


    6


    7


    8


    9

    3
    0


    1

    LI

    VN

    Mode=3

    Stratum

    Poll Interval

    Precision

    Root Delay

    Root Dispersion

    Reference Clock Identifier

    Reference Timestamp

    ...

    Original Timestamp

    ...

    Receive Timestamp

    ...

    Transmit Timestamp

    ...

    0x00 0x35 0x7B 0x9D

    0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x00

    0x00 0x00 0x00 0x00

  3. After receiving the request, the server verifies that the received message size is 68 bytes. If it is not, the server either drops the request (if the message size does not equal 48 bytes) or treats it as an unauthenticated request (if the message size is 48 bytes). Assuming that the received message size is 68 bytes, the server extracts the RID from the received message. The server uses it to call the NetrLogonComputeServerDigest method (as specified in [MS-NRPC] section 3.5.4.8.2) to compute the crypto-checksums and select the crypto-checksum based on the most significant bit of the Key Identifier subfield from the received message, as specified in section 3.2.5. The server then sends a response to the client, setting the Key Identifier field to 0 and the Crypto-Checksum field to the computed crypto-checksum.


    0


    1


    2


    3


    4


    5


    6


    7


    8


    9

    1
    0


    1


    2


    3


    4


    5


    6


    7


    8


    9

    2
    0


    1


    2


    3


    4


    5


    6


    7


    8


    9

    3
    0


    1

    LI

    VN

    Mode=4

    Stratum

    Poll Interval

    Precision

    Root Delay

    Root Dispersion

    Reference Clock Identifier

    Reference Timestamp

    ...

    Original Timestamp

    ...

    Receive Timestamp

    ...

    Transmit Timestamp

    ...

    0x00 0x00 0x00 0x00

    0x5E 0xBD 0xA9 0x0E

    0xB2 0x35 0x54 0x9A

    0xB2 0xA8 0xB3 0x4F

    0x50 0x1D 0x62 0x20

  4. The client receives the response and, after it verifies that the message size is 68 bytes, computes the crypto-checksums, as specified in section 3.1.5. The client finds that one of the calculated crypto-checksums matches the crypto-checksum in the response. The response is, therefore, authenticated successfully, and the client synchronizes its time.