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

["TS Glassey" <[e-mail]>]

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" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
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
> [e-mail]
> https://lists.ntp.org/mailman/listinfo/ntpwg 


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg