draft-ietf-tictoc-security-requirements-08.txt   draft-ietf-tictoc-security-requirements-09.txt 
TICTOC Working Group Tal Mizrahi TICTOC Working Group Tal Mizrahi
Internet Draft Marvell Internet Draft Marvell
Intended status: Informational Intended status: Informational
Expires: October 2014 April 30, 2014 Expires: December 2014 June 16, 2014
Security Requirements of Time Protocols Security Requirements of Time Protocols
in Packet Switched Networks in Packet Switched Networks
draft-ietf-tictoc-security-requirements-08.txt draft-ietf-tictoc-security-requirements-09.txt
Abstract Abstract
As time and frequency distribution protocols are becoming As time and frequency distribution protocols are becoming
increasingly common and widely deployed, concern about their exposure increasingly common and widely deployed, concern about their exposure
to various security threats is increasing. This document defines a to various security threats is increasing. This document defines a
set of security requirements for time protocols, focusing on the set of security requirements for time protocols, focusing on the
Precision Time Protocol (PTP) and the Network Time Protocol (NTP). Precision Time Protocol (PTP) and the Network Time Protocol (NTP).
This document also discusses the security impacts of time protocol This document also discusses the security impacts of time protocol
practices, the performance implications of external security practices, the performance implications of external security
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 30, 2014. This Internet-Draft will expire on December 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 19, line 47 skipping to change at page 19, line 47
from the originator of a protocol packet to the receiver. This allows from the originator of a protocol packet to the receiver. This allows
the receiver to directly validate the protocol packet without the the receiver to directly validate the protocol packet without the
ability of intermediate TCs to manipulate the packet. ability of intermediate TCs to manipulate the packet.
Since TCs need to modify the correctionField, a separate integrity Since TCs need to modify the correctionField, a separate integrity
protection mechanism is used specifically for the correctionField. protection mechanism is used specifically for the correctionField.
The end-to-end approach limits the TC's impact to the correctionField The end-to-end approach limits the TC's impact to the correctionField
alone, while the rest of the protocol packet is protected on an end- alone, while the rest of the protocol packet is protected on an end-
to-end basis. It should be noted that this approach is more difficult to-end basis. It should be noted that this approach is more difficult
to implement than the hop-by-hop approach, as it requires the to implement than the hop-by-hop approach, as it requires the
correctionField to be protected separately from the other fields of correctionField to be protected separately from the other fields of
the packet, possibly using different cryptographic mechanisms and the packet, possibly using different cryptographic mechanisms and
keys. keys.
5.3. Spoofing Prevention 5.3. Spoofing Prevention
Requirement Requirement
The security mechanism MUST provide a means to prevent master The security mechanism MUST provide a means to prevent master
spoofing. spoofing.
Requirement Requirement
skipping to change at page 32, line 31 skipping to change at page 32, line 31
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
12. References 12. References
12.1. Normative References 12.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W., [NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W.,
"Network Time Protocol Version 4: Protocol and "Network Time Protocol Version 4: Protocol and
Algorithms Specification", RFC 5905, June 2010. Algorithms Specification", RFC 5905, June 2010.
[AutoKey] Haberman, B., Mills, D., "Network Time Protocol [AutoKey] Haberman, B., Mills, D., "Network Time Protocol
Version 4: Autokey Specification", RFC 5906, June Version 4: Autokey Specification", RFC 5906, June
2010. 2010.
[IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society,
"1588 IEEE Standard for a Precision Clock "1588 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems Version 2", IEEE Standard, 2008. Control Systems Version 2", IEEE Standard, 2008.
12.2. Informative References
[Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R., [Traps] Treytl, A., Gaderer, G., Hirschler, B., Cohen, R.,
"Traps and pitfalls in secure clock synchronization" "Traps and pitfalls in secure clock synchronization"
in Proceedings of 2007 International Symposium for in Proceedings of 2007 International Symposium for
Precision Clock Synchronization for Measurement, Precision Clock Synchronization for Measurement,
Control and Communication, ISPCS 2007, pp. 18-24, Control and Communication, ISPCS 2007, pp. 18-24,
2007. 2007.
[TM] T. Mizrahi, "Time synchronization security using IPsec [TM] T. Mizrahi, "Time synchronization security using IPsec
and MACsec", ISPCS 2011, pp. 38-43, 2011. and MACsec", ISPCS 2011, pp. 38-43, 2011.
 End of changes. 7 change blocks. 
7 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/