From: Daniel Kutchin (daniel@kutchin.com)
Date: Mon Jan 05 2009 - 03:52:47 ARST
> maybe the RFC has more insight...haven't read through it in quite a while.
It wasn't apparent to me that RFC1305 mentioned trusted keys
http://www.faqs.org/rfcs/rfc1305.html
Accept it as given: include the "ntp trusted-key #" command on the client
side
when configuring NTP-auth.
--Daniel
-----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Jason Madsen Sent: Sonntag, 4. Januar 2009 09:58 To: Dale Shaw Cc: GS Subject: Re: NTP Server
maybe the RFC has more insight...haven't read through it in quite a while. I've just always remembered and accepted that you need the "trusted-key" command on NTP clients, but it is a rather strange configuration if you ask me. Why should you specify the key you want your server to authenticate to via "ntp server x.x.x.x key x", but yet you still have to specify that key as trusted...weird.
I just did a quick test and found that with a key created and specified in an NTP server x.x.x.x key x statement as long as the server has that same key created it will authenticate with the client, but it will not sync time unless the client also has the trusted key statement.
R1 (acting as NTP Server) ntp master 5 ntp authentication-key 1 md5 key1
R2 (client) ntp authenticate ntp authentication-key 1 md5 key1 ntp server 1.1.1.1 key 1
show ntp association detail output: ..."*authenticated*"..."*insane*"..."* invalid*"
ntp trusted-key 1
show ntp association detail output now reveals..."*authenticated*"..."*sane* "..."*valid*"
Jason
On Sun, Jan 4, 2009 at 1:15 AM, Jason Madsen <madsen.jason@gmail.com> wrote:
> Hi Dale, > > With NTP Authentication it's best to remember that the client is the one > with the authentication requirement of the server and not the other way > around. On the client you can specify multiple authentication keys. It's > the trusted key statement that specifies which of your authentication keys > to use...not really sure why you'd want to have multiple keys listed just to > "use" / trust one of them though unless it helps facilitate a more seamless > key change. > > Jason > > On Sun, Jan 4, 2009 at 12:59 AM, Dale Shaw <dale.shaw@gmail.com> wrote: > >> Hi, >> >> On Sun, Jan 4, 2009 at 1:38 PM, Jared Scrivener <jscrivener@ipexpert.com> >> wrote: >> > Nope. For what you want to do, you need: >> > >> *snip* >> >> Hmm.. At first, I interpreted this description of 'ntp trusted-key' (a >> NTP-process level command, not per-peer/server) to mean that an IOS >> NTP client configured for authentication requires that all of its time >> sources present the same key -- i.e. every time source must be >> configured with the same key as the client, and that once client-side >> authentication enabled, all time sources must offer up a key. >> >> Then I realised you can enter multiple "trusted-key" commands. >> >> *phew* >> >> What's not clear to me, is why the 'trusted-key' command is required >> at all. Surely, like routing protocol authentication, as long as the >> NTP peers (client, server, peer, whatever) have matching keys, the >> light should turn green. I don't see what value 'trusted-key' provdes. >> Anyone? >> >> Lastly, am I the only one that thinks the documentation of the NTP >> implementation in IOS leaves a LOT to be desired? >> >> cheers, >> Dale >> >> >> Blogs and organic groups at http://www.ccie.net >> >> _______________________________________________________________________ >> Subscription information may be found at: >> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:36 ARST