NTP authentication using kerberos

[Da Rock]

On Thu, 2008-09-18 at 08:28 +0100, Matthew Seaman wrote:
> 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
> 

Well thats good to know. I'm already using those methods on the dns and
dhcp server, seems isc have their own methods in security so I'll just
have to stick with those for ntp too.

For reference, how does this affect the whole kerberos setup if these
services are not in the kerberos system? Does it introduce a security
flaw? Any experts out there that can clarify this point? Or should I
just run these particular services outside the kerberos system (ie on a
separate machine not kerberos secured)?