[ntp:questions] ntp-keygen -s

David Mills mills at udel.edu
Wed Jul 1 19:29:38 UTC 2009


We are talking right past each other. I don't undersand your concern, 
especially the possiblitty that gethostname() might return the same name 
for two different hosts. This is an operating system issue, not NTP. Be 
truly advised the online documentation applies to the current 
development version and may not coincide with what you are using. The 
only documentation that applies to your particular version is in your 
software release of whatever version. Upon careful review, the crypto 
host and crypto group commands do exactly as I entend and do correspond 
with the -s and -i options and the defaults do work as expected. I do 
apollogize, but I have nothing further for you. I think we are done with 
this particular issue.


Carsten Rieck wrote:

> Dear David Mills,
> I guess I lack some fundamental understanding, or language borders are 
> too wide!
> My question concerns the use of distinct autokey names ! I merely 
> suggest that  DNS (FQDN)names are sufficiently distinct to allow 
> distinction of trust groups where trusted host (accidentally) have the 
> same gethostname(). I could live with any distinct autokey group name. 
> The documentation at
> http://www.eecis.udel.edu/~mills/ntp/html/authopt.html
> does not really help with that kind of problem, or does it ? I 
> understand the theory and the intention of
> I would like to point out an inconsistency between the documentation 
> at http://www.eecis.udel.edu/~mills/ntp/html/authopt.html and the 
> implementation (4.2.4p5/p7)
> npt.conf options:
> crypto host
> crypto ident
> do not specify host names and group names . In the implementation they 
> specify:
> host: host_key_filename (host_file) which is used in pkey = 
> crypto_key(host_file, &fstamp); (ntp_crypo.c:4003), and
> ident: sets ident_scheme as any of 
> the CRYPTO_ASSOC exchange for compatibility tests.
> using ntp-keygen with the matching options -s and -i is also not 
> straight forward:
> -s works as expected setting the subject of the certificate at will
> -i is not recognized in e.g. ntp-keygen -T -I -s perl.sp.se -i perl.sp.se
>    it segfaults when used as -iperl.sp.se for example
> this could possibly be my compilation, but as much as I can see it 
> compiles cleanly (with  warning: assignment discards qualifiers from 
> pointer target type), openssl is of v0.9.8g. I have checked with a 
> stock compiled Ubuntu version  4.2.4p4, that behaves similar.
> Could someone verify the -i issue ? thank you !
> A ntp-keygen certificate uses the gethostname() (in this case changed 
> to "gold") as issuer but allows a variable subject name: below output 
> of a 'ntp-keygen -T -I -s perl.sp.se' produced certificate:
>carsten at perl:/etc/ntp.keys$ openssl x509 -text -in ntpkey_RSA-MD5cert_perl.sp.se.3455423985 
>    Data:
>        Version: 3 (0x2)
>        Serial Number: -839543311 (-0x320a6a0f)
>        Signature Algorithm: md5WithRSAEncryption
>        Issuer: CN=gold
>        Validity
>            Not Before: Jul  1 07:59:45 2009 GMT
>            Not After : Jul  1 07:59:45 2010 GMT
>        Subject: CN=perl.sp.se
>        Subject Public Key Info:
>            Public Key Algorithm: rsaEncryption
>            RSA Public Key: (512 bit)
>                Modulus (512 bit):
>                    00:df:68:29:86:ed:ce:19:e8:18:89:2b:7a:eb:5a:
>                    5d:c8:f1:0b:38:a5:be:29:17:68:f3:9f:13:c6:fe:
>                    8a:33:55:a6:f6:62:2a:3e:4b:ff:39:61:90:32:ca:
>                    a9:52:85:8a:8c:05:b4:d8:d1:26:37:47:b5:88:8d:
>                    78:a2:2b:98:19
>                Exponent: 3 (0x3)
>        X509v3 extensions:
>            X509v3 Basic Constraints: critical
>                CA:TRUE
>            X509v3 Key Usage: 
>                Digital Signature, Certificate Sign
>            X509v3 Extended Key Usage: 
>                Trust Root
>    Signature Algorithm: md5WithRSAEncryption
>        8e:88:3d:2b:79:75:b4:32:9b:a9:b9:dc:e0:3a:08:12:44:e9:
>        55:d3:8d:d8:ca:c9:11:ae:af:b0:ce:86:69:ad:4b:eb:05:6a:
>        19:9c:0f:a4:59:c4:f6:56:0f:30:20:55:ae:6a:07:c4:45:8f:
>        1e:1e:b5:be:4f:7c:31:cb:2c:9c
>carsten at perl:/etc/ntp.keys$ 
> From the code (again stable 4.2.4p5/p7) I do not see how DNS host 
> names are by default used for Autokey host names. gethostname() 
> returns whatever the system was configured for. if the ntp.conf 
> options and the ntp-keygen options would work as described by the 
> documentation I guess I could set group names at will and they would 
> also propagate via the autokey protocol. The only thing that would be 
> needed is a mechanism for the clients to know the group name, which 
> could be achieved by the group (if) parameter distribution.
> again, I am grateful for the advice your are giving !
> with best regards
> Carsten Rieck
> David Mills wrote:
>>You ask where to go for examples and additional information on Autokey
>>names. See the Authentication Optioins page in the documentation. You
>>say you want to use DNS host names for Autokey host names. That's the
>>default! If you want to use DNS host names for the trusted hosts, that's
>>the default, too! The only problem is that the dependent hosts have to
>>specify the trusted host DNS name as the group name and most folks would
>>want to use a generic group name rather than a host name..
>>Carsten Rieck wrote:
>>>Dear David Mills,
>>>Thank you for your advice, I appreciate your time.
>>>I understand that the DNS name space and the NTP autokey name space
>>>are not connected.
>>>Nevertheless it would seem convenient to use DNS names for autokey in
>>>case trust groups consist of only a single trusted host. This would
>>>not imply the use of DNS service as often well behaved systems know
>>>about there domainname.
>>>Could you point me to the examples in the documentation, I am unable
>>>to find information about how to handle autokey names for hosts with
>>>the same gethostname() but different trust groups.
>>>In desperation I have turned to the code and parsed ntp_crypto.c in
>>>particular. I try to summarize the relevant autokey name-space part
>>>for iff (most for my understanding):
>>>- Server side crypto_setup(void) sets 'sys_hostname' using
>>>gethostname() which in turn is used to initialize the 'hostval'
>>>structure, where the value part stays constant during ntpd's lifetime.
>>>- clients peer_xmit() of ntp_proto.c governs the per peer autokey
>>>exchange state machine
>>>- Server crypto_xmit(....) uses hostval in order to respond to
>>>CRYPTO_ASSOC request from the client with
>>>       len += crypto_send(fp, &hostval);
>>>       fp->fstamp = htonl(crypto_flags);
>>>- Client crypto_recv(...) in in turn uses
>>>and saves the servers (autokey) name in both 'peer->subject' and
>>>- clients peer_xmit() builds extension field using peer->issuer
>>>exten = crypto_args(peer, CRYPTO_CERT,
>>>                           peer->issuer);
>>>- and thus requests the certificate from the peer with the subject name
>>>- Server searches its certifcate list ('cinfo') in order to find a TC
>>>              memcpy(certname, ep->pkt, vallen);
>>>      ...
>>>              xp = NULL;
>>>              for (cp = cinfo; cp != NULL; cp = cp->link) {
>>>                      if (cp->flags & CERT_PRIV)
>>>                              continue;
>>>                      if (strcmp(certname, cp->subject) == 0) {
>>>                              if (xp == NULL)
>>>                                      xp = cp;
>>>                              if (strcmp(certname, cp->issuer) ==
>>>                                  0 && cp->flags & CERT_TRUST) {
>>>                                      xp = cp;
>>>                                      break;
>>>                              }
>>>                      }
>>>              }
>>>- Server sends its certifacte
>>>  crypto_send(fp, &xp->cert);
>>>- Clients case CRYPTO_CERT | CRYPTO_RESP: tests the cert, adds it to
>>>its list of certs and trails till TC
>>>  'peer->issuer' gets eventually altered if the server has no TC
>>>- Clients crypto_ident(...) uses 'peer->issuer' in order to construct
>>>and load the iff parameters
>>>   if (peer->crypto & CRYPTO_FLAG_IFF) {
>>>       snprintf(filename, MAXFILENAME, "ntpkey_iff_%s",
>>>           peer->issuer);
>>>   peer->ident_pkey = crypto_key(filename, &peer->fstamp);
>>>That would means that the servers gethostname() gets directly mapped
>>>to the iff parameter file on the client. this in turn means that
>>>servers (single trusted hosts) would need to be referred to the same
>>>name space segment, even if they potentially do not belong to the same
>>>trust group  ? I just need to understand what the limits are. I often
>>>do not have control over hostname settings (that traditionally is
>>>ntp[123]). So I appreciate if you could point me to specific
>>>thank you, with best regards
>>>Carsten Rieck
>>>David Mills wrote:
>>>>There are examples in the documentation. Note that the -s option is only
>>>>for nontrusted hosts. Note also that the Autokey names have nothing to
>>>>do with DNS names with the exception that the default name is the string
>>>>returned by the gethostname() system call, whatever that might be. There
>>>>is in general no need to specify an Autokey name for a nontrusted host.
>>>>Carsten Rieck wrote:
>>>>>I hope someone can advice me some guidelines for the following:
>>>>>Lets say I have have a couple of primary servers at different domains
>>>>>that are all called "ntp[123].whateverXdomain". These servers I want to
>>>>>configure for IFF autokey all forming there own (domain wise) auth/trus
>>>>>group. Sym-links for the particular group keys of these servers are by
>>>>>default all need to be called "ntpkey_iff_ntp[123]" at a clients
>>>>>locations. This makes it impossible (?) to use several of these servers
>>>>>at the same time, i.e. group names have to be distinct from each other.
>>>>>At first glans this should be a client (configuration) problem. On the
>>>>>client it seems to me that the naming of the generic link:
>>>>>ntpkey_iff_server only works for with the short hostname of the server.
>>>>>Nevertheless, on the server (maybe unrelated):
>>>>>(4.2.4p5) ntp-keygen/ntpd by default seem to use the short hostname
>>>>>(versus  long hostname fqdn) when creating/searching for keys and
>>>>>Using ntp-keygen with the -s option and "crypto host" and "crypto cert"
>>>>>of ntp.conf suggest that the naming convention can be changed.
>>>>>as an example:
>>>>>ntp-keygen -s perl.sp.se -T -I -p "a_proper_passwd"
>>>>>lrwxrwxrwx   1 root root    40 2009-06-29 12:00 ntpkey_cert_perl.sp.se -> ntpkey_RSA-MD5cert_perl.sp.se.3455258405
>>>>>lrwxrwxrwx   1 root root    35 2009-06-29 12:00 ntpkey_host_perl.sp.se -> ntpkey_RSAkey_perl.sp.se.3455258405
>>>>>-rw-r--r--   1 root root   530 2009-06-29 12:00 ntpkey_IFFpar_perl.3455258405
>>>>>lrwxrwxrwx   1 root root    29 2009-06-29 12:00 ntpkey_iff_perl -> ntpkey_IFFpar_perl.3455258405
>>>>>-rw-r--r--   1 root root   621 2009-06-29 12:00 ntpkey_RSAkey_perl.sp.se.3455258405
>>>>>-rw-r--r--   1 root root   579 2009-06-29 12:00 ntpkey_RSA-MD5cert_perl.sp.se.3455258405
>>>>>and apparently names the parameter file different from the key/cert
>>>>>files. First line content matches the filenames of the respective file.
>>>>>groupkey export does nothing with the -s switch:
>>>>>ntp-keygen -s perl.sp.se -e -q "a_proper_passwd" -p "client_pw"
>>>>>but produces a stdout output when used without:
>>>>>ntp-keygen -e -q "a_proper_passwd" -p "client_pw"
>>>>>using a matching ntp.conf:
>>>>>logfile /var/log/ntp
>>>>>driftfile /etc/ntp.drift
>>>>>fudge stratum 10
>>>>>##### ak_tool starts messing with your ntp.conf ##########
>>>>># ak_tool crypto setup
>>>>>crypto host ntpkey_host_perl.sp.se
>>>>>crypto cert ntpkey_cert_perl.sp.se
>>>>>crypto ident iff
>>>>>crypto pw a_proper_passwd
>>>>>crypto randfile /root/.rnd
>>>>>keysdir /etc/ntp.keys
>>>>>Running ntp with this setup fails with:
>>>>>root at perl:/etc/ntp.keys# ntpd  -D 1
>>>>>ntpd 4.2.4p5 at 1.1541-o Thu Jun 11 14:49:14 UTC 2009 (3)
>>>>>addto_syslog: precision = 1.000 usec
>>>>>addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
>>>>>addto_syslog: Listening on interface #0 wildcard, Disabled
>>>>>addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled
>>>>>addto_syslog: Listening on interface #2 lo, ::1#123 Enabled
>>>>>addto_syslog: Listening on interface #3 eth0, fe80::223:54ff:fed4:52eb#123 Enabled
>>>>>addto_syslog: Listening on interface #4 lo, Enabled
>>>>>addto_syslog: Listening on interface #5 eth0, Enabled
>>>>>local_clock: time 0 offset 0.000000 freq 0.000 state 0
>>>>>addto_syslog: kernel time sync status 0040
>>>>>addto_syslog: frequency initialized -69.250 PPM from /etc/ntp.drift
>>>>>peer_crypto_clear: at 0 next 0 assoc ID 13875
>>>>>key_expire: at 0
>>>>>peer_clear: at 0 next 1 assoc ID 13875 refid INIT
>>>>>newpeer:> mode 3 vers 4 poll 6 10 flags 0x1021 0x1 ttl 0 key 00000000
>>>>>local_clock: time 0 offset 0.000000 freq -69.250 state 1
>>>>>crypto_setup: OpenSSL version 90807f random seed file /root/.rnd bytes read 1024
>>>>>crypto_key: ntpkey_RSAkey_perl.sp.se.3455258405 mod 512
>>>>>crypto_key: ntpkey_IFFpar_perl.3455258405 mod 384
>>>>>cert_parse: X509v3 Extended Key Usage: Trust Root
>>>>>crypto_cert: ntpkey_RSA-MD5cert_perl.sp.se.3455258405 0x1 len 335
>>>>>addto_syslog: crypto_setup: certificate ntpkey_cert_perl.sp.se not for this host
>>>>>Cert regeneration works well with
>>>>>ntp-keygen -s perl.sp.se -T -q a_proper_passwd
>>>>>A key-generation without -s option and a relevant ntp.conf  and ntpd
>>>>>works well.
>>>>>I wonder if someone has experience with these kind of problems.
>>>>>Thank you, with best regards
>>>>>Carsten Rieck
>>>>questions mailing list
>>>>questions at lists.ntp.org
>>>Carsten Rieck
>>>SP Technical Research Institute of Sweden
>>>Measurement Technology / MTk, Time and Frequency
>>>Box 857, SE-501 15 Boras Sweden
>>>Tel: +46 10 516 54 40 Cel: +46 703 170705 fax: +46 10 516 56 20
>>>the dirty dozen: \|()[{^$*+?.
>>questions mailing list
>>questions at lists.ntp.org
>Carsten Rieck
>SP Technical Research Institute of Sweden
>Measurement Technology / MTk, Time and Frequency
>Box 857, SE-501 15 Boras Sweden
>Tel: +46 10 516 54 40 Cel: +46 703 170705 fax: +46 10 516 56 20
>the dirty dozen: \|()[{^$*+?. 

More information about the questions mailing list