Vanya, My intent in writing the proposed specification was to leave room for an association identifier, but not specify explicit means at this time. A natural way to do this is a Diffie-Hellman exchange to develop a shared secret and use that instead of the addresses. Of course, the original symmetric (private) key continues to work.
Dave Vanya wrote: > Wondering what others might have to say about the possibility of > authenticating a NTP server from behind a NAT/Firewall. We are setting > up a system of certified email for cities in Italy. The authorities > want us to show that the servers in the cluster handling the email > traffic are communicating in an authenticated fashion with the local > NTP servers (located in Pisa). > > As Mills, et al point out in the ietf drafts > > "NPT associations are identified by the endpoint IP addresses ... > natural approach is to authenticated associations using these values. > For scenarios where this is not possible, an optional identification > value can be used instead of the endpoint IP addresses. The Parameter > Negotiation message contains an options to specify these data; > however, the format, encoding and use of this options are not > specified in this memorandum." > > Has any work been done on this issue? As it stands it seems we have to > use a public IP address to authenticate using autokey with the NTP > server in Pisa (using a NAT'ed address the authentication obviously > fails). Anyway getting around this? > > Thanks. > > Be glad to offer a plate of pasta and a glass of wine (at one of our > restaurants here in Rome) to anyone able to help us. > _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
