Re: NTP authentication using kerberos
- From: Matthew Seaman <m.seaman@xxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 18 Sep 2008 08:28:51 +0100
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
Attachment:
signature.asc
Description: OpenPGP digital signature
- Follow-Ups:
- Re: NTP authentication using kerberos
- From: Da Rock
- Re: NTP authentication using kerberos
- References:
- NTP authentication using kerberos
- From: Da Rock
- NTP authentication using kerberos
- Prev by Date: Re: bash shell colors
- Next by Date: Re: Auto blacklist ssh connections ...
- Previous by thread: NTP authentication using kerberos
- Next by thread: Re: NTP authentication using kerberos
- Index(es):
Relevant Pages
|
