[ntp:questions] ntp-keygen -s

David Mills mills at udel.edu
Tue Jun 30 21:19:33 UTC 2009


Carsten,

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

Dave

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
>
>case CRYPTO_ASSOC | CRYPTO_RESP:
>
>        len += crypto_send(fp, &hostval);
>
>        fp->fstamp = htonl(crypto_flags);
>
> - Client crypto_recv(...) in in turn uses
>
>case CRYPTO_ASSOC | CRYPTO_RESP: 
>
> and saves the servers (autokey) name in both 'peer->subject' and 
> 'peer->issuer'
> - 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 
> documentation/examples.
>
>
> thank you, with best regards
> Carsten Rieck
>
>
>
> David Mills wrote:
>
>>Carsten,
>>
>>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.
>>
>>Dave
>>
>>Carsten Rieck wrote:
>>
>>  
>>
>>>Hej,
>>>
>>>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
>>>certificates.
>>>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"
>>>
>>>generates:
>>>
>>>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
>>>
>>>server 127.127.1.0
>>>fudge 127.127.1.0 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, 0.0.0.0#123 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, 127.0.0.1#123 Enabled
>>>addto_syslog: Listening on interface #5 eth0, 10.1.71.85#123 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: 127.0.0.1->127.127.1.0 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
>>https://lists.ntp.org/mailman/listinfo/questions
>>
>>  
>>
>
>-- 
>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