Subject: Re: [TICTOC] [ntpwg] NTP Extension Field without Authentication

From: Cui Yang <[email-masked]>
Date: Wed, 14 Dec 2011 08:33:58 +0000

Hi, Dave,

So, if ntpd detects the algorithm not by checking the digest size, then it is easier to make some extension on MAC size.
We could have more scalability and agility. 
Am I right?

Cheers,
Yang

>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.
>
>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.
>
>Cheers,
>Dave Hart

On Wed, Dec 14, 2011 at 04:52, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> **
> Hi Dave,
>
> I agree. Inspite of this we need to work on a generic mechanism because
> best operational practices might start deprecating MD5 and SHA1, and
> recommend some other authentication algo to be used in the future.
> Moreover, detecting auth algo based on the packet size is absurd because
> people use truncated hashes all the time. One could
> truncate a HMAC-SHA-256 digest to 20 bytes (or even 16). Thus even if there
> is no burning need today, we should start working on defining a generic way
> to secure NTP packets going forward.
>
> Cheers, Manna
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Dave Hart
> *Sent:* Wednesday, December 14, 2011 8:40 AM
> *To:* John Smith
> *Cc:* [email-masked]; [email-masked]; David L. Mills
> *Subject:* Re: [TICTOC] [ntpwg] NTP Extension Field without Authentication
>
> What Dr. Mills suggests is if you can't MITM NTP exchanges secured by
> 20-octet digests, there is no need for a larger digest.  This is why he
> harkens back to the discussion of MD5 flaws and how they might be exploited
> in the context of NTP authentication.  NTP has the advantage of time -- the
> MITM has to not only find a correct digest for the modified packet, he must
> do so fast enough that the client will not find reason to ignore the
> response.
>
> There is no doubt it is ugly that there are two different ad-hoc
> extensions to the basic NTPv4 packet defined, both detected solely by the
> received datagram size, and unfortunate that means extensions must be at
> least 7 x 32 bits long to avoid ambiguity.  One might hope any NTPv5 would
> include indication in the basic packet headers of whether authentication
> and/or extensions are used in a way that avoids such ambiguity.
>
> Cheers,
> Dave Hart
>
> On Tue, Dec 13, 2011 at 20:45, John Smith <[email-masked]>wrote:
>
>>  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-masked]>
>> *To:* Danny Mayer <[email-masked]>
>> *Cc:* "[email-masked]" <[email-masked]>; "[email-masked]" <
>> [email-masked]>
>> *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-masked]
>> http://lists.ntp.org/listinfo/ntpwg
>>
>>
>> _______________________________________________
>> TICTOC mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tictoc
>>
>>
>

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Fri, 16 Dec 2011 03:23:46 +0000

Just find the following statement in the section 5 of RFC5906 for your information..^_^

" Parameter exchange.  The request includes the client host name and
      status word; the response includes the server host name and status
      word.  The status word specifies the digest/signature scheme to
      use and the identity schemes supported."

>
> 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.