From: Jason Madsen (madsen.jason@gmail.com)
Date: Sun Jan 04 2009 - 06:57:36 ARST
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