Authentication of time servers behind NAT / Firewall - NTP

This is a discussion on Authentication of time servers behind NAT / Firewall - NTP ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Authentication of time servers behind NAT / Firewall

  1. Authentication of time servers behind NAT / Firewall

    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.


  2. Re: Authentication of time servers behind NAT / Firewall

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


  3. Re: Authentication of time servers behind NAT /Firewall

    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


  4. Re: Authentication of time servers behind NAT / Firewall

    In article <1172677173.595394.195670@s48g2000cws.googlegroups. com>,
    "Vanya" 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.


+ Reply to Thread