[ntp:questions] authenticated packet using alternate digest algorithms

Greg.Dowd at microchip.com Greg.Dowd at microchip.com
Tue Apr 30 16:08:47 UTC 2019


Sorry, took me a few tries to get a format that was acceptable for posting and lost quite a bit of the original material in the process.


Hey, am I missing something here?  I'm looking at ntpd 4.2.6 and 4.2.8.  A customer pointed to the ntp.keys web page and asked about using sha512.  The link is
https://docs.ntpsec.org/latest/ntp_keys.html
and it appears to clearly show how to use any digest algorithm supported by openssl.  When I create a keyfile and run ntpd in debug mode, sure enough they all get parsed and assigned a digest id for digest algorithms md5, sha1, ripemd160, sha224, 256,384 and 512.

Here are some keys:
6 MD5 zs"a@'r`&QiNW>ihD;YF  # MD5 key
7 MD5 qEU<XkWN-M]\$H~>|"F+  # MD5 key
8 MD5 ^TLS~EmRl}Jx~l$:^3o.  # MD5 key
9 MD5 'uL(75Gz_*S906yG$K_?  # MD5 key
10 MD5 ExZU8%k2h]`_S_cjLv+^  # MD5 key
11 SHA1 771fc6d1010f4e1d1fb4018de76d1c18826ccdea  # SHA1 key
12 SHA1 eac734f1acf1bf3556eb44aa2d6a71cc696009e2  # SHA1 key
13 SHA1 4a52b7c96900941dd84c2f3524a547db9dec2cb4  # SHA1 key
14 SHA1 ca6789d1a6623b61447e20aa4484a991b166f73c  # SHA1 key
15 SHA1 a685eb967977d90441486768f05cc6cb24581d98  # SHA1 key
16 SHA1 2a7d7e1b7e72d2083f3333575afaefc1945faa6b  # SHA1 key
17 SHA1 126fc66ec429e8002f0328990813c33f0e70f6a3  # SHA1 key
18 SHA1 287f749a2b4cd12535ae8d072f86edce9e28fa67  # SHA1 key
19 SHA1 2915015e44948758cf8a529513364fc5a852d320  # SHA1 key
20 SHA1 708a37feba30068e5919fd005c7d206c836460ef  # SHA1 key
21 ripemd160 foozleA
22 sha224 foozleB
23 sha256 foozleC
24 sha384 foozleD
25 sha512 foozleE

Here is ntpd parsing them, still looks good.
auth_setkey: key 25 type 674 len 7 666f6f7a6c6545
auth_setkey: key 24 type 673 len 7 666f6f7a6c6544
auth_setkey: key 23 type 672 len 7 666f6f7a6c6543
auth_setkey: key 22 type 675 len 7 666f6f7a6c6542
auth_setkey: key 21 type 117 len 7 666f6f7a6c6541
auth_setkey: key 20 type 64 len 20 708a37feba30068e5919fd005c7d206c836460ef
auth_setkey: key 19 type 64 len 20 2915015e44948758cf8a529513364fc5a852d320
auth_setkey: key 18 type 64 len 20 287f749a2b4cd12535ae8d072f86edce9e28fa67
auth_setkey: key 17 type 64 len 20 126fc66ec429e8002f0328990813c33f0e70f6a3
auth_setkey: key 16 type 64 len 20 2a7d7e1b7e72d2083f3333575afaefc1945faa6b
auth_setkey: key 15 type 64 len 20 a685eb967977d90441486768f05cc6cb24581d98
auth_setkey: key 14 type 64 len 20 ca6789d1a6623b61447e20aa4484a991b166f73c
auth_setkey: key 13 type 64 len 20 4a52b7c96900941dd84c2f3524a547db9dec2cb4
auth_setkey: key 12 type 64 len 20 eac734f1acf1bf3556eb44aa2d6a71cc696009e2
auth_setkey: key 11 type 64 len 20 771fc6d1010f4e1d1fb4018de76d1c18826ccdea
auth_setkey: key 10 type 4 len 20 45785a5538256b32685d605f535f636a4c762b5e
auth_setkey: key 9 type 4 len 20 27754c283735477a5f2a533930367947244b5f3f
auth_setkey: key 8 type 4 len 20 5e544c537e456d526c7d4a787e6c243a5e336f2e
auth_setkey: key 7 type 4 len 20 7145553c586b574e2d4d5d5c24487e3e7c22462b
auth_setkey: key 6 type 4 len 20 7a732261402772602651694e573e6968443b5946
auth_setkey: key 5 type 4 len 20 4c4f6044302e6533425f734755292f5b685c5b2c

Here is what openssl help says:
Message Digest commands (see the `dgst' command for more details)
md4               md5               rmd160            sha               
sha1        

However, in operation things get weird.  Md5 and sha1 are fine.  Ripemd160 is successful but I think that is just lucky because it has a 160bit digest that ends up looking like a sha1 mac.  However, I "think" because I don't have support in openssl, sha224, 256, and 384 don't even try to send MAC frames, just regular no auth.  So they look like they work but they have no MAC.  Sha512 actually generates a 64 byte mac and stuffs all of it in the frame so 68 bye HMAC (with key) but this gets parsed as an extension and fails.  

So what's up?  Is this like somewhere in the middle of development?  I remember discussions about have an extension field to either negotiate or at least identify digest algorithms but I don't think this is that.

Thanks.Greg


Greg Dowd
Principal Engineering Technologist, FTD
Microsemi 
3870 N. First St. | San Jose | CA 95134 | USA
Office: 408.964.7643
Email: greg.dowd at microchip.com
Company Website:  www.microsemi.com





More information about the questions mailing list