[ipxe-devel] SSL certificate validation and NTP

[Terry Burton]

On 22 March 2012 17:37, Michael Brown <mbrown at fensystems.co.uk> wrote:
> On Thursday 22 Mar 2012 17:05:19 Phil Martin wrote:
>> I've been experimenting with the HTTPS functions in iPXE over the last
>> day or so. Since you've enabled the checking of the certificate
>> validity period, will you be including some sort of NTP functionality
>> to set the system clock before checking the certificate? Currently, if
>> for some reason a machine has lost time (or doesn't have a CMOS clock
>> at all), it will fail to boot over HTTPS as the certificate won't yet
>> be valid, according to the machine's clock at least. Perhaps it could
>> use the NTP servers at pool.ntp.org by default, but be overridden if
>> option 42 was specified in DHCP?
>
> Wouldn't that make the validity period check essentially worthless, since a
> man-in-the-middle attacker could simply fake the current NTP time?  How can we
> do this securely?

Hi Michael, Phil,

NTP has a concept of authentication using shared secrets that can be
used for this. If a client sends an NTP request along with AUTH data
using a shared-key that the server recognises and can validate then
the response will be sent with corresponding AUTH data that the client
can validate.

Example below...


All the best,

Terry


----

Server ntp.conf:

enable auth
keys /etc/ntp.keys
trustedkey 3
...


Client/server ntp.keys:

3 M ezAPNJFR


For example:

17:52:28.356267 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 96)
    client.123 > server.123: [bad udp cksum 27a5!] NTPv4, length 68
        Client, Leap indicator:  (0), Stratum 14 (secondary
reference), poll 6s, precision -23
        Root Delay: 0.000000, Root dispersion: 7.947509, Reference-ID:
127.127.1.0
          Reference Timestamp:  3542028747.356243461 (2012/03/29 17:52:27)
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3542028748.356236875 (2012/03/29 17:52:28)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3542028748.356236875
(2012/03/29 17:52:28)
        Key id: 50331648
        Authentication: 69ea2a997193392be59ecd1321bba405
17:52:28.356495 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto
UDP (17), length 96)
    server.123 > client.123: [udp sum ok] NTPv4, length 68
        Server, Leap indicator:  (0), Stratum 3 (secondary reference),
poll 6s, precision -20
        Root Delay: 0.010879, Root dispersion: 0.073623, Reference-ID: upstream
          Reference Timestamp:  3542027891.402116894 (2012/03/29 17:38:11)
          Originator Timestamp: 3542028748.356236875 (2012/03/29 17:52:28)
          Receive Timestamp:    3542028748.355720996 (2012/03/29 17:52:28)
          Transmit Timestamp:   3542028748.355789840 (2012/03/29 17:52:28)
            Originator - Receive Timestamp:  -0.000515884
            Originator - Transmit Timestamp: -0.000447024
        Key id: 50331648
        Authentication: 0349f16cd553156971b4c6d9f5274205