Skip to main content

Security Requirements of Time Protocols in Packet Switched Networks
draft-ietf-tictoc-security-requirements-12

Yes

(Brian Haberman)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Alissa Cooper)
(Jari Arkko)
(Martin Stiemerling)
(Richard Barnes)

Note: This ballot was opened for revision 11 and is now closed.

Brian Haberman Former IESG member
Yes
Yes (for -11) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2014-08-18 for -11) Unknown
I think Barry is likely correct about the time protocols themselves being normative references.

This document was a pleasure to review - very clear and well-organized for One Unskilled In The Art ...
Adrian Farrel Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2014-08-13 for -11) Unknown
I think that IEEE1588 and NTPv4 are normative references.
Jari Arkko Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2014-08-18 for -11) Unknown
neither 3.2.7 nor 3.2.2 3.2.4 or 5.3 describe actual dos attacks using the ntp protocol.

Those do involve spoofing client source address (of the victim) but rely on nothing other an asymmetry in the size of the response relative to the query.
Kathleen Moriarty Former IESG member
(was Discuss) No Objection
No Objection (2014-08-21 for -11) Unknown
Thanks for addressing the SecDir review.

I just have a question on the Confidentiality (5.8) part of the Security Considerations section, it says:

"Requirement Level

   The requirement level of this requirement is 'MAY' since it does not
   prevent severe threats, as discussed below."

That reads a bit oddly to me and I am wondering if there is a typo, maybe presents instead of prevents?
Martin Stiemerling Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2014-08-21 for -11) Unknown

- 2.4: defining e2e security as just meaning data integrity
without confidentiality is unusual enough that it should
probably be noted. Separately I'm surprised that you don't
include some form of origin authentication in your concept
of e2e security - why is that?

- 3.2: possible threat - ensure specific client(s) offset by
X (different X for each set you need to track) in order to
spot (or reduce search space for) those clients in other
protocols when timestamp are sent. Worth adding?  I'm not
sure if a mechanisms meeting the 5.9 requirement would or
would not be sure to mitigate this. (You could also advise
protocols emitting timing information to slighly perturb any
time signals they emit, to disguise any small but detectable
offset from the wall-clock time.) 

- 3.2: another possible threat: if a mobile node sends time
protocol requests at a specific frequency (e.g.  every N
seconds, at 283 ms past the second) then that can be used to
identify (or reduce the search space for) the mobile node
irrespective of crypto or address changes. (A similar thing
has been a real concern in vehicular networks btw. with the
basic safety message).  Those are probably not that big a
deal here and the migitation is probably just to tell
implementers to not do that, which is pretty simple:-)

- 3.2 - Similarly, if a node sends out complex time protocol
messages those might allow fingerprinting of the node
regardless of other changes. For example, it could be easy
to track a Brazilian node that's in Europe if it sends
queries out saying it mostly trusts something in .br.  Not
sure if that's as easy to deal with, perhaps the requirement
there is just that protocol developers think about it. (This
relates to Kathleen's discuss also probably.)

- 5.6.1: that requirement is stated as an operational
requirement, don't you need a protocol requirement here i.e.
to say that it MUST be possible to ensure keys are fresh?

- 5.10 - I wonder if there's not a case to be made for an
opportunistic mode, e.g. where one learns that some master
can be authenticated and thereafter requires that. In this
document I think such an opportunistic mode would maybe be a
MAY - the WG can think later if they figure that'd help
enough to be worthwhile. The reason to raise it now is thus
so as to not rule it out for later. I think this is
different from, and possibly much better than the hybrid
thing you have now and ought be much more deployable than a
"secure" mode (as in 5.10.1, and that's a bad term for that
section/mode btw).

- 7.5: Kerberos is notoriously more time-sensitive than PKI
stuff - why not mention it?