[ntp:questions] ntp-keygen -s

Carsten Rieck carsten.rieck at sp.se
Wed Jul 1 10:07:41 UTC 2009


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 
(CRYPTO_FLAG_IFF|CRYPTO_FLAG_GQ|CRYPTO_FLAG_MV) which is used during 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 
Certificate:
    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
-----BEGIN CERTIFICATE-----
MIIBSzCB9qADAgECAgTN9ZXxMA0GCSqGSIb3DQEBBAUAMA8xDTALBgNVBAMTBGdv
bGQwHhcNMDkwNzAxMDc1OTQ1WhcNMTAwNzAxMDc1OTQ1WjAVMRMwEQYDVQQDEwpw
ZXJsLnNwLnNlMFowDQYJKoZIhvcNAQEBBQADSQAwRgJBAN9oKYbtzhnoGIkreuta
XcjxCzilvikXaPOfE8b+ijNVpvZiKj5L/zlhkDLKqVKFiowFtNjRJjdHtYiNeKIr
mBkCAQOjNjA0MA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgKEMBQGA1UdJQQN
MAsGCSsGAQUFBzABCzANBgkqhkiG9w0BAQQFAANBAI6IPSt5dbQym6m53OA6CBJE
6VXTjdjKyRGur7DOhmmtS+sFahmcD6RZxPZWDzAgVa5qB8RFjx4etb5PfDHLLJw=
-----END CERTIFICATE-----
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:
> 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: \|()[{^$*+?.
>>
>>
>>     
>
> _______________________________________________
> 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