From: Michael (mamiller2@comcast.net)
Date: Tue May 02 2006 - 06:21:16 ART
Yes, very nicely said Petr. Thanks for the confirmation on this NTP
authentication. One last Cisco NTP anomaly though - I seem to find no
difference with key tag on the peer statement vs. without key tag. (CR4 vs.
CR5) Comments?
See config snip below:
P1R1-2511#show run | inc ntp
ntp authentication-key 1 md5 0941571D100812 7
ntp authentication-key 3 md5 00070155 7
ntp authenticate
ntp trusted-key 1
ntp trusted-key 3
ntp clock-period 17180210
ntp peer 10.10.3.3 key 3
ntp peer 10.10.4.4 key 1
ntp peer 10.10.5.5 key 1
ntp peer 10.10.6.6 key 1
ntp peer 10.10.7.7 key 1
ntp peer 10.10.8.8 key 1
ntp peer 10.10.9.9 key 1
ntp server 66.90.78.182 prefer
P1R1-2511#
CR4#show run | inc ntp
ntp authentication-key 1 md5 12141C031B0609 7
ntp authenticate
ntp trusted-key 1
ntp clock-period 17179921
ntp source Loopback0
ntp peer 10.10.1.1 key 1 prefer
CR4#
CR5#show run | inc ntp
ntp authentication-key 1 md5 151F12180D272E 7
ntp authenticate
ntp trusted-key 1
ntp clock-period 17208757
ntp source Loopback0
ntp peer 10.10.1.1 prefer
CR5#
Michael
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Schulz, Dave
Sent: Monday, May 01, 2006 8:07 AM
To: Petr Lapukhov
Cc: Luis Rueda; Michael; ccielab
Subject: RE: NTP authentication
Nice explanation, Petr. So, then you are saying the keys must
agree...not only in the key itself, but also the number.
Dave Schulz,
Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com%20>
________________________________
From: Petr Lapukhov [mailto:petrsoft@gmail.com]
Sent: Monday, May 01, 2006 9:58 AM
To: Schulz, Dave
Cc: Luis Rueda; Michael; ccielab
Subject: Re: NTP authentication
Guys,
I think I got some logic behind this..
Okay, so what does that mean :))
First of all, all authenticated packets carry key numbers with them.
Next:
1) We have "active" and "passive" modes. Active mode (peer active,
client)
deduces key from "key" parameter in command line (ntp peer key,
ntp server key).
Passive mode deduces key number from incoming "active" packet,
and look up key-string in it's keyring. E.g when server receives a query
with key, it replies with the key-string under same key-number
from it's key-ring.
2) As i get it, ony "synchronization" packets needs to be authenticated.
That is, only packets that can change our clock needs to be
authenticated.
So, "ntp server" is not required to check authentication in query
packet.
It does something else, though. More on that later.
3) Authentication is not enabled until we enter "ntp authenticate"
command.
When "ntp authenticate'" is turend on, we inspect every "sync" packet
to get key number. We then look that key-string by it's number in our
key ring,
verify md5 checksum, and if the key is trusted, we consider packet to be
authenticated.
4) As i said, when a "passive" router receives packet from "active"
neighbor,
it looks up it key ring. Next, if this is "sync" packet, we need to
validate it.
That is, key needs to be trusted, and md5 sum must match.
If this is a "query" packet, we simple reply with "sync" packet, and
include key
from our key-ring in reply, looking that key by key-number from packet.
That's all i get :) By the way, I discovered that we dont need to enable
"ntp authentication" on server either. It still does respond with
appropriate keys.
HTH
Petr
2006/5/1, Schulz, Dave <DSchulz@dpsciences.com>:
That is what I was thinking, but after doing the debugs....I didn't see
this. I'll run it again.
Dave Schulz,
Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com%20>
________________________________
From: Petr Lapukhov [mailto:petrsoft@gmail.com]
Sent: Monday, May 01, 2006 9:05 AM
To: Schulz, Dave
Cc: Luis Rueda; Michael; ccielab
Subject: Re: NTP authentication
Actually, if you do a "debug ntp authentication" you will see,
that NTP packets carry key number with them :))
I try to dig that topic, since information on NTP is scarse and vague
:))
Petr
2006/5/1, Schulz, Dave <DSchulz@dpsciences.com >:
Luis -
Do you have a configuration where this worked successfully? I labbed it
up and could only get the authentication to work if the key #'s are the
same.
Dave Schulz,
Email: dschulz@dpsciences.com
-----Original Message-----
From: nobody@groupstudy.com [mailto: nobody@groupstudy.com
<mailto:nobody@groupstudy.com> ] On Behalf Of
Luis Rueda
Sent: Sunday, April 30, 2006 4:09 PM
To: Michael; ccielab
Subject: RE: NTP authentication
If you mean like OSPF that you have to use the same number on both ? I'm
pretty sure not. I have used them with different numbers and they all
work.
Diferent numbers are supported because maybe you have different servers
with different passwords....
Hope it helps.
Luis
-----Mensaje original-----
De: nobody@groupstudy.com [mailto: nobody@groupstudy.com
<mailto:nobody@groupstudy.com> ] En nombre de
Michael
Enviado el: Sunday, April 30, 2006 3:05 PM
Para: ccielab
Asunto: RE: NTP authentication
Hi Groupstudy,
Is there anyone that can please comment / help on this subject?
Thanks in advance,
Michael
_____
From: Michael [mailto: mamiller2@comcast.net
<mailto:mamiller2@comcast.net> ]
Sent: Sunday, April 30, 2006 2:43 AM
To: ccielab (ccielab@groupstudy.com)
Subject: NTP authentication
Hey all~
Can anyone confirm that ntp key id numbers also need to be the same for
peers using md5 authentication? I have been experimenting with
different configurations and this all that seems to work.
P1R1-2511#show run | inc ntp
ntp authentication-key 1 md5 0941571D100812 7
ntp authentication-key 3 md5 00070155 7
ntp authenticate
ntp trusted-key 1
ntp trusted-key 3
ntp trusted-key 6
ntp clock-period 17180181
ntp peer 10.10.3.3 key 3
ntp peer 10.10.4.4 key 1
ntp peer 10.10.5.5 key 1
ntp peer 10.10.6.6 key 1
ntp peer 10.10.7.7 key 1
ntp peer 10.10.8.8 key 1
ntp peer 10.10.9.9 key 1
ntp server 66.90.78.182
P1R1-2511#
CR3#show run | inc ntp
ntp authentication-key 3 md5 104D1B4A 7
ntp authenticate
ntp trusted-key 3
ntp clock-period 17208479
ntp source Loopback0
ntp peer 10.10.1.1 key 3 prefer
CR3#
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:20 ART