[ntp:hackers] Findinterface

David L. Mills mills at udel.edu
Mon Jun 13 09:01:53 PDT 2005


Todd,

NSA waasn't smoking anything when I saw the first edition of the orange 
book in 1983. I don't remember if it had been declassified then or not. 
In any case, the 1985 edition apparently doesn't have the useful 
capability matrix I saw in the original edition.

In retrospect, the published criteria apply to a system, not a specific 
application in that system. I conclude that NTP can't be certified 
unless bundled with a specific operating system and hardware platform. 
So far as I remember, Secure Unix was a flop and only the Guardian 
system and Multinet Gateway had a chance.

I conclude orange is not a useful color at this time and the most useful 
exercise is developing a test plan. Want to have a go at it?

Dave

todd glassey wrote:

>----- Original Message ----- 
>From: "David L. Mills" <mills at udel.edu>
>Cc: "NTP Hackers" <hackers at ntp.org>
>Sent: Sunday, June 12, 2005 8:50 PM
>Subject: Re: [ntp:hackers] Findinterface
>
>
>
>>TOdd,
>>
>>Mat Bishop was the author of the code evaluation. I have his report
>>buried somewhere here. It is at least 20 yuears old.
>>
>
>Cool - lets see it.
>
>
>>As for the Orange Book, NSA wouldn't let me take a copy out of the
>>building, but I did manage to copy the page on evaluative criteria, also
>>buried in about a thousand briefing slides. What did you base your C2
>>claim on?
>>
>
>What were they smoking - Its on the web...
>http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html
>
>
>>Dave
>>
>>todd glassey wrote:
>>
>>
>>>----- Original Message ----- 
>>>From: "David L. Mills" <mills at udel.edu>
>>>Cc: "NTP Hackers" <hackers at ntp.org>
>>>Sent: Sunday, June 12, 2005 8:30 AM
>>>Subject: Re: [ntp:hackers] Findinterface
>>>
>>>
>>>
>>>
>>>
>>>>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?
>>>>
>>>>
>>>>
>>>CryptoAPI interface of some kind so that HW can uniformly be plugged into
>>>it.
>>>
>>>
>>>
>>>
>>>>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.
>>>>
>>>>
>>>>
>>>Yes...
>>>
>>>
>>>
>>>
>>>>NTP has already been audited by the IETF Security Task Force, which
>>>>found some flaws since corrected.
>>>>
>>>>
>>>>
>>>On what use models?
>>>
>>>
>>>
>>>
>>>>What metric do you suggest, the NSA
>>>>Orange Book?
>>>>
>>>>
>>>>
>>>The generic system was C2 - I suggest that the code footprint could
>>>
>easily
>
>>>be secured to B1 or better.
>>>
>>>
>>>
>>>
>>>>I think NTP is now some flavor of B.
>>>>
>>>>
>>>>
>>>How would you know? - What makes it this way and which environments.
>>>
>That's
>
>>>the problem - its "B1" in some specific environment based on the
>>>
>footprint
>
>>>of the executable and the environment's state.
>>>
>>>
>>>
>>>
>>>>With formal
>>>>correctness proofs it might even be some flavor of A, like the Multinet
>>>>Gateway.
>>>>
>>>>
>>>>
>>>I like that idea...
>>>
>>>
>>>
>>>
>>>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>_______________________________________________
>>>>hackers mailing list
>>>>hackers at support.ntp.org
>>>>https://support.ntp.org/mailman/listinfo/hackers
>>>>
>>>>
>>>>
>>_______________________________________________
>>hackers mailing list
>>hackers at support.ntp.org
>>https://support.ntp.org/mailman/listinfo/hackers
>>




More information about the hackers mailing list