[ntp:hackers] Autokey with IFF - unable to get it working with 4.2.4p4 and 4.2.5p105

Olaf Fraczyk olaf at navi.pl
Thu Dec 13 12:50:31 UTC 2007


Hello,

I'm trying to get working IFF scheme.

I have made 3 tests named TEST1, TEST2, TEST3.
TEST1 - only server has IFF parameters
TEST2 - server and client have parameters
TEST3 - additional link for client parameters, as found using strace. It
seems that there is bug in the code or in the documentation.

I try it using:
case A - server 4.2.4p4 - client 4.2.4p4 
sace B - server 4.2.4p4 - client 4.2.5p105
case C - server 4.2.5p105 - client 4.2.5p105

All tests are performed using official documentation found on ntp.org
site (this seems to be coherent with the community supported
documentation - at least in this aspect).

The sad truth is that I couldn't get it working with ANY configuration.

What is the most interesting is the test result for TEST1 case B.
The client has no IFF keys but it claims that the server is
authenticated and that the IFF scheme is in use :).

The other interesting thing is that in 4.2.4p4 the client is even not
trying to open client iff parameters. So it simply cannot work. This is
shown in TEST2 case A.

Below provided is detailed description of configuration and all
actions that have been performed.

As a side note:
Does anybody have working and tested configuration and is able to share
it? I mean including the exact ntp version, configuration files etc.

I have tested 4.2.4p4 - marked as stable
and 4.2.5p105 marked as devel


Setup:
SERVER: venus.local.navi.pl
CLIENT: sunshine

On SERVER:
in /etc/ntp/ I generated keys, certificates and IFF parameters:
/home/projects/ntp/binaries/stable/bin/ntp-keygen -T -I -p lala

So I have:

[root at venus ntp]# ll
total 12
lrwxrwxrwx  1 root root  49 Dec 12 16:09 ntpkey_cert_venus.local.navi.pl -> ntpkey_RSA-MD5cert_venus.local.navi.pl.3406460940
lrwxrwxrwx  1 root root  44 Dec 12 16:09 ntpkey_host_venus.local.navi.pl -> ntpkey_RSAkey_venus.local.navi.pl.3406460940
-rw-r--r--  1 root root 545 Dec 12 16:09 ntpkey_IFFpar_venus.local.navi.pl.3406460940
lrwxrwxrwx  1 root root  44 Dec 12 16:09 ntpkey_iff_venus.local.navi.pl -> ntpkey_IFFpar_venus.local.navi.pl.3406460940
-rw-r--r--  1 root root 630 Dec 12 16:09 ntpkey_RSAkey_venus.local.navi.pl.3406460940
-rw-r--r--  1 root root 621 Dec 12 16:09 ntpkey_RSA-MD5cert_venus.local.navi.pl.3406460940

in /etc/ntp.conf I have:
-----
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0
crypto pw lala ident venus.local.navi.pl
server 127.127.1.0 prefer
fudge 127.127.1.0 stratum 0
logfile /var/log/messages
statsdir /var/log
keysdir /etc/ntp
statistics cryptostats loopstats peerstats clockstats
-----

On CLIENT:

in /etc/ntp/ I generated keys and certificates:
/root/ntp_trees/exec/4.2.4p4/bin/ntp-keygen -p lala

So I have:

[root at sunshine ntp]# ll
total 8
lrwxrwxrwx 1 root root  38 Dec 12 16:16 ntpkey_cert_sunshine -> ntpkey_RSA-MD5cert_sunshine.3406461375
lrwxrwxrwx 1 root root  33 Dec 12 16:16 ntpkey_host_sunshine -> ntpkey_RSAkey_sunshine.3406461375
-rw-r--r-- 1 root root 619 Dec 12 16:16 ntpkey_RSAkey_sunshine.3406461375
-rw-r--r-- 1 root root 549 Dec 12 16:16 ntpkey_RSA-MD5cert_sunshine.3406461375

in /etc/ntp.conf I have:
-----
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0
crypto pw lala ident venus.local.navi.pl
server venus.local.navi.pl autokey
logfile /var/log/messages
statsdir /var/log                                                               
keysdir /etc/ntp
statistics cryptostats loopstats peerstats clockstats 
----

Yes - I know I need the IFF parameters on the client,
but it will be done later in next test.

TEST1
I tried the configuration in three ways: 
A - both server and client running stable tree
B - server using stable, client using devel tree
C - both server and client running devel tree
RESULTS:

The A case:

1.On the server:
>From logcryptostats looks like the IFF parameters are loaded:
54446 55367.005 ntpkey_RSAkey_venus.local.navi.pl.3406460940 mod 512
54446 55367.006 ntpkey_IFFpar_venus.local.navi.pl.3406460940 mod 384
54446 55367.006 ntpkey_RSA-MD5cert_venus.local.navi.pl.3406460940 0x1 len 360
54446 55367.979 refresh ts 0
Also nothing wrong in /var/log messages.

2. On the client:
>From logcryptostats looks like the IFF parameters are not loaded
- it is fine as we don't have any yet.
- From flags we see that we use autokey, but IFF scheme is not used:
54446 55662.476 ntpkey_RSAkey_sunshine.3406461375 mod 512                       
54446 55662.476 ntpkey_RSA-MD5cert_sunshine.3406461375 0x0 len 315              
54446 55663.180 refresh ts 0                                                    
54446 55663.180 192.168.1.10 flags 0x80001 host venus.local.navi.pl signature md
5WithRSAEncryption                                                              
54446 55728.183 192.168.1.10 cert venus.local.navi.pl 0x7 md5WithRSAEncryption (
8) fs 3406460940                                                                
54446 55794.183 192.168.1.10 cook 801961ff ts 3406462194 fs 3406461962          
54446 56031.629 192.168.1.10 flags 0x80001 host venus.local.navi.pl signature md
5WithRSAEncryption                                                              
54446 56095.627 192.168.1.10 cert venus.local.navi.pl 0x7 md5WithRSAEncryption (
8) fs 3406460940                                                                
54446 56160.627 192.168.1.10 cook 801961ff ts 3406462560 fs 3406461962 

Reading association information we get:
hostname="venus.local.navi.pl", signature="md5WithRSAEncryption",
flags=0x83f01, trust="venus.local.navi.pl"

3. Everything seems to be OK. 
IFF is not used, as we have no IFF parameters on the client.

The B case:
1. On the server we change nothing so identical to case A.

2. On the client:
We see flag saying that IFF is in use:
in logcryptostats:
54446 56430.779 192.168.1.10 clear 46611 ident INIT                             
54446 56430.779 192.168.1.10 newpeer 46611                                      
54446 56431.478 192.168.1.10 flags 0x80021 host venus.local.navi.pl signature md
5WithRSAEncryption                                                              
54446 56495.477 192.168.1.10 cert venus.local.navi.pl 0x7 md5WithRSAEncryption (
8) fs 3406460940                                                                
54446 56560.486 192.168.1.10 cook 801961ff ts 3406462960 fs 3406461962          
54446 56567.486 update at 137 ts 3406462967                                     
54446 56568.491 update at 138 ts 3406462968                                     
54446 56568.491 192.168.1.10 sign venus.local.navi.pl 0x6 md5WithRSAEncryption (
8) fs 3406461375 


Reading association information we get:
host="venus.local.navi.pl", flags=0x83f21,
signature="md5WithRSAEncryption"

3. What is going on? 
We have no client IFF parameters but from flags we clearly see that IFF is used.

The C case:

1. On the server I got in /var/log/messages:
Dec 12 16:52:03 venus ntpd[19783]: crypto_setup: trusted host venus.local.navi.p
l missing group name

So I added "ident venus.local.navi.pl" to the crypto command and it worked.
In logcryptostats I see nothing:
54446 57216.500 127.127.1.0 clear 17887 ident INIT
54446 57217.480 update at 1 ts 3406463617

2. on the client:
in logcryptostats:
54446 57476.205 192.168.1.10 clear 2093 ident INIT                              
54446 57476.205 192.168.1.10 newpeer 2093                                       
54446 57476.903 192.168.1.10 flags 0x80001 host venus.local.navi.pl signature md
5WithRSAEncryption                                                              
54446 57542.900 192.168.1.10 cert venus.local.navi.pl 0x7 md5WithRSAEncryption (
8) fs 3406460940                                                                
54446 57608.905 192.168.1.10 cook f558385 ts 3406464008 fs 3406463617           
54446 57615.906 update at 140 ts 3406464015                                     
54446 57616.910 update at 141 ts 3406464016                                     
54446 57616.910 192.168.1.10 sign venus.local.navi.pl 0x6 md5WithRSAEncryption (
8) fs 3406461375                                                                
54446 57618.903 192.168.1.10 leap TAI offset 0 at 3408134400 expire 0 fs 3406460
940  

Reading association information we get:         
host="venus.local.navi.pl", flags=0x87f01,
signature="md5WithRSAEncryption"

3. Everything seems to be OK. 
IFF is not used, as we have no IFF parameters on the client.                                                                                                                                        
    
---------------------------

TEST2

Here I added IFF parameters to the client machine:
I copied IFFpar from SERVER and put link on client so in /etc/ntp I have:
[root at sunshine ~]# ls -l /etc/ntp
total 12
lrwxrwxrwx 1 root root  38 Dec 12 16:16 ntpkey_cert_sunshine -> ntpkey_RSA-MD5cert_sunshine.3406461375
lrwxrwxrwx 1 root root  33 Dec 12 16:16 ntpkey_host_sunshine -> ntpkey_RSAkey_sunshine.3406461375
-rw-r--r-- 1 root root 545 Dec 12 16:09 ntpkey_IFFpar_venus.local.navi.pl.3406460940
lrwxrwxrwx 1 root root  44 Dec 13 11:07 ntpkey_iff_venus.local.navi.pl -> ntpkey_IFFpar_venus.local.navi.pl.3406460940
-rw-r--r-- 1 root root 619 Dec 12 16:16 ntpkey_RSAkey_sunshine.3406461375
-rw-r--r-- 1 root root 549 Dec 12 16:16 ntpkey_RSA-MD5cert_sunshine.3406461375



I tried the configuration in three ways: 
A - both server and client running stable tree
B - server using stable, client using devel tree
C - both server and client running devel tree
RESULTS:

The A case:

1. Since there is no change on SERVER to the TEST1 I skip it.

2. On the client:
>From logcryptostats looks like the IFF parameters are not loaded.
This is strange as we have the ntpkey_iff_venus.local.navi.pl.
54447 37166.850 ntpkey_RSAkey_sunshine.3406461375 mod 512                       
54447 37166.851 ntpkey_RSA-MD5cert_sunshine.3406461375 0x0 len 315              
54447 37167.574 refresh ts 0                                                    
54447 37167.575 192.168.1.10 flags 0x80001 host venus.local.navi.pl signature md
5WithRSAEncryption                                                              
54447 37232.577 192.168.1.10 cert venus.local.navi.pl 0x7 md5WithRSAEncryption (
8) fs 3406460940                                                                
54447 37295.576 192.168.1.10 cook 8554bd63 ts 3406530103 fs 3406529924          
54447 37506.889 192.168.1.10 flags 0x80001 host venus.local.navi.pl signature md
5WithRSAEncryption                                                              
54447 37572.891 192.168.1.10 cert venus.local.navi.pl 0x7 md5WithRSAEncryption (
8) fs 3406460940                                                                
54447 37638.890 192.168.1.10 cook 8554bd63 ts 3406530438 fs 3406529924          
54447 37833.892 update ts 3406530633                                            
54447 37833.895 update ts 3406530633  

Reading association information we get:
hostname="venus.local.navi.pl", signature="md5WithRSAEncryption",
flags=0x83f01, trust="venus.local.navi.pl"

3. What is going on? We have the IFF parameters.
Why is IFF scheme not used ??

4. Doing strace and looking for the "iff" word I only see:
[root at sunshine ntp]# strace -f /root/ntp_trees/exec/4.2.4p4/bin/ntpd 2>&1 | grep iff
open("/etc/ntp/ntpkey_iff_sunshine", O_RDONLY) = -1 ENOENT (No such file or directory)

So it looks only for parameters for "sunshine" group, but not for the
"venus.local.navi.pl" group. Kinda strange, isn't it?
It gives us some clue why we don't use IFF for this association.
But also tells us that something is wrong here.

5. I did another strace - looking for the "venus" word:
[root at sunshine ntp]# strace -f /root/ntp_trees/exec/4.2.4p4/bin/ntpd 2>&1 | grep venus

But the only thing I get is network traffic. So it clearly doesn't try to find
the venus.local.navi.pl group parameters.

The B case:

1. Since there is no change on SERVER to the TEST1 I skip it.

2. On the client:
Hmm - here is something interesting.
The autokey worked for a while. The IFF is still not working at all.

hostname="venus.local.navi.pl", signature="md5WithRSAEncryption",
flags=0x83f01, trust="venus.local.navi.pl"

But afterwards this info disappeared from association variables.

What is more interesting:
ntpq> la

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 25489  e01f   yes   yes   ok     reject              1
  
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 venus.local.nav .CRYP.          16 u  262   64    0    0.000    0.000   0.000



In logcryptostats we have:
54447 39607.325 192.168.1.10 clear 25489 ident INIT                             
54447 39607.326 192.168.1.10 newpeer 25489                                      
54447 39608.068 192.168.1.10 flags 0x80021 host venus.local.navi.pl signature md
5WithRSAEncryption                                                              
54447 39672.070 192.168.1.10 cert venus.local.navi.pl 0x7 md5WithRSAEncryption (
8) fs 3406460940                                                                
54447 39737.079 192.168.1.10 error 10f opcode c2000000 ts 0 fs 0                
54447 39737.079 192.168.1.10 clear 25489 ident CRYP

3. Why is it not working??

4. How can we get auth=ok with .CRYP. kiss of death code!!!!????
Why the crypto fails?

5. I tried to do strace and found that ntpd is looking for:
"ntpkey_iffkey_venus.local.navi.pl" and NOT for:
"ntpkey_iff_venus.local.navi.pl"

The C case:

1. Since there is no change on SERVER to the TEST1 I skip it.

2. On the client
Autokey is working.The IFF scheme is not working.
In logcryptostats we have:
54447 40984.104 192.168.1.10 clear 49854 ident INIT                             
54447 40984.104 192.168.1.10 newpeer 49854                                      
54447 40984.867 192.168.1.10 flags 0x80001 host venus.local.navi.pl signature md
5WithRSAEncryption                                                              
54447 41050.860 192.168.1.10 cert venus.local.navi.pl 0x7 md5WithRSAEncryption (
8) fs 3406460940                                                                
54447 41114.860 192.168.1.10 cook d79f86df ts 3406533915 fs 3406533454          
54447 41121.022 192.168.1.10 clear 49854 ident STEP                             
54447 41122.022 192.168.1.10 flags 0x80001 host venus.local.navi.pl signature md
5WithRSAEncryption                                                              
54447 41189.024 192.168.1.10 cert venus.local.navi.pl 0x7 md5WithRSAEncryption (
8) fs 3406460940                                                                
54447 41255.027 192.168.1.10 cook d79f86df ts 3406534055 fs 3406533454          
54447 41262.028 update at 278 ts 3406534062                                     
54447 41263.053 update at 279 ts 3406534063                                     
54447 41263.053 192.168.1.10 sign venus.local.navi.pl 0x6 md5WithRSAEncryption (
8) fs 3406461375                                                                
54447 41265.025 192.168.1.10 leap TAI offset 0 at 3408134400 expire 0 fs 3406460
940   

>From ntpq:
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*venus.local.nav .LOCL.           1 u   56   64    3    0.132   11.751   1.862
ntpq> la

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 49854  f624   yes   yes   ok   sys.peer   reachable  2

host="venus.local.navi.pl", flags=0x87f01,
signature="md5WithRSAEncryption"

3. Why is it not working?? 

----------------------------------------------

TEST3

I did again case B and C, because I have found that ntpd wants another symlink.
"ntpkey_iffkey_venus.local.navi.pl" and NOT:
"ntpkey_iff_venus.local.navi.pl"

So I added the required link and now I have:
[root at sunshine ntp]# ls -l
total 12
lrwxrwxrwx 1 root root  38 Dec 12 16:16 ntpkey_cert_sunshine -> ntpkey_RSA-MD5cert_sunshine.3406461375
lrwxrwxrwx 1 root root  33 Dec 12 16:16 ntpkey_host_sunshine -> ntpkey_RSAkey_sunshine.3406461375
lrwxrwxrwx 1 root root  30 Dec 13 12:40 ntpkey_iffkey_venus.local.navi.pl -> ntpkey_iff_venus.local.navi.pl
-rw-r--r-- 1 root root 545 Dec 12 16:09 ntpkey_IFFpar_venus.local.navi.pl.3406460940
lrwxrwxrwx 1 root root  44 Dec 13 11:07 ntpkey_iff_venus.local.navi.pl -> ntpkey_IFFpar_venus.local.navi.pl.3406460940
-rw-r--r-- 1 root root 619 Dec 12 16:16 ntpkey_RSAkey_sunshine.3406461375
-rw-r--r-- 1 root root 549 Dec 12 16:16 ntpkey_RSA-MD5cert_sunshine.3406461375

Case B:

1. Since there is no change on SERVER to the TEST1 I skip it.

2. On the client:
Seems to start working for a while. Next it fails.

In logcryptostats we have:
54447 43221.287 192.168.1.10 clear 35709 ident INIT                             
54447 43221.288 192.168.1.10 newpeer 35709                                      
54447 43222.032 192.168.1.10 flags 0x80021 host venus.local.navi.pl signature md
5WithRSAEncryption                                                              
54447 43288.024 192.168.1.10 cert venus.local.navi.pl 0x7 md5WithRSAEncryption (
8) fs 3406460940                                                                
54447 43355.029 192.168.1.10 error 10f opcode c2000000 ts 0 fs 0                
54447 43355.029 192.168.1.10 clear 35709 ident CRYP 

In ntpq we get:

Before failed:
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 venus.local.nav .LOCL.           1 u   45   64    0    0.000    0.000   0.000

ntpq> la

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 35709  e000   yes   yes   ok     reject

And flags:
host="venus.local.navi.pl", flags=0x80021,
signature="md5WithRSAEncryption"

After failed:
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 venus.local.nav .CRYP.          16 u  170   64    0    0.000    0.000   0.000
ntpq> la

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 35709  e01f   yes   yes   ok     reject              1
  
3. Why it fails.

4. Again - why auth=ok?

Case C:


1. Since there is no change on SERVER to the TEST1 I skip it.

2. On the client:
The crypto fails immediatly. 
In logcryptostats we have:
54447 42435.443 192.168.1.10 clear 19516 ident INIT                             
54447 42435.443 192.168.1.10 newpeer 19516                                      
54447 42436.193 192.168.1.10 error 106 opcode 82010000 ts 3406533454 fs 524289  
54447 42436.193 192.168.1.10 clear 19516 ident CRYP 

In ntpq I get:
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 venus.local.nav .CRYP.          16 u    -   64    0    0.000    0.000   0.000
ntpq> la

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 19516  e016   yes   yes   ok     reject              1


3. Why it fails.

4. Again - why auth=ok?

Here is the end :)

Regards,

Olaf Frączyk
-- 
Olaf Frączyk <olaf at navi.pl>
NAVI
http://www.navi.pl




More information about the hackers mailing list