Hello Kurt, thanks for your comments. Your are right that the draft currently does not specifies that the server has to sign the message during cookie message exchange. We shall add this to the next version of the draft.
Dieter ---------------------------------- Physikalisch-Technische Bundesanstalt Dr. Dieter Sibold Q.42 - Serversysteme und Datenhaltung QM-Verantwortlicher der Stelle IT-Infrastruktur Bundesallee 100 D-38116 Braunschweig Tel: +49-531-592-84 20 E-Mail: [email protected] Von: Kurt Roeckx <[email protected]> An: "David L. Mills" <[email protected]> Kopie: NTP Working Group <[email protected]>, "[email protected]" <[email protected]> Datum: 07.08.2013 12:23 Betreff: Re: [ntpwg] security ID submitted for review Gesendet von: [email protected] Hi Dave, On Wed, Aug 07, 2013 at 01:01:47AM +0000, David L. Mills wrote: > Kurt, > > Thanks for your reply. As a window of history, the Autokey protocol > was devised during several walks in Regents Park, London, in 1996. > I thought the most significant hazzard was the replay of client > messages requiring extensive server cryptographic computations. At > that time, I did not think that a middle-man attack would be > significant. Both of those assumptions are probably inadvisable > today. > > One problem with Autokey is the assumption that secret keys for each > client can be manufactured using packet header fields and a hash of > a server private value. A middle-man can manipulate the header > fields compromising the client private key. There does not seem to > be a solution for this problem other than requiring server state. This proposal also generates a cookie based on the something the client sends and a secret in the server, which is then encrypted using the client's public key. The ID does not mention that this message is signed by the server, but Stephen's mail said it was. This part is important to avoid the man in the middle attack. So as result the client got a unique secret for him, and only the client and the server known it. It can also be sure that it really comes from the server, so that there can be no man in the middle attack. And the server doesn't need to keep state since it can calculate it again based on what the client sends him. > In the current Autokey design, the MAC computation covers the header > and all extension fields. However, the key used for the MAC > computation in packets with extension fields is not private. > Therefore, in a cut-and-paste attack, an intruder could mix and > match extension fields and simply recalculate the MAC. If the key is not private, by adding extentions to a packet an attacker can just generate anything he wants? > RFC 5906 defines the extension field including the filestamp and > timestamp. The filestamp was designed to reliably associate the > cryptographic media with the current version, as it can be > frequently changed. This might not be useful in current designs. > The timestamp field was designed to detect replays requiring > expensive cryptographic computations which could take up to a > second. However, the "call gap" (minimum headway) provisions nicely > deflect such attacks, so the timestamp field might not be useful in > current designs. Lastly, in the current design, each extension > field is separately signed at the time the data were constructed. > In current designs the signature might be computed at the time of I'm not sure I understand what you're trying to say. I'm not sure what the filestamps are used for. But I assume that for instance for the leap seconds you send when it was last updates. I guess you can sign this once and always send this signed in an extension, even when you're otherwise not using any encryption. Since you already signed it, the overhead of adding that extension is small. The problem I see with only sending the MAC over the ntp headers and not over the extensions is that the extensions can be removed or added and the client can't tell. So it could for instance be replaced with an old version of the extension. I think it's important that the MAC covers everything. Kurt _______________________________________________ ntpwg mailing list [email protected] http://lists.ntp.org/listinfo/ntpwg
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
