[ntpwg] Digital Evidence Standards and a statement that this directly effects NTP and its use...

[David L. Mills]

Ted,

There may be much merit in the case you cite; however, this is a 
volunteer group and neither a cabal of lawyers nor capable of high 
finance. If you have a specific plan, are willing to direct and 
contribute to it and suffient labor is available, let's do it. If you 
have very specific proposals that can be implemented without serious 
committment of effort, let's hear that, too. Better yet, find a lawyer 
needing to fill out his required 100 hours of pro-bono time per year and 
have him translate your legal issues to actionable projects.

Dave

TS Glassey wrote:

> Dave -
> There is ANOTHER issue facing this WG and that is that just like the 
> "description's" of the NTP Process the AutoKEY system needs to be 
> accountable to a standard which allows data captured from such a 
> source to be admitted in a court of law and now that there are formal 
> standards many of the cool methods of delivering time over networks 
> from a physics perspective dont mean squat now to the Courts.
>
> The case that set this standard was called Lorraine v Markel CIVIL 
> ACTION NO. PWG-06-1893 and it came out of the US District Court in 
> Maryland on May 4th 2007 from a Judge (a Chief Magistrate Judge) by 
> the name of Paul Grimm. Google the actual ruling here: 
> http://www.google.com/search?q=lorraine+v+markel&rls=com.microsoft:en-us:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7GGLF 
>
>
> Bluntly, the world changed a tad on May 4th and while this effort is 
> pointed at the physics of operating NTP, these new controls impact any 
> work with any other Standardized Protocol as well... What this means 
> to people who NTP is a part of their commercial offering, is that they 
> MUST apply these new standards to this code and its support as well, 
> or they must use their own internal code-base's rather than depending 
> on one here. I think this ruling re-set the bar heighth, and it is now 
> much higher - even for an Academic Entity. As to how this effects this 
> WG, we need to build tools that are capable of being used in these key 
> application contexts or this protocol will likely be ultimately replaced.
>
> Just my two cents,
>
> Todd Glassey
>
> ----- Original Message ----- From: "David L. Mills" <mills at udel.edu>
> To: <ntpwg at lists.ntp.org>; <dhcwg at ietf.org>
> Sent: Monday, November 12, 2007 7:33 PM
> Subject: Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6
>
>
>> Brian,
>>
>> Roaming laptops is what NTP Autokey is designed for. All a properly
>> configued laptop would not need anything except a flag that says to use
>> it and possibly the public group key. Heck with NTP; use Autokey to
>> authenticate the server for anything.
>>
>> Dave
>>
>> Brian Utterback wrote:
>>
>>>
>>>
>>> David L. Mills wrote:
>>>
>>>> Brian,
>>>>
>>>> My model about the keys is that the DHCP server would supply a key ID
>>>> for the NTP server(s) as configured, but not the keys themselves. The
>>>> keys would have to be configured for the NTP server and client
>>>> separately. The DHCP server would be responsible only for the opaque
>>>> key ID.
>>>>
>>>
>>> I see what you mean, but I am not sure about the use case here.
>>> Certainly if the keys are pre-configured on both the clients and the
>>> servers, then the key id is a must.  But I am concerned about the
>>> roaming laptop mode here. If I bring my laptop to a network, I would
>>> like to be able to get enough info from the DHCP server to allow me
>>> to securely connect to the server and have it be authenticated. Perhaps
>>> a public key distribution scheme?
>>>
>>>> There is an issue about the security of the DFCP server itself; that
>>>> is another issue. I'm assuming the DHCP server is behind the firewall.
>>>
>>>
>>>
>>> Right. Out of the realm of our discussion.
>>>
>>>>
>>>> The mode specification could be any of the valid NTP modes. If client
>>>> (3) it would be an ordinary client/server association. A means would
>>>> be necessary to specify broadcast client, as that is not a mode in
>>>> the strict sense. It could be symmetric active (1), in which case the
>>>> victim would initiate that type association. To specify symmetric
>>>> passive (2) means that the victim should wait for a symmetric active
>>>> (1) packet. This does not seem useful.
>>>
>>>
>>>
>>> If you get a broadcast address to use then you should be a broadcast
>>> client. I don't see the usefulness of a DHCP client being a symmetric
>>> anything. Perhaps this is a failure of imagination on my part.
>>>
>>>
>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwg at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/ntpwg 
>
>