[ntpwg] Stronger symmetric NTP authentication

Thu Dec 4 20:48:11 UTC 2008

I realize that. But the point I am making is that if we can change the 
  format of the packet, then adding longer MAC hashes is trivial, just 
make the field bigger and add whatever you need to get to work. So, I 
presume that the discussion in this thread is how to do this in a 
backwards compatible manner within the existing format.

Danny Mayer wrote:
> Brian Utterback wrote:
>> Wasn't the whole point of this discussion about how to do it without
>> changing (or not incompatibly changing) the protocol? If we are going to
>> allow a change in the protocol, then simply make the MAC field variable
>> length we're pretty much done.
>>
> 
> No, you also have to identify the digest type or you will have
> interoperability issues. it's not just a matter of specifying the MAC
> field length.
> 
> Danny
> 
>> Danny Mayer wrote:
>>> In addition this would require an update to the NTPv4 protocol.
>>>
>>> Danny
>>> David L. Mills wrote:
>>>> Brian,
>>>>
>>>> Publish my list? At the top is work for JPL on time synchronization
>>>> in space, followed closely by a second edition of my book. At the
>>>> moment, there is nothing about NTP on that list, but that could change.
>>>>
>>>> The work to bring up a 20-octet digest is messy. In principle it is
>>>> easy, as the required crypto code is already available in OpenSSL and
>>>> the NTP crypto interface is the same. However, the ick comes in the
>>>> build and configuration code and interaction with various defines
>>>> scattered all over the code.
>>>>
>>>> For instance, the OPENSSL define is lit when the OpenSSL library is
>>>> present and in that case lights up Autokey. Probably, if you need
>>>> only HMAC and don't want Autoke, that has to change. Also, it could
>>>> be that somebody wants HMAC with Autokey.
>>>>
>>>> Next, the crypto command is used to configure Autokey now. Some
>>>> change to th econfiguration syntax and semantics would need to be
>>>> done to configure HMAC separatly from the digest/signature
>>>> combinations now supported. Those combinations are built in the
>>>> OpenSSL library and passed transparently by th econfiguration code..
>>>>
>>>> Next, some considerations need to be implemented to handle cases
>>>> where the digests are mismatched. An innocent client equipped with
>>>> both MD5 and HMAC would need to automatically reconfigure when
>>>> presented with one or the other. This might apply also if other
>>>> digest algorithms were available.
>>>>
>>>> Next, the key cache code would need to be modified to support
>>>> 20-octet keys. This is in principle not hard, but needs review. My
>>>> approach would be to allow keys of any length independent of digest
>>>> algorithm, but that requires overhaul of the cache code.
>>>>
>>>> I'm really opposed to a hack; the issues should be thought through
>>>> and carefully integrated in a seamless design.
>>>>
>>>> Dave
>>>>
>>>> Brian Utterback wrote:
>>>>
>>>>> I happen to agree with you Dave. We don't need to implement this
>>>>> ASAP. On the other hand, you say that the design has provisions to
>>>>> support 20-octet digests, but that it isn't high on the list.
>>>>>
>>>>>
>>>>> I would like to suggest that you publish your list and provide the
>>>>> notes you have on the line items. The beauty of open source is that
>>>>> with enough hands, "all problems are shallow". Keep the list to
>>>>> yourself, and one or two of the top items may get implemented.
>>>>> Publish the list and probably two or three times as many will
>>>>> eventually happen, although not necessarily in your priority order.
>>>>> Their are hands available to you Dave, if you would just allow them
>>>>> to help.
>>>>>
>>>>>
>>>>> David L. Mills wrote:
>>>>>
>>>>>> Manav,
>>>>>>
>>>>>>
>>>>>> Will you read my messages again? I don't disagree it would be a
>>>>>> good idea to implement a 20-octet digest; in fact, as I said
>>>>>> previously, there are already provisions for that in the design to
>>>>>> suppor that. However, in the wisdom of good engineering design and
>>>>>> utilization of current resources, this is not likely to be done
>>>>>> soon. There are lots of other projects of importance in the
>>>>>> evolution of NTP and this is not one of urgent priority. An
>>>>>> advocacy to implement a 20-octet digest based purely on he
>>>>>> perceived hazard of possible masquerade without consideration of
>>>>>> the overall security hazard is simply not a good engineering strategy.
>>>>>>
>>>>>>
>>>>>> If your point is that NIST says SHA is good and MD5 is bad based on
>>>>>> nothing other than demonstration that it is possible so spoof a
>>>>>> digest with a contrived but necessarily invalid NTP message, then I
>>>>>> suggest there is something seriously wrong with the security
>>>>>> analysis. This point is stressed in the course I teach on computer
>>>>>> security.
>>>>>>
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>
>>>>>> DaeBhatia, Manav (Manav) wrote:
>>>>>>
>>>>>>
>>>>>>> Tony,
>>>>>>>
>>>>>>>
>>>>>>>> This is not applicable to most usages of HMAC-MD5 for two
>>>>>>>>
>>>>>>>> very good reasons:
>>>>>>>>
>>>>>>> If you read draft-ietf-ntp-ntpv4-proto-11 you will realize that
>>>>>>> NTP uses
>>>>>>>
>>>>>>> MD5 and not HMAC-MD5.
>>>>>>>
>>>>>>>
>>>>>>> I totally agree that the attacks may not necessarily result in direct
>>>>>>>
>>>>>>> vulnerabilities in MD5 as used in NTP authentication purposes,
>>>>>>> because
>>>>>>>
>>>>>>> the colliding message may not necessarily be a syntactically correct
>>>>>>>
>>>>>>> protocol packet. However, there is a need felt to move away from MD5
>>>>>>>
>>>>>>> towards more complex and difficult to break hash algorithms and I was
>>>>>>>
>>>>>>> just trying to propose an extension that does just that. One cannot
>>>>>>>
>>>>>>> always assume that the authentication data would *always* be just 16
>>>>>>>
>>>>>>> octets (unless somebody is thinking of truncating the SHA hash :))
>>>>>>>
>>>>>>>
>>>>>>> At the very least, NTP should be using the HMAC construct along
>>>>>>> with MD5
>>>>>>>
>>>>>>> as against plain MD5 that the spec mandates.
>>>>>>>
>>>>>>>
>>>>>>> Cheers, Manav
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>>
>>>>>>>> From: Tony Li [mailto:tony.li at tony.li]
>>>>>>>>
>>>>>>>> Sent: Tuesday, December 02, 2008 8.26 AM
>>>>>>>>
>>>>>>>> To: Bhatia, Manav (Manav); 'David L. Mills'
>>>>>>>>
>>>>>>>> Cc: ntpwg at lists.ntp.org
>>>>>>>>
>>>>>>>> Subject: RE: [ntpwg] Stronger symmetric NTP authentication
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>>
>>>>>>>> |Current NTP specs provide provision for only MD5 digests (16
>>>>>>>> octets).
>>>>>>>>
>>>>>>>> |This is not good enough, as there have been attacks found
>>>>>>>> against MD5
>>>>>>>>
>>>>>>>> |and the IETF community is moving away from this towards stronger
>>>>>>>> hash
>>>>>>>>
>>>>>>>> |algorithms (HMAC-SHA-1, HMAC-SHA-224, etc).
>>>>>>>>
>>>>>>>>
>>>>>>>> This is vastly misleading. The literature documents the
>>>>>>>>
>>>>>>>> ability to find
>>>>>>>>
>>>>>>>> collisions against straight MD5 hashing. Thus, given a
>>>>>>>>
>>>>>>>> plaintext block and
>>>>>>>>
>>>>>>>> a hash result, it is possible to compute a specific alternate
>>>>>>>>
>>>>>>>> plaintext
>>>>>>>>
>>>>>>>> block that would produce the same hash result.
>>>>>>>>
>>>>>>>>
>>>>>>>> This is not applicable to most usages of HMAC-MD5 for two
>>>>>>>>
>>>>>>>> very good reasons:
>>>>>>>>
>>>>>>>> first, there is typically a password or other key material
>>>>>>>>
>>>>>>>> concatenated with
>>>>>>>>
>>>>>>>> the plaintext block before hashing. The password is presumably not
>>>>>>>>
>>>>>>>> available to the attacker. [If it is, the algorithm is
>>>>>>>>
>>>>>>>> irrelevant. ;-)]
>>>>>>>>
>>>>>>>> No one has demonstrated a technique for determining a
>>>>>>>>
>>>>>>>> collision to a fixed
>>>>>>>>
>>>>>>>> plaintext block modification that is also hashed by key
>>>>>>>>
>>>>>>>> material. Thus,
>>>>>>>>
>>>>>>>> given a valid packet, there is still no documented way to
>>>>>>>>
>>>>>>>> tweak that packet
>>>>>>>>
>>>>>>>> and have it pass authentication.
>>>>>>>>
>>>>>>>>
>>>>>>>> Second, no one has demonstrated the ability to generate valid
>>>>>>>>
>>>>>>>> hashes of
>>>>>>>>
>>>>>>>> plaintext blocks and key material without the actual access to
>>>>>>>> the key
>>>>>>>>
>>>>>>>> material. Instead, the alternate blocks that are generated
>>>>>>>>
>>>>>>>> are unlikely to
>>>>>>>>
>>>>>>>> be valid protocol structures in the first place, result in
>>>>>>>>
>>>>>>>> parsing errors in
>>>>>>>>
>>>>>>>> the protocol. Thus, there is no way to wholly forge a packet
>>>>>>>>
>>>>>>>> and generate
>>>>>>>>
>>>>>>>> correct authentication for it without the key.
>>>>>>>>
>>>>>>>>
>>>>>>>> That said, as always with security, there is no such thing as
>>>>>>>>
>>>>>>>> a perfect
>>>>>>>>
>>>>>>>> algorithm and increasing the available algorithms is always a
>>>>>>>>
>>>>>>>> good thing.
>>>>>>>>
>>>>>>>> However, it is a vast misrepresentation to suggest that this
>>>>>>>>
>>>>>>>> is a practical
>>>>>>>>
>>>>>>>> necessity today. There is one single (tho large ;-) customer
>>>>>>>>
>>>>>>>> that truly
>>>>>>>>
>>>>>>>> requires SHA algorithms today. BTW, HMAC-SHA-1 has been
>>>>>>>>
>>>>>>>> broken and the
>>>>>>>>
>>>>>>>> customer is interested in the larger values.
>>>>>>>>
>>>>>>>>
>>>>>>>> Tony
>>>>>>>>
>>>>>>>>
>>>>>>>> P.s. This same scare tactic has been used in other IETF WG's.
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>> ntpwg mailing list
>>>>>>>
>>>>>>> ntpwg at lists.ntp.org
>>>>>>>
>>>>>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>> ntpwg mailing list
>>>>>>
>>>>>> ntpwg at lists.ntp.org
>>>>>>
>>>>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>>>>
>>>> _______________________________________________
>>>> ntpwg mailing list
>>>> ntpwg at lists.ntp.org
>>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>>
>>>>
>>> _______________________________________________
>>> ntpwg mailing list
>>> ntpwg at lists.ntp.org
>>> https://lists.ntp.org/mailman/listinfo/ntpwg
> 

-- 
blu

"Murderous organizations have increased in size and scope; they are
more daring, they are served by the most terrible weapons offered by
modern science, and the world is nowadays threatened by new forces
which, if recklessly unchained, may some day wreck universal
destruction."  - Arthur Griffith, 1898
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom