Danny,
We are talking right past each other. Myy comments applied mainly to the
symmetric key cryptography, onlyincidently to Autokey. In symmetric key
cryptography the message digest algorithm is specified in the keys file;
there is no opportunity to negotiate following that. In Autokey the
signature and digest algorihtms are specified in the initial exchange;
the group key algorithm is negotiated. Obviously, all things could be
negotiated, but that is not the point of this message.
The fundamental requirements whether a MAC is present or not and whehter
one or more extension fields are present has been covered in several
previous messages. Limitations on the extension field and MAC
configuration have been discussed as well. I have nothing further to
add, other than a rewrite of the basic format with no backwards
compatibility. You are welcome to initiate a discussion on a possible
format revision.
Dave
Danny Mayer wrote:
However we are not just talking about Autokey. There are two questions:
1) Is a MAC really required if there is an some other extension field?;
2) How do you specify the MAC digest algorithm outside of an Autokey
extension?
So let's discuss the above without Autokey with the understanding that
Autokey may require changes to the RFC to specify how to deal with a MAC
digest algorithm specification.
Danny
On 12/14/2011 11:14 AM, David L. Mills wrote:
disambiguating them, then that needs to be added to the Autokey RFC.
Autokey requires a specific digest algorithm, or well defined ways of
of the Autokey specifications (RFC5906) but I don't believe so. If
I don't recall if the digest algorithm is specified for the MAC as part
Dave,
Danny,
Think of the message digest algorithm identifier as part of the key
defined in the keys file. Only the server and client know the key and
algorithm according to the key ID in the packet. There is no need for
negotiation and no need for the client to learn the digest algorithm
implicitly from the packet. Just to make life more interesting, in
Autokey the key is used only once. While not algorithm the
specification, there is no reason whey subsequent Autokey packets could
not use different digest algorithms.
I submit that NTP cryptographic vulnerability is a tough nut to crack.
Better a distributed DoS attack, then we get to talk about the rate
managment provisions and the KoD packet.
Dave
Danny Mayer wrote:
On 12/13/2011 11:56 PM, Dave Hart wrote:
Again you seem to be ignoring the point that a generic policy to avoid
MD5, or SHA1, is probably not applicable to NTP's use of those
algorithms. Fine, I'm not going to beat that drum anymore.
No, you are ignoring the point that when the government says don't use
MD5 or some other hashing algorithm in any software provided to the
government, you can't use it and you have to find a replacement for it.
Worse still some governments may say that you cannot use algorithm X.
Saying that it is probably not applicable is like sticking your head in
the sand; it doesn't solve the underlying problem.
You are mistaken in assuming ntpd detects the algorithm based on the
digest size. The algorithm is configured into both sides and not
communicated on the wire at all for symmetric authed NTP.
That assumes a lot, including the fact that each server communicating
with an single host may want to use different algorithms. Not signalling
which one is being used is a really bad idea and a very poor design.
Danny
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
