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

[TS Glassey]

Dale, why are you sending me a link to a soft-core blog site and what does this have to do with digital evidence and NTP's use therein?

Todd Glassey
  ----- Original Message ----- 
  From: Dale Matzke 
  To: TS Glassey 
  Sent: Wednesday, November 14, 2007 10:15 PM
  Subject: Re: [dhcwg] Digital Evidence Standards and a statement that this directly effects NTP and its use...



  http://www.bluestories.com 

  ----- Original Message ----
  From: TS Glassey <tglassey at earthlink.net>
  To: David L. Mills <mills at udel.edu>;  dhcwg at ietf.org
  Sent: Tuesday, November 13, 2007 12:15:54 PM
  Subject: [dhcwg] Digital Evidence Standards and a statement that this directly effects NTP and its use...

  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 


  _______________________________________________
  dhcwg mailing list
  dhcwg at ietf.org
  https://www1.ietf.org/mailman/listinfo/dhcwg





------------------------------------------------------------------------------
  Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.org/pipermail/ntpwg/attachments/20071115/d4cb79a0/attachment.html