(so that the key will rotate every x number of days). No problem.
However, consider the following topology
Internet --- R1 --- R2 --- R3 --- Rn
We currently have R1 synchronizing NTP with an outside source, and all other devices synchronizing with R1. Makes sense as far as I can tell.
The problem is this: If R3 looses power, it forgets what time it is. If it doesn't know what time it is, it can't exchange routes with R2 (because it's trying to use the wrong key to authenticate). If it can't get the routes, it doesn't know how to get to R1 and it can't synchronize NTP. If it can't Sync NTP, it can't learn what time it is, etc...
I'm positive i'm not the first person that's wanted to do this... so what am I missing? I suppose I could point every device to it's upstream neighbor for NTP, but that seems messy. Also, I'd have to use the nearest neighbor interface for each of those associations (violating the rule of "use loopbacks for all control plane traffic). I could also just use static routes... or any number of other work arounds I can think of, but none of them seem like they're the "right" thing to do.
So what am I missing? How are you SUPPOSED to do it?
I'd have to lab this up, so what I'm saying is strictly a thought
You could put statics on all routers (R2 and R3) that lead to R1. Make them floating with a higher AD than 120 (RIPs AD). When the router reboots and loses its time, it can use the static route from R3 --> R2. R2, can then in turn use R2 ---> R1. Once you get your NTP association on R3, then it can update the time, RIP can converged, and you should be good to go...