Dave,
I think the discussion is not as much as whether SHA is secure enough or not
but rather whether the current design of inferring the auth algo based on the
length scalable or not? At some point of time we have to allow NTP to use an
auth algo that has a digest size > 16 or 20 bytes. What needs to be done to get
us to that stage is what folks would like to hear.
John
________________________________
From: David L. Mills <[email protected]>
To: Danny Mayer <[email protected]>
Cc: "[email protected]" <[email protected]>; "[email protected]"
<[email protected]>
Sent: Tuesday, 13 December 2011, 22:09
Subject: Re: [ntpwg] [TICTOC] NTP Extension Field without Authentication
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
_______________________________________________
ntpwg mailing list
[email protected]
http://lists.ntp.org/listinfo/ntpwg
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
