Autokey Certificate Update - NTP

This is a discussion on Autokey Certificate Update - NTP ; Hi, The advice on the Autokey configuration page, http://support.ntp.org/bin/view/Supp...iguringAutokey is to update the server and client key/certificate monthly since the cert is only good for 1 year. When I run the cert update commands provided on the link above, a ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Autokey Certificate Update

  1. Autokey Certificate Update

    Hi,
    The advice on the Autokey configuration page,
    http://support.ntp.org/bin/view/Supp...iguringAutokey
    is to update the server and client key/certificate monthly since the
    cert is only good for 1 year. When I run the cert update commands
    provided on the link above, a new cert and link is generated and
    Autokey NTP continues to run fine. However, it does not appear that
    NTP actually uses the new cert until it is restarted. I determined
    this by examining the output of the ntpq -c "rv 0 cert" command also
    provided in the link above.

    I want to know if the new cert is used only after a restart because
    otherwise we might think the certs are being updated only to find NTP
    Autokey broken 1 year later when the cert in use expires. So is the
    real procedure to update the cert then restart NTP on a periodic
    basis? Any way to tell NTP to pickup the new cert without restarting
    the daemon?

    In a separate (hopefully) issue, I only can get Autokey to work when
    the password I use in ntp.conf and the ntp-keygen commands are
    identical for the client and server; however the link above implies
    there are (or can be) 2 distinct password, namely the clientpassword
    and serverpassword.

    I am using IFF and use ntp-keygen -T -I -p serverpassword on the
    server and use
    ntp-keygen -H -p clientpassword on the client.

    I ftp the IFF parameters file from the server to the client and
    install it as indicated in the link above. I suspect my issue might be
    with the following statement from the link:
    "You must export an IFF Group Key for each client using that client's
    password. " I am not sure what is meant by this and did not do this
    step...I just ftped the IFF file to the client.

    I really appreciate the help...and sorry for the double question.

    Steve

  2. Re: Autokey Certificate Update

    On 2008-01-03, Steve wrote:

    > The advice on the Autokey configuration page,
    > http://support.ntp.org/bin/view/Supp...iguringAutokey


    I'm the original author of that "page".

    It should be noted that this material applies to the current stable
    release and does not reflect any Autokey updates in the dev release.

    > is to update the server and client key/certificate monthly since the
    > cert is only good for 1 year.


    The "Error Codes" section of
    http://www.cis.udel.edu/~mills/ntp/html/authopt.html states "One of the
    most common errors is expired certificates, which must be regenerated
    and signed at least once per year using the ntp-keygen program."

    The recommendation to update the server certificate on a more frequent
    basis (e.g. monthly) can be found in a number of places including the
    NTP FAQ at http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm. I know I've
    seen it elsewhere.

    > When I run the cert update commands provided on the link above, a new
    > cert and link is generated and Autokey NTP continues to run fine.
    > However, it does not appear that NTP actually uses the new cert until
    > it is restarted. I determined this by examining the output of the ntpq
    > -c "rv 0 cert" command also provided in the link above.


    That's interesting.

    > I want to know if the new cert is used only after a restart because
    > otherwise we might think the certs are being updated only to find NTP
    > Autokey broken 1 year later when the cert in use expires.


    It has always been my understanding the ntpd reloads the cert when the
    protocol restarts (~ daily).

    > So is the real procedure to update the cert then restart NTP on a
    > periodic basis?


    It may be necessary to add a restart to the certificate update
    procedure.

    > Any way to tell NTP to pickup the new cert without restarting the
    > daemon?


    Not that I'm aware of.

    It should be noted that a well tempered ntpd (i.e. iburst on the server
    lines, good drift-file, operating in state 4) is available almost
    immediately after a "warm restart".

    > In a separate (hopefully) issue, I only can get Autokey to work when
    > the password I use in ntp.conf and the ntp-keygen commands are
    > identical for the client and server; however the link above implies
    > there are (or can be) 2 distinct password, namely the clientpassword
    > and serverpassword.
    >
    > I am using IFF and use ntp-keygen -T -I -p serverpassword on the
    > server and use
    > ntp-keygen -H -p clientpassword on the client.
    >
    > I ftp the IFF parameters file from the server to the client and
    > install it as indicated in the link above.


    The full text you are refering to is:

    | 6.7.2.4.1. IFF Group Keys
    |
    | Obtain the IFF group key, exported in 6.7.1.3.1. IFF Parameters via a
    | secure means (e.g. an SSL Web Form or encrypted e-mail), copy the key
    | file to the keysdir, and create the standard sym-link:

    Section 6.7.1.3.1 explains the IFF Parameter generation process and how
    to export the IFF Group Key (or IFF Client Key).

    The IFFpar file is supposed to stay on the server (unless you are using
    the latest ntp-dev and fall in to a certain category).

    > I suspect my issue might be with the following statement from the
    > link: "You must export an IFF Group Key for each client using that
    > client's password." I am not sure what is meant by this and did not
    > do this step...I just ftped the IFF file to the client.


    You may not have read to the end of sections 6.7.1.3.1. Or, if you did,
    the example was confusing.

    IF YOU ARE USING THE CURRENT NTP-STABLE ...

    This is how you export the IFF Group Key to the console:

    cd
    ntp-keygen -e -q serverpassword -p clientpassword

    This is how you export the IFF Group Key to a file:

    cd
    ntp-keygen -e -q serverpassword -p clientpassword > ntpkey_IFFkey_servername

    This is how you export the IFF Group Key and mail it to another
    system:

    cd
    ntp-keygen -e -q serverpassword -p clientpassword | mail admin@somewhere.com

    IFF Group Keys may also be distributed via a web-form. My implementation
    of one is at http://support.ntp.org/crypto.php; it distributes IFF keys
    for that system.

    IF YOU ARE USING THE CURRENT NTP-DEV ...

    It is no longer necessary to provide the client password when exporting
    the IFF Group Key. This means that the IFF Group Key may be treated like
    a PGP/GPG Public Key and made available for download, or distributed,
    via insecure channels.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  3. Re: Autokey Certificate Update

    Steve Kostecke wrote:

    > IFF Group Keys may also be distributed via a web-form. My implementation
    > of one is at http://support.ntp.org/crypto.php; it distributes IFF keys
    > for that system.
    >
    > IF YOU ARE USING THE CURRENT NTP-DEV ...
    >
    > It is no longer necessary to provide the client password when exporting
    > the IFF Group Key. This means that the IFF Group Key may be treated like
    > a PGP/GPG Public Key and made available for download, or distributed,
    > via insecure channels.
    >


    In that case it makes a good candidate to add to the DHCP options to
    distribute this key.

    Danny

  4. Re: Autokey Certificate Update

    Danny,

    Good point; I agree. For experiment I parked the public group key for
    pogo.udel.edu in the lists of public time servers. Next step is to
    figure how to do that with the pool scheme.

    Dave

    Danny Mayer wrote:

    > Steve Kostecke wrote:
    >
    >
    >>IFF Group Keys may also be distributed via a web-form. My implementation
    >>of one is at http://support.ntp.org/crypto.php; it distributes IFF keys
    >>for that system.
    >>
    >>IF YOU ARE USING THE CURRENT NTP-DEV ...
    >>
    >>It is no longer necessary to provide the client password when exporting
    >>the IFF Group Key. This means that the IFF Group Key may be treated like
    >>a PGP/GPG Public Key and made available for download, or distributed,
    >>via insecure channels.
    >>

    >
    >
    > In that case it makes a good candidate to add to the DHCP options to
    > distribute this key.
    >
    > Danny


  5. Re: Autokey Certificate Update

    On 2008-01-04, David L. Mills wrote:

    > Good point; I agree. For experiment I parked the public group key for
    > pogo.udel.edu in the lists of public time servers. Next step is to
    > figure how to do that with the pool scheme.


    Another potential use for 123/TCP ?

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  6. Re: Autokey Certificate Update

    Steve Kostecke wrote:
    > On 2008-01-04, David L. Mills wrote:
    >
    >> Good point; I agree. For experiment I parked the public group key for
    >> pogo.udel.edu in the lists of public time servers. Next step is to
    >> figure how to do that with the pool scheme.

    >
    > Another potential use for 123/TCP ?
    >


    How large is the key file?

    Danny

  7. Re: Autokey Certificate Update

    On 2008-01-04, Danny Mayer wrote:
    > Steve Kostecke wrote:
    >> On 2008-01-04, David L. Mills wrote:
    >>
    >>> Good point; I agree. For experiment I parked the public group key for
    >>> pogo.udel.edu in the lists of public time servers. Next step is to
    >>> figure how to do that with the pool scheme.

    >>
    >> Another potential use for 123/TCP ?

    >
    > How large is the key file?


    The largest one I see locally is 511 bytes.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  8. Re: Autokey Certificate Update

    Steve,

    You are correct; the new certificate is not used until after restarting
    the daemon. When restarted the next upstratum a client automatically
    restart the protocol (not the daemon). They all get well shortly after
    sending the next poll. As this happens the client finds a more recent
    certificate and replaces the old one.

    However, the next upstratum clients after that doesn't see this, since
    the certificate cache is still valid, even if it contains an old
    certificate and the just regenerated self-signed nontrusted certificate
    is not on the trail.

    It is still best practices to refresh the certificates sometime during
    the hear, but it is also best practices to restart the machine at that
    time. Right in the development version I have just put in a gimmick that
    remobilizes each client association once per week. If cetificates are
    refreshed maybe once every month or two, the changes should trickle
    upstratum at that rate, so only the machine with regenerated certificate
    needs to be restarted..

    Dave

    Steve wrote:

    > Hi,
    > The advice on the Autokey configuration page,
    > http://support.ntp.org/bin/view/Supp...iguringAutokey
    > is to update the server and client key/certificate monthly since the
    > cert is only good for 1 year. When I run the cert update commands
    > provided on the link above, a new cert and link is generated and
    > Autokey NTP continues to run fine. However, it does not appear that
    > NTP actually uses the new cert until it is restarted. I determined
    > this by examining the output of the ntpq -c "rv 0 cert" command also
    > provided in the link above.
    >
    > I want to know if the new cert is used only after a restart because
    > otherwise we might think the certs are being updated only to find NTP
    > Autokey broken 1 year later when the cert in use expires. So is the
    > real procedure to update the cert then restart NTP on a periodic
    > basis? Any way to tell NTP to pickup the new cert without restarting
    > the daemon?
    >
    > In a separate (hopefully) issue, I only can get Autokey to work when
    > the password I use in ntp.conf and the ntp-keygen commands are
    > identical for the client and server; however the link above implies
    > there are (or can be) 2 distinct password, namely the clientpassword
    > and serverpassword.
    >
    > I am using IFF and use ntp-keygen -T -I -p serverpassword on the
    > server and use
    > ntp-keygen -H -p clientpassword on the client.
    >
    > I ftp the IFF parameters file from the server to the client and
    > install it as indicated in the link above. I suspect my issue might be
    > with the following statement from the link:
    > "You must export an IFF Group Key for each client using that client's
    > password. " I am not sure what is meant by this and did not do this
    > step...I just ftped the IFF file to the client.
    >
    > I really appreciate the help...and sorry for the double question.
    >
    > Steve


  9. Re: Autokey Certificate Update

    Danny,

    400-600 octest for most files, 7500 octets for the MV trustaed agent
    file, but that contains parameters for 15 keys.

    Dave

    Danny Mayer wrote:
    > Steve Kostecke wrote:
    >
    >>On 2008-01-04, David L. Mills wrote:
    >>
    >>
    >>>Good point; I agree. For experiment I parked the public group key for
    >>>pogo.udel.edu in the lists of public time servers. Next step is to
    >>>figure how to do that with the pool scheme.

    >>
    >>Another potential use for 123/TCP ?
    >>

    >
    >
    > How large is the key file?
    >
    > Danny


  10. Re: Autokey Certificate Update

    On Jan 3, 3:17*pm, Steve Kostecke wrote:
    > On 2008-01-03, Steve wrote:
    >
    > > The advice on the Autokey configuration page,
    > >http://support.ntp.org/bin/view/Supp...iguringAutokey

    >
    > I'm the original author of that "page".
    >
    > It should be noted that this material applies to the current stable
    > release and does not reflect any Autokey updates in the dev release.
    >
    > > is to update the server and client key/certificate monthly since the
    > > cert is only good for 1 year.

    >
    > The "Error Codes" section ofhttp://www.cis.udel.edu/~mills/ntp/html/authopt.htmlstates "One of the
    > most common errors is expired certificates, which must be regenerated
    > and signed at least once per year using the ntp-keygen program."
    >
    > The recommendation to update the server certificate on a more frequent
    > basis (e.g. monthly) can be found in a number of places including the
    > NTP FAQ athttp://www.ntp.org/ntpfaq/NTP-s-config-adv.htm. I know I've
    > seen it elsewhere.
    >
    > > When I run the cert update commands provided on the link above, a new
    > > cert and link is generated and Autokey NTP continues to run fine.
    > > However, it does not appear that NTP actually uses the new cert until
    > > it is restarted. I determined this by examining the output of the ntpq
    > > -c "rv 0 cert" command also provided in the link above.

    >
    > That's interesting.
    >
    > > I want to know if the new cert is used only after a restart because
    > > otherwise we might think the certs are being updated only to find NTP
    > > Autokey broken 1 year later when the cert in use expires.

    >
    > It has always been my understanding the ntpd reloads the cert when the
    > protocol restarts (~ daily).
    >
    > > So is the real procedure to update the cert then restart NTP on a
    > > periodic basis?

    >
    > It may be necessary to add a restart to the certificate update
    > procedure.
    >
    > > Any way to tell NTP to pickup the new cert without restarting the
    > > daemon?

    >
    > Not that I'm aware of.
    >
    > It should be noted that a well tempered ntpd (i.e. iburst on the server
    > lines, good drift-file, operating in state 4) is available almost
    > immediately after a "warm restart".
    >
    > > In a separate (hopefully) issue, I only can get Autokey to work when
    > > the password I use in ntp.conf and the ntp-keygen commands are
    > > identical for the client and server; however the link above implies
    > > there are (or can be) 2 distinct password, namely the clientpassword
    > > and serverpassword.

    >
    > > I am using IFF and use ntp-keygen -T -I -p serverpassword on the
    > > server and use
    > > ntp-keygen -H -p clientpassword on the client.

    >
    > > I ftp the IFF parameters file from the server to the client and
    > > install it as indicated in the link above.

    >
    > The full text you are refering to is:
    >
    > | 6.7.2.4.1. IFF Group Keys
    > |
    > | Obtain the IFF group key, exported in 6.7.1.3.1. IFF Parameters via a
    > | secure means (e.g. an SSL Web Form or encrypted e-mail), copy the key
    > | file to the keysdir, and create the standard sym-link:
    >
    > Section 6.7.1.3.1 explains the IFF Parameter generation process and how
    > to export the IFF Group Key (or IFF Client Key).
    >
    > The IFFpar file is supposed to stay on the server (unless you are using
    > the latest ntp-dev and fall in to a certain category).
    >
    > > I suspect my issue might be with the following statement from the
    > > link: "You must export an IFF Group Key for each client using that
    > > client's password." I am not sure what is meant by this and did not
    > > do this step...I just ftped the IFF file to the client.

    >
    > You may not have read to the end of sections 6.7.1.3.1. Or, if you did,
    > the example was confusing.
    >
    > IF YOU ARE USING THE CURRENT NTP-STABLE ...
    >
    > This is how you export the IFF Group Key to the console:
    >
    > cd
    > ntp-keygen -e -q serverpassword -p clientpassword
    >
    > This is how you export the IFF Group Key to a file:
    >
    > cd
    > ntp-keygen -e -q serverpassword -p clientpassword > ntpkey_IFFkey_servername
    >
    > This is how you export the IFF Group Key and mail it to another
    > system:
    >
    > cd
    > ntp-keygen -e -q serverpassword -p clientpassword | mail ad...@somewhere.com
    >
    > IFF Group Keys may also be distributed via a web-form. My implementation
    > of one is athttp://support.ntp.org/crypto.php;it distributes IFF keys
    > for that system.
    >
    > IF YOU ARE USING THE CURRENT NTP-DEV ...
    >



    > It is no longer necessary to provide the client password when exporting
    > the IFF Group Key. This means that the IFF Group Key may be treated like
    > a PGP/GPG Public Key and made available for download, or distributed,
    > via insecure channels.
    >
    > --
    > Steve Kostecke
    > NTP Public Services Project -http://support.ntp.org/


    Steve, Thanks a lot for helping me with the specifics of IFF. I did
    read that part about exporting the IFF parms but guess I thought it
    was an additional optional step or something. I exported the IFF parms
    and Autokey works like a charm.

    For the record I am using stable version 4.2.0

    Dave,
    thanks for your comments on the certificate update. So if I follow you
    correctly, I should update the certificates on both the client and
    server (for my case I ony use Autokey from s3 client to a s2 server)
    and need to restart the daemon on both for my 4.2.0 version of NTP. If
    I was using your gimmicky version, I would only need to restart the
    server daemon.

    Correct?

+ Reply to Thread