[ntp:hackers] Findinterface

David L. Mills mills at udel.edu
Sun Jun 12 08:30:30 PDT 2005


Todd,

There is a variety of schemes that can be cooked from the digest, 
signature, certifidate and identity algorithms in Autokey, perhaps too 
many for a designated standard. I submit the most crucial component is 
the secure group concept. I would think that the first point of 
controversy. What else do you think is needed?

On the audit issue, a performance audit for accuracy is a nonstarter. A 
performance audit for security would be useful and I would welcome that. 
NTP has already been audited by the IETF Security Task Force, which 
found some flaws since corrected. What metric do you suggest, the NSA 
Orange Book? I think NTP is now some flavor of B. With formal 
correctness proofs it might even be some flavor of A, like the Multinet 
Gateway.

Dave

todd glassey wrote:

>Mayer -
>----- Original Message ----- 
>From: "mayer" <mayer at gis.net>
>To: "todd glassey" <todd.glassey at att.net>; "Paul Vixie" <paul at vix.com>;
>"Harlan Stenn" <stenn at www.ntp.org>
>Cc: "NTP Hackers" <hackers at ntp.org>; <mills at udel.edu>
>Sent: Saturday, June 11, 2005 4:39 PM
>Subject: Re: [ntp:hackers] Findinterface
>
>
>
>>----- Original Message Follows -----
>>
>>>Maybe I should say this again... "NTP cannot be secured" - the process
>>>of securing it makes in less accurate and installs an immediate
>>>uncertainty to the time data. I will as an auditor argue this and win
>>>in all instances. Plugging a UDP based protocol into a collision
>>>domain as a LAN also has problems.
>>>
>>>
>>I'm not sure I understand what you mean by this. There is an exchange
>>at the beginning of the association while the client verifies the
>>server's keys. After that there it just processes the MAC section in the
>>NTP packet every time it receives an NTP packet and there is no further
>>exchanges (except for once every 24 hours). Are you saying the
>>processing
>>the MAC takes longer and therefore reduces the accuracy or is there
>>something that I'm missing? Note that there's always some uncertainty
>>in the time data since there is a variable amount of time that the
>>system will take to process the packets depending on what else the
>>system is doing, not to mention the fact that the network may or may
>>not be congested. Processing the security data is the least of the
>>variabilities.
>>
>
>No I am saying AutoKEY isnt enough. Probably not a popular idea here on this
>list but I would like to see additional resources.
>
>
>>>What NTP really needs is performance standardization rather than huge
>>>efforts to secure the open Internet Transport of UDP data, which is a
>>>hopeless case from an Audit Perspective. This statement is something
>>>that the cryptographers in the group are going to rail up against,
>>>but the fact that they want to spend their time trying new variant of
>>>AutoKEY or in plugging x509 Certificates into NTP as some us have
>>>already done, myself included. What this all boils down to is that
>>>from an Audit perspective NTP is an At-Risk Protocol.
>>>
>>Performance standardization analysis IS needed but what has that got
>>to do with cyptography or authentication?
>>
>
>Nothing - there are separate points - sorry, thought that was self-evident.
>
>
>>NTP does NOT try to secure
>>the transport of the UDP data nor does it encrypt it. It only tries
>>to verify that it actually came from the server that it said it
>>came from which is very different. Or did I misunderstand what you
>>are saying?
>>
>
>No - you got it.
>
>
>>>What NTP really does need rather than huge amounts of work in evolving
>>>AutoKEY in NTP, is the commercial standardization as to "what specs
>>>the Uniform NTP Port should perform to" and whether there is a set of
>>>striated implementations that perform at different levels. This is
>>>even more important for those who want to standardize or characterize
>>>systems like Symmetricom's 2100 or other appliance style NTP Servers.
>>>
>>>
>>Standardization of the NTP v4 protocol is under way. Autokey will be
>>a separate part of that effort and be a separate document from what
>>I understand of the IETF WG charter. I'm not sure what you mean by
>>commercial standardization, IETF RFCs or something else? Also what
>>do you meant by "Uniform NTP Port" and I assume you mean "conform to"
>>rather than "perform to"?
>>
>>Characterization of a refclock is very different from the
>>characterization of NTP and I think that's more a matter of
>>the manufacturers have a standard to follow than NTP to
>>have a standard.
>>
>>
>>>This is the type of information that the Audit Community needs and
>>>they ultimately will determine how successful the NTP consortia is in
>>>its goals to standardize NTP.
>>>
>>>Todd Glassey, CISM, CIFI
>>>
>>>
>>Maybe you can clarify what you are saying as I'm really confused
>>by it.
>>
>>Danny
>>
>>




More information about the hackers mailing list