Tal,
Looks much better. Some specific suggestions:
3.1 There is a third category of attacker: one who attacks a clock
device, rather than the protocol. I would think that this should be
included for completeness, but taken out of scope. Thus:
--
3.1.3 Protocol vs Device Attackers
MITM and Packet Injection attacks exploit vulnerabilities in time
synchronization protocols and the underlying network(s) that support them.
A separate category of attacks exploits vulnerabilities in devices; for
example, by installing malware, obtaining credentials to reconfigure the
device, or stealing encryption keys in order to enable insider attacks.
Requirements for securing against device attacks are outside the scope
of this memo, except to the extent that they enable Insider attacks.
--
Alternatively, we could create a requirement later on that requires
"good hygiene" to prevent these kinds of attacks.
Global change: "attackee" to "victim" (or "intended victim"). "Attackee"
doesn't seem to be in the dictionary.
4.1 Discussion, 4.1.1: clarification needed. Is the intent of 4.1 that
authentication covers both identification AND authorization, or that is
covers identification OR authorization? If the latter, does 4.1.1 imply
that the slaves can authenticate the identity but not the authorization
of the master? And if the former, the words are misleading. If what
is intended is what I think is intended, then here are some improved words:
"
In the context of this document, authentication refers to both:
o Identification: verifying the identity of the peer clock; and,
"
" 4.1.1 Authentication of Masters
Requirement
The security mechanism MUST support an authentication mechanism,
allowing slave clocks to authenticate the identity and authorization of
master clocks.
"
4.2 change "WHO" to "which device" ("who" implies a person).
4.2.1.2 Change "It should be noted that this approach is more difficult
to implement than the hop-by-hop approach, as it requires separate
layers of protection for the correctionField and for the rest of the
packet, using different cryptographic mechanisms and keys." to "It
should be noted that this approach is more difficult to implement than
the hop-by-hop approach, as it requires the correctionField to be
protected separately from the other fields of the packet, possibly
using different cryptographic mechanisms and keys." How much benefit
would you get from using different mechanisms and keys?
4.5.1 Change "cryptographich" to "cryptographic" (typo)
4.5.3 Change "The association protocol MUST be invoked periodically,
where each instance of the association protocol MUST produce a different
session key." to "The association protocol MUST be periodically invoked
to produce a fresh session key."
While on this subject... shouldn't it be possible to revoke or force
refresh session keys if a compromise is detected?
4.7 If traffic analysis attacks were a concern, there certainly are
mechanisms (random padding of encrypted packets, random dummy packets)
to protect against them. Is the point here that traffic analysis
attacks are not a consideration?
6.3 Change "that are exposed to the security keys" to "that possess the
security keys".
7 Change "Although this is a cardinal element in any security system, it
is not a security requirement, and is thus not described here." to
"Although this is an essential element of any security system, it is
outside the scope of this document".
Thanks much for the credit!
Regards
Dan Grossman
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
