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.

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.
> 

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?
> 

As Dave Mills will tell you the current authentication scheme uses the
IP address so you cannot use NAT'd addresses.

Consider creating an NTP server on your firewall that does not need a
NAT'd addresses and then point your internal ntp servers at that.

Danny

> 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.

Love to though it's been a few years since I've been to Italy.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

In article <1172677173.595394.195670@s48g2000cws.googlegroups.com>,
 "Vanya" <forrester.rome@gmail.com> writes:
>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).

Do you really want your mail servers behind a NAT box?  I'd
expect you would want them on a DMZ and that would also solve
your NTP problems.

If all your traffic goes through a single NAT box, then
all your servers get block/black listed when one of your
PCs gets infected or any of a zillion other problems
causes spam/abuse to emit from your NAT box.

Has anybody tried tunneling NTP traffic?


-- 
These are my opinions, not necessarily my employer's.  I hate spam.