draft-ietf-tictoc-security-requirements-07.txt   draft-ietf-tictoc-security-requirements-08.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 23, 2014 Expires: October 2014 April 30, 2014
Security Requirements of Time Protocols Security Requirements of Time Protocols
in Packet Switched Networks in Packet Switched Networks
draft-ietf-tictoc-security-requirements-07.txt draft-ietf-tictoc-security-requirements-08.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 23, 2014. This Internet-Draft will expire on October 30, 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 3, line 12 skipping to change at page 3, line 12
(Chain of Trust) ......................................... 15 (Chain of Trust) ......................................... 15
5.1.3. Authentication and Authorization of Slaves ........ 15 5.1.3. Authentication and Authorization of Slaves ........ 15
5.1.4. PTP: Authentication and Authorization of P2P TCs by the 5.1.4. PTP: Authentication and Authorization of P2P TCs by the
Master ................................................... 16 Master ................................................... 16
5.1.5. PTP: Authentication and Authorization of Control 5.1.5. PTP: Authentication and Authorization of Control
Messages ................................................. 17 Messages ................................................. 17
5.2. Protocol Packet Integrity .............................. 18 5.2. Protocol Packet Integrity .............................. 18
5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 19 5.2.1. PTP: Hop-by-hop vs. End-to-end Integrity Protection 19
5.2.1.1. Hop-by-Hop Integrity Protection .............. 19 5.2.1.1. Hop-by-Hop Integrity Protection .............. 19
5.2.1.2. End-to-End Integrity Protection .............. 19 5.2.1.2. End-to-End Integrity Protection .............. 19
5.3. Availability ........................................... 20 5.3. Spoofing Prevention .................................... 20
5.4. Replay Protection ...................................... 20 5.4. Availability ........................................... 20
5.5. Cryptographic Keys and Security Associations ........... 21 5.5. Replay Protection ...................................... 21
5.5.1. Key Freshness ..................................... 21 5.6. Cryptographic Keys and Security Associations ........... 22
5.5.2. Security Association .............................. 21 5.6.1. Key Freshness ..................................... 22
5.5.3. Unicast and Multicast Associations ................ 22 5.6.2. Security Association .............................. 22
5.6. Performance ............................................ 22 5.6.3. Unicast and Multicast Associations ................ 23
5.7. Confidentiality......................................... 23 5.7. Performance ............................................ 23
5.8. Protection against Packet Delay and Interception Attacks 24 5.8. Confidentiality......................................... 24
5.9. Combining Secured with Unsecured Nodes ................. 25 5.9. Protection against Packet Delay and Interception Attacks 25
5.9.1. Secure Mode ....................................... 25 5.10. Combining Secured with Unsecured Nodes ................ 25
5.9.2. Hybrid Mode ....................................... 25 5.10.1. Secure Mode ...................................... 26
6. Summary of Requirements ..................................... 26 5.10.2. Hybrid Mode ...................................... 26
7. Additional security implications ............................ 28 6. Summary of Requirements ..................................... 27
7.1. Security and on-the-fly Timestamping ................... 28 7. Additional security implications ............................ 29
7.2. PTP: Security and Two-Step Timestamping ................ 28 7.1. Security and on-the-fly Timestamping ................... 29
7.3. Intermediate Clocks .................................... 29 7.2. PTP: Security and Two-Step Timestamping ................ 29
7.4. External Security Protocols and Time Protocols.......... 29 7.3. Intermediate Clocks .................................... 30
7.5. External Security Services Requiring Time .............. 30 7.4. External Security Protocols and Time Protocols.......... 30
7.5.1. Timestamped Certificates .......................... 30 7.5. External Security Services Requiring Time .............. 31
7.5.2. Time Changes and Replay Attacks ................... 30 7.5.1. Timestamped Certificates .......................... 31
7.5.2. Time Changes and Replay Attacks ................... 31
8. Issues for Further Discussion ............................... 31 8. Issues for Further Discussion ............................... 31
9. Security Considerations ..................................... 31 9. Security Considerations ..................................... 32
10. IANA Considerations......................................... 31 10. IANA Considerations......................................... 32
11. Acknowledgments ............................................ 31 11. Acknowledgments ............................................ 32
12. References ................................................. 31 12. References ................................................. 32
12.1. Normative References .................................. 31 12.1. Normative References .................................. 32
12.2. Informative References ................................ 32 12.2. Informative References ................................ 32
13. Contributing Authors ....................................... 33 13. Contributing Authors ....................................... 34
1. Introduction 1. Introduction
As time protocols are becoming increasingly common and widely As time protocols are becoming increasingly common and widely
deployed, concern about the resulting exposure to various security deployed, concern about the resulting exposure to various security
threats is increasing. If a time protocol is compromised, the threats is increasing. If a time protocol is compromised, the
applications it serves are prone to a range of possible attacks applications it serves are prone to a range of possible attacks
including Denial-of-Service (DoS) or incorrect behavior. including Denial-of-Service (DoS) or incorrect behavior.
This document focuses on the security aspects of the Precision Time This document focuses on the security aspects of the Precision Time
skipping to change at page 15, line 46 skipping to change at page 15, line 46
receives time information through a TC, it must authenticate the TC receives time information through a TC, it must authenticate the TC
it is attached to, as well as authenticate the master it receives the it is attached to, as well as authenticate the master it receives the
time information from, as per Section 5.1.1. Similarly, if a TC time information from, as per Section 5.1.1. Similarly, if a TC
receives time information through an attached TC, it must receives time information through an attached TC, it must
authenticate the attached TC. authenticate the attached TC.
5.1.3. Authentication and Authorization of Slaves 5.1.3. Authentication and Authorization of Slaves
Requirement Requirement
The security mechanism MUST provide a means for a master to The security mechanism MAY provide a means for a master to
authenticate its slaves. authenticate its slaves.
Requirement Requirement
The security mechanism MAY provide a means for a master to verify The security mechanism MAY provide a means for a master to verify
that the sender of a protocol packet is authorized to send a packet that the sender of a protocol packet is authorized to send a packet
of this type. of this type.
Requirement Level Requirement Level
The authentication requirement in this subsection prevents DoS The requirement in this subsection prevents DoS attacks against the
attacks against the master (Section 3.2.9.), as well as spoofing master (Section 3.2.9.).
attacks (Section 3.2.2.). A spoofing attack, such as the second
example in Section 3.2.2. , is easy to implement and has a high
impact, and therefore the requirement level is 'MUST'.
The authorization requirement in this subsection only mitigates DoS The requirement level of this requirement is 'MAY' since:
attacks against the master (Section 3.2.9.). The requirement level
is 'MAY', since the absence of this requirement has a relatively low o Its low impact, i.e., in the absence of this requirement the
impact, i.e., in the absence of this requirement the protocol is only protocol is only exposed to DoS.
exposed to DoS. Note that Section 5.1.1. specifies authorization as
a 'MUST', i.e., the security mechanism must provide a means for o Practical considerations: requiring an NTP server to authenticate
authorization, with an emphasis on the master. Authentication and its clients may significantly impose on the server's performance.
authorization of slaves is specified in this subsection as 'MAY'.
Note that while the requirement level of this requirement is 'MAY',
the requirement in Section 5.1.1. is 'MUST'; the security mechanism
must provide a means for authentication and authorization, with an
emphasis on the master. Authentication and authorization of slaves is
specified in this subsection as 'MAY'.
Discussion Discussion
Slaves and intermediate clocks are authenticated by masters in order Slaves and intermediate clocks are authenticated by masters in order
to verify their identity, thus preventing attackers from sending to verify that they are authorized to receive timing services from
unauthorized protocol packets to the master, and preventing the master.
unauthorized clocks from receiving time services.
Note that the authentication of slaves might put a higher load on the Authentication of slaves prevents unauthorized clocks from receiving
master than serving the unauthorized clock, and thus the decision of time services. Preventing the master from serving unauthorized clocks
whether to deploy slave authentication and/or authorization should be can help in mitigating DoS attacks against the master. Note that the
based on the environment in which the master and slaves are deployed. authentication of slaves might put a higher load on the master than
serving the unauthorized clock, and hence this requirement is a MAY.
5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master 5.1.4. PTP: Authentication and Authorization of P2P TCs by the Master
Requirement Requirement
The security mechanism for PTP MUST provide a means for a master to The security mechanism for PTP MAY provide a means for a master to
authenticate the identity of the P2P TCs directly connected to it. authenticate the identity of the P2P TCs directly connected to it.
Requirement Requirement
The security mechanism for PTP MAY provide a means for a master to The security mechanism for PTP MAY provide a means for a master to
verify that P2P TCs directly connected to it are authorized to be verify that P2P TCs directly connected to it are authorized to be
TCs. TCs.
Requirement Level Requirement Level
As in Section 5.1.3. , authentication and authorization can help in
preventing DoS attacks against the master (Section 3.2.9.).
Authentication also mitigates spoofing attacks (Section 3.2.2.).
The requirement levels of the authentication and authorization The requirement in this subsection prevents DoS attacks against the
requirements in this subsection are 'MUST' and 'MAY' respectively, master (Section 3.2.9.).
for the same reasons specified in Section 5.1.3.
The requirement level of this requirement is 'MAY' for the same
reasons specified in Section 5.1.3.
Discussion Discussion
P2P TCs that are one hop from the master use the PDelay_Req and P2P TCs that are one hop from the master use the PDelay_Req and
PDelay_Resp handshake to compute the link delay between the master PDelay_Resp handshake to compute the link delay between the master
and TC. These TCs are authenticated by the master. and TC. These TCs are authenticated by the master.
Authentication of TCs, much like authentication of slaves, prevents Authentication of TCs, much like authentication of slaves, reduces
external attackers from sending spoofed messages to the master, as unnecessary load on the master and peer TCs, by preventing the master
well as reduces unnecessary load on the master and peer TCs, by from serving unauthorized clocks.
preventing the master from serving unauthorized clocks.
5.1.5. PTP: Authentication and Authorization of Control Messages 5.1.5. PTP: Authentication and Authorization of Control Messages
Requirement Requirement
The security mechanism for PTP MUST support authentication of The security mechanism for PTP MUST support authentication of
Announce messages. The authentication mechanism MUST also verify that Announce messages. The authentication mechanism MUST also verify that
the sender is authorized to be a master. the sender is authorized to be a master.
Requirement Requirement
skipping to change at page 20, line 5 skipping to change at page 20, line 5
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. Availability 5.3. Spoofing Prevention
Requirement
The security mechanism MUST provide a means to prevent master
spoofing.
Requirement
The security mechanism MUST provide a means to prevent slave
spoofing.
Requirement
PTP: The security mechanism MUST provide a means to prevent P2P TC
spoofing.
Requirement Level
The requirements in this subsection address spoofing attacks (Section
3.2.2.). As described in Section 3.2.2. , when these requirements
are not met, the attack may have a high impact, causing slaves to
rely on false time information. Thus, the requirement level is
'MUST'.
Discussion
Spoofing attacks may take various different forms, and can
potentially cause significant impact. In a master spoofing attack,
the attacker causes slaves to receive false information about the
current time by masquerading as the master.
By spoofing a slave or an intermediate node (the second example of
Section 3.2.2.), an attacker can tamper with slaves' delay
computations. These attacks can be mitigated by an authentication
mechanism (Section 5.1.3. and 5.1.4.), or by other means, for
example, a PTP Delay_Req can include a Message Authentication Code
(MAC) that is included in the corresponding Delay_Resp message,
allowing the slave to verify that the Delay_Resp was not sent in
response to a spoofed message.
5.4. Availability
Requirement Requirement
The security mechanism SHOULD include measures to mitigate DoS The security mechanism SHOULD include measures to mitigate DoS
attacks against the time protocol. attacks against the time protocol.
Requirement Level Requirement Level
The requirement in this subsection prevents DoS attacks against the The requirement in this subsection prevents DoS attacks against the
protocol (Section 3.2.9.). protocol (Section 3.2.9.).
skipping to change at page 20, line 36 skipping to change at page 21, line 29
An attacker can inject protocol packets to implement the spoofing An attacker can inject protocol packets to implement the spoofing
attack (Section 3.2.2.) or the rogue master attack (Section 3.2.4. attack (Section 3.2.2.) or the rogue master attack (Section 3.2.4.
), causing DoS to the victim (Section 3.2.9.). An authentication ), causing DoS to the victim (Section 3.2.9.). An authentication
mechanism (Section 5.1.) limits these attacks strictly to internal mechanism (Section 5.1.) limits these attacks strictly to internal
attackers, and thus prevents external attackers from performing them. attackers, and thus prevents external attackers from performing them.
The DoS attacks described in Section 3.2.7. are performed at lower The DoS attacks described in Section 3.2.7. are performed at lower
layers than the time protocol layer, and are thus outside the scope layers than the time protocol layer, and are thus outside the scope
of the security requirements defined in this document. of the security requirements defined in this document.
5.4. Replay Protection 5.5. Replay Protection
Requirement Requirement
The security mechanism MUST include a replay prevention mechanism. The security mechanism MUST include a replay prevention mechanism.
Requirement Level Requirement Level
The requirement in this subsection prevents replay attacks (Section The requirement in this subsection prevents replay attacks (Section
3.2.3.). 3.2.3.).
skipping to change at page 21, line 4 skipping to change at page 21, line 45
Requirement Level Requirement Level
The requirement in this subsection prevents replay attacks (Section The requirement in this subsection prevents replay attacks (Section
3.2.3.). 3.2.3.).
The requirement level of this requirement is 'MUST' since in the The requirement level of this requirement is 'MUST' since in the
absence of this requirement the protocol is exposed to attacks that absence of this requirement the protocol is exposed to attacks that
are easy to implement and have a high impact. are easy to implement and have a high impact.
Discussion Discussion
The replay attack (Section 3.2.3.) can compromise both the integrity The replay attack (Section 3.2.3.) can compromise both the integrity
and availability of the protocol. Common encryption and and availability of the protocol. Common encryption and
authentication mechanisms include replay prevention mechanisms that authentication mechanisms include replay prevention mechanisms that
typically use a monotonously increasing packet sequence number. typically use a monotonously increasing packet sequence number.
5.5. Cryptographic Keys and Security Associations 5.6. Cryptographic Keys and Security Associations
5.5.1. Key Freshness 5.6.1. Key Freshness
Requirement Requirement
The cryptographic keys MUST be refreshed frequently. The cryptographic keys MUST be refreshed frequently.
Requirement Level Requirement Level
The requirement level of this requirement is 'MUST' since key The requirement level of this requirement is 'MUST' since key
freshness is an essential property for cryptographic algorithms, as freshness is an essential property for cryptographic algorithms, as
discussed below. discussed below.
Discussion Discussion
Key freshness guarantees that both sides share a common updated Key freshness guarantees that both sides share a common updated
secret key. It also helps in preventing replay attacks. Thus, it is secret key. It also helps in preventing replay attacks. Thus, it is
important for keys to be refreshed frequently. important for keys to be refreshed frequently.
5.5.2. Security Association 5.6.2. Security Association
Requirement Requirement
The security protocol SHOULD support an association protocol where: The security protocol SHOULD support an association protocol where:
o Two or more clocks authenticate each other. o Two or more clocks authenticate each other.
o The clocks generate and agree on a cryptographic session key. o The clocks generate and agree on a cryptographic session key.
Requirement Requirement
skipping to change at page 22, line 4 skipping to change at page 22, line 46
Each instance of the association protocol SHOULD produce a different Each instance of the association protocol SHOULD produce a different
session key. session key.
Requirement Level Requirement Level
The requirement level of this requirement is 'SHOULD' since it may be The requirement level of this requirement is 'SHOULD' since it may be
expensive in terms of performance, especially in low-cost clocks. expensive in terms of performance, especially in low-cost clocks.
Discussion Discussion
The security requirements in Section 5.1. and Section 5.2. require The security requirements in Section 5.1. and Section 5.2. require
usage of cryptographic mechanisms, deploying cryptographic keys. A usage of cryptographic mechanisms, deploying cryptographic keys. A
security association is an important building block in these security association is an important building block in these
mechanisms. mechanisms.
5.5.3. Unicast and Multicast Associations 5.6.3. Unicast and Multicast Associations
Requirement Requirement
The security mechanism SHOULD support security association protocols The security mechanism SHOULD support security association protocols
for unicast and for multicast associations. for unicast and for multicast associations.
Requirement Level Requirement Level
The requirement level of this requirement is 'SHOULD' since it may be The requirement level of this requirement is 'SHOULD' since it may be
expensive in terms of performance, especially for low-cost clocks. expensive in terms of performance, especially for low-cost clocks.
Discussion Discussion
A unicast protocol requires an association protocol between two A unicast protocol requires an association protocol between two
clocks, whereas a multicast protocol requires an association protocol clocks, whereas a multicast protocol requires an association protocol
among two or more clocks, where one of the clocks is a master. among two or more clocks, where one of the clocks is a master.
5.6. Performance 5.7. Performance
Requirement Requirement
The security mechanism MUST be designed in such a way that it does The security mechanism MUST be designed in such a way that it does
not significantly degrade the quality of the time transfer. not significantly degrade the quality of the time transfer.
Requirement Requirement
The mechanism SHOULD minimize computational load. The mechanism SHOULD minimize computational load.
skipping to change at page 23, line 24 skipping to change at page 24, line 17
Note that the performance requirements refer to a time-protocol- Note that the performance requirements refer to a time-protocol-
specific security mechanism. In systems where a security protocol is specific security mechanism. In systems where a security protocol is
used for other types of traffic as well, this document does not place used for other types of traffic as well, this document does not place
any performance requirements on the security protocol performance. any performance requirements on the security protocol performance.
For example, if IPsec encryption is used for securing all information For example, if IPsec encryption is used for securing all information
between the master and slave node, including information that is not between the master and slave node, including information that is not
part of the time protocol, the requirements in this subsection are part of the time protocol, the requirements in this subsection are
not necessarily applicable. not necessarily applicable.
5.7. Confidentiality 5.8. Confidentiality
Requirement Requirement
The security mechanism MAY provide confidentiality protection of the The security mechanism MAY provide confidentiality protection of the
protocol packets. protocol packets.
Requirement Level Requirement Level
The requirement level of this requirement is 'MAY' since it does not The requirement level of this requirement is 'MAY' since it does not
prevent severe threats, as discussed below. prevent severe threats, as discussed below.
skipping to change at page 24, line 12 skipping to change at page 25, line 5
protocol packets. Thus, confidentiality can assist in protecting the protocol packets. Thus, confidentiality can assist in protecting the
timing protocol against MITM attacks such as packet delay (Section timing protocol against MITM attacks such as packet delay (Section
3.2.6.), manipulation and interception and removal attacks. Note, 3.2.6.), manipulation and interception and removal attacks. Note,
that time protocols have predictable behavior even after encryption, that time protocols have predictable behavior even after encryption,
such as packet transmission rates and packet lengths. Additional such as packet transmission rates and packet lengths. Additional
measures can be taken to mitigate encrypted traffic analysis by measures can be taken to mitigate encrypted traffic analysis by
random padding of encrypted packets and by adding random dummy random padding of encrypted packets and by adding random dummy
packets. Nevertheless, encryption does not prevent such MITM attacks, packets. Nevertheless, encryption does not prevent such MITM attacks,
but rather makes these attacks more difficult to implement. but rather makes these attacks more difficult to implement.
5.8. Protection against Packet Delay and Interception Attacks 5.9. Protection against Packet Delay and Interception Attacks
Requirement Requirement
The security mechanism MUST include means to protect the protocol The security mechanism MUST include means to protect the protocol
from MITM attacks that degrade the clock accuracy. from MITM attacks that degrade the clock accuracy.
Requirement Level Requirement Level
The requirements in this subsection address MITM attacks such as the The requirements in this subsection address MITM attacks such as the
packet delay attack (Section 3.2.6.) and packet interception attacks packet delay attack (Section 3.2.6.) and packet interception attacks
skipping to change at page 25, line 5 skipping to change at page 25, line 44
indicates a time value that is significantly different than the other indicates a time value that is significantly different than the other
sources, it is assumed to be erroneous or under attack, and is sources, it is assumed to be erroneous or under attack, and is
therefore ignored. therefore ignored.
Thus, MITM attack prevention derives a requirement from the security Thus, MITM attack prevention derives a requirement from the security
mechanism, and a requirement from the network topology. While the mechanism, and a requirement from the network topology. While the
security mechanism should support the ability to detect delay security mechanism should support the ability to detect delay
attacks, it is noted that in some networks it is not possible to attacks, it is noted that in some networks it is not possible to
provide the redundancy needed for such a detection mechanism. provide the redundancy needed for such a detection mechanism.
5.9. Combining Secured with Unsecured Nodes 5.10. Combining Secured with Unsecured Nodes
Integrating a security mechanism into a time synchronized system is a Integrating a security mechanism into a time synchronized system is a
complex and expensive process, and hence in some cases may require complex and expensive process, and hence in some cases may require
incremental deployment, where new equipment supports the security incremental deployment, where new equipment supports the security
mechanism, and is required to interoperate with legacy equipment mechanism, and is required to interoperate with legacy equipment
without the security features. without the security features.
5.9.1. Secure Mode 5.10.1. Secure Mode
Requirement Requirement
The security mechanism MUST support a secure mode, where only secured The security mechanism MUST support a secure mode, where only secured
clocks are permitted to take part in the time protocol. In this mode clocks are permitted to take part in the time protocol. In this mode
every protocol packet received from an unsecured clock MUST be every protocol packet received from an unsecured clock MUST be
discarded. discarded.
Requirement Level Requirement Level
The requirement level of this requirement is 'MUST' since the full The requirement level of this requirement is 'MUST' since the full
capacity of the security requirements defined in this document can capacity of the security requirements defined in this document can
only be achieved in secure mode. only be achieved in secure mode.
Discussion Discussion
While the requirement in this subsection is similar to the one in While the requirement in this subsection is similar to the one in
5.1. , it refers to the secure mode, as opposed to the hybrid mode 5.1. , it refers to the secure mode, as opposed to the hybrid mode
presented in the next subsection. presented in the next subsection.
5.9.2. Hybrid Mode 5.10.2. Hybrid Mode
Requirement Requirement
The security protocol MAY support a hybrid mode, where both secured The security protocol MAY support a hybrid mode, where both secured
and unsecured clocks are permitted to take part in the protocol. and unsecured clocks are permitted to take part in the protocol.
Requirement Level Requirement Level
The requirement level of this requirement is a 'MAY', since it is not The requirement level of this requirement is a 'MAY', since it is not
necessarily required in all systems. This document recommends to necessarily required in all systems. This document recommends to
deploy the 'Secure Mode' described in Section 5.9.1. where possible. deploy the 'Secure Mode' described in Section 5.10.1. where possible.
Discussion Discussion
The hybrid mode allows both secured and unsecured clocks to take part The hybrid mode allows both secured and unsecured clocks to take part
in the time protocol. NTP, for example, allows a mixture of secured in the time protocol. NTP, for example, allows a mixture of secured
and unsecured nodes. and unsecured nodes.
Requirement Requirement
A master in the hybrid mode SHOULD be a secured clock. A master in the hybrid mode SHOULD be a secured clock.
skipping to change at page 27, line 5 skipping to change at page 27, line 44
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| Section | Requirement | Type | | Section | Requirement | Type |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.1. | Authentication & authorization of sender. | MUST | | 5.1. | Authentication & authorization of sender. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Authentication & authorization of master. | MUST | | | Authentication & authorization of master. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Recursive authentication & authorization. | MUST | | | Recursive authentication & authorization. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Authentication of slaves. | MUST | | | Authentication & authorization of slaves. | MAY |
| +---------------------------------------------+--------+
| | Authorization of slaves. | MAY |
| +---------------------------------------------+--------+
| | PTP: Authentication of P2P TCs by master. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | PTP: Authorization of P2P TCs by master. | MAY | | | PTP: Authentication & authorization of | MAY |
| | P2P TCs by master. | |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MUST | | | PTP: Authentication & authorization of | MUST |
| | Announce messages. | | | | Announce messages. | |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MUST | | | PTP: Authentication & authorization of | MUST |
| | Management messages. | | | | Management messages. | |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MAY | | | PTP: Authentication & authorization of | MAY |
| | Signaling messages. | | | | Signaling messages. | |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.2. | Integrity protection. | MUST | | 5.2. | Integrity protection. | MUST |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.3. | Protection from DoS attacks against the | SHOULD | | 5.3. | Spoofing prevention. | MUST |
+-----------+---------------------------------------------+--------+
| 5.4. | Protection from DoS attacks against the | SHOULD |
| | time protocol. | | | | time protocol. | |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.4. | Replay protection. | MUST | | 5.5. | Replay protection. | MUST |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.5. | Key freshness. | MUST | | 5.6. | Key freshness. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Security association. | SHOULD | | | Security association. | SHOULD |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Unicast and multicast associations. | SHOULD | | | Unicast and multicast associations. | SHOULD |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.6. | Performance: no degradation in quality of | MUST | | 5.7. | Performance: no degradation in quality of | MUST |
| | time transfer. | | | | time transfer. | |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Performance: computation load. | SHOULD | | | Performance: computation load. | SHOULD |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Performance: storage. | SHOULD | | | Performance: storage. | SHOULD |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Performance: bandwidth. | SHOULD | | | Performance: bandwidth. | SHOULD |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.7. | Confidentiality protection. | MAY | | 5.8. | Confidentiality protection. | MAY |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.8. | Protection against delay and interception | MUST | | 5.9. | Protection against delay and interception | MUST |
| | attacks. | | | | attacks. | |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
| 5.9. | Secure mode. | MUST | | 5.10. | Secure mode. | MUST |
| +---------------------------------------------+--------+ | +---------------------------------------------+--------+
| | Hybrid mode. | MAY | | | Hybrid mode. | MAY |
+-----------+---------------------------------------------+--------+ +-----------+---------------------------------------------+--------+
Table 2 Summary of Security Requirements Table 2 Summary of Security Requirements
7. Additional security implications 7. Additional security implications
This section discusses additional implications of the interaction This section discusses additional implications of the interaction
between time protocols and security mechanisms. between time protocols and security mechanisms.
 End of changes. 39 change blocks. 
88 lines changed or deleted 131 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/