Crypto, passwords

[Eric S. Raymond]

Hal Murray via devel <devel at ntpsec.org>:
> Does anybody use shared keys between NTP servers?

That's the kind of thing I expect *you* to know.  I sure don't.

> MD5 is no longer considered safe.
> Is SHA1 considered safe?  What other types should we test and/or suggest 
> people use?

No, SHA1 is no longer considered safe.  The first collision was generated
early last year. The git team is considering a move to SHA-2 (I think - I
might be out of date on this.)

> ntpq needs a password to modify things.  (and examine some things)
> 
> I don't use passwords with ntpq.  It's got code to read the local keys file 
> and if looking at localhost, it looks in ntp.conf to find the control key.  I 
> assume you can type in a password.  Can you type in hex passwords?  Is there 
> a standard recipe for converting a text password to hex?

No and no.

> Should we fix the code that reads keys to allow text for other types than MD5?

I've had this on my mind for a while, but it seems like the kind of
thing where we might want to float a draft RFC before implementing.

We need to be careful here because the existing implementation has
backed us into an odd corner; the only way to distinguish among hash
types is by the length of the hash.

        # Parse the extension field if present. We figure out whether
        # an extension field is present by measuring the MAC size. If
        # the number of 4-octet words following the packet header is
        # 0, no MAC is present and the packet is not authenticated. If
        # 1, the packet is a crypto-NAK; if 3, the packet is
        # authenticated with DES; if 5, the packet is authenticated
        # with MD5; if 6, the packet is authenticated with SHA1. If 2
        # or 4, the packet is a runt and discarded forthwith. If
        # greater than 6, an extension field is present, so we
        # subtract the length of the field and go around again.

We've only got 3 potential slots for wedging in another hash type there
and each of them is problematic for various reasons.  Best course would
probably be to re-use the DES slot and (gross hack) pad the hash to the
right length.  That's why I think an amendment RFC is probably needed.

This is one of the top couple reasons that designing NTPv5 is on my
radar, up there with refid hash collisions on IPv6 and the cross-epoch
problem.  It is not in much doubt that whetever new hash we add will
eventually be obsolesced itself, etcetera.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.