Danny,
I don't know where this is going. I mentioned some constraints in my
recent message. I have no agenda for the spec; if it can be warped for
some goal or other, that's fine. However, the parsing design assumes the
packet format checks are independent of the contents of the extension
field. That doesn't leave much latitude for MACs longer than 6 words.
Apparently, we are having the same discussion about the vulnerability of
the SHA family as we had with MD5. The issue id whether we can concoct
an NTP header that has correct digest but altered header fields that are
acceptable to the client. That is a tall order, as I discussed in the
NTP Security Analysis cited earlier.
Dave
Danny Mayer wrote:
On 12/13/2011 12:33 AM, Bhatia, Manav (Manav) wrote:
Ok, let me put it this way. I was trying to propose extending NTP to
support having an arbitrary MAC size. I was also trying to
push HMAC-SHA-1, instead of the regular SHA-1.
That's one possibility. Another is SHA-2. That's why we need
to revisit the question.
Security vulnerabilities found in SHA-1 and SHA-2 don't apply to
HMAC-SHA-1 and HMAC-SHA-2. I understand that the known attacks on SHA-1
and SHA-2 will not apply to NTP (like most IETF protocols) but that
doesn't mean that we should go ahead using them. The security ADs I
believe are insistent on the HMAC construct to be used. To cite an
example, Bidirectional Forwarding Detection (BFD) protocol already
supports SHA-1. It is however being upgraded to support the HMAC version
of the SHA algorithms. I thus don't recommend going ahead with SHA-2.
Sorry, I managed to miscommunicate what I meant. If HMAC is what is
needed to be used then we should use it. I just threw out SHA-2 as an
example. It wasn't meant as a specific recommendation. There are several
parts to the requirements about the MAC:
1) Signalling by the sender what algorithm to use for the MAC in the packet;
2) Signalling by the requestor what algorithms it can accept since the
two ends may have support for different algorithms.
3) What to do in the case where there is no algorithm in common.
Danny
Cheers, Manav
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
