NTP authentication using kerberos

[Matthew Seaman]

Da Rock wrote:
> This may be a stupid question, and/or a chicken and egg conundrum:
> 
> Is it possible to use kerberos in authentication with an ntp server?
> 
> Here is my reasoning for this (and please correct any wrong assumptions
> I have here): In the handbook regarding kerberos (and nearly every other
> reliable source) kerberos is all or nothing- every service needs to be
> included or it is not as secure as it should be. On the other hand,
> there are problems with using kerberos if the time is not synchronised,
> so use ntp.
> 
> And so far I have only found simple key authentication similar to dhcp
> and dns to authenticate ntp with. But if kerberos provides keys then
> this could be simpler, yes?
> 
> Once I have worked through this, I'd like to multicast ntp, but I think
> I've got that sewn up already, unless anybody has some advice on this?
> I'll probably be using the 239 subnet rather than 224 if that is not an
> issue.
> 
> One more thing- if ntp uses the same sort of authentication as dhcp and
> dns, is there a way to extend this kerberos setup (if it is possible
> with ntp) to dhcp and dns on my local network? Or am I just getting too
> ambitious with everything here? :)

NTP doesn't support Kerberos style authentication.  It has it's own
cryptographically secured authentication mechanisms.  See ntp-keygen(8)
However, doing the full-blown crypto security thing is generally over the
top for securing simple clients.  It's good for NTP servers, especially
if you have your own heirarchy of Stratum 1 and perhaps Stratum 2 servers 
and accurate timing really is critical for you.  Remember you need at least 
three independent time sources -- preferably four to give you some 
resilience -- in order to be able to detect if the clock has gone wonky on 
any one of your servers.

For supplying a time signal by multicast or broadcast, you have to enable
key based authentication on all the servers and clients.  The basic method
just uses what is effectively an 8 character random string as a password.
This is usually sufficient if all your client machines are on protected back end networks and taking a time signal from NTP servers entirely in 
your control.  You need to protect the ntp-keys file from exposure -- I 
like to create a root-only directory to hold it:

	mkdir /etc/ntp
        mv ntp.keys /etc/ntp/
        chown -R root:wheel /etc/ntp
        chmod -R go-rwx /etc/ntp

For dhcp and DNS security -- there are all sorts of mechanisms for
authenticating and securing transactions between such servers.  In the
case of DNS, I suggest you read up on 'Tsig' (Transaction Signatures)
and DNSSEC -- this is a good resource: 

http://www.dnssec.net/why-deploy-dnssec

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20080918/18a3a730/signature.pgp