Frequenctly Asked Questions
Q: Which security protocol is available for the PTP (IEEE 1588) standard?
A: Annex K of the IEEE 1588 standard defines an experimental security extension to PTP. The PTP security extension and protocol provide group source authentication, message integrity, and replay attack protection for PTP messages. This security protocol does not provide non-repudiation and confidentiality.
Q: What security mechanisms are included in the IEEE 1588 standard?
A:
The PTP security protocol (Annex K) includes the following protection mechanisms:
- An integrity protection mechanism, which uses the message authentication code to verify that a received message is sent by an authenticated source and was not modified in transit, and a replay protection, which is implemented using replay counters and lifetime ids guaranteeing the freshness of a message (i.e., preventing message replay).
- A challenge-response mechanism, which is used to affirm the authenticity of new sources and to maintain the freshness of the trust relations.
No protection to introduce confidentiality and non-repudiation are included so far.
Q: What is a ICV?
A: The ICV is the integrity check value that protects a PTP message. This integrity protection mechanism uses the hashed message authentication codes (HMAC-SHA1-96 and HMAC-SHA256-128) to verify that a received message was sent by an authenticated source, was not modified in transit.
Q: What is included in the protection of the ICV (Integrity Check Value)?
A: "The ICV value is computed over all PTP message fields beginning with the first octet of the common header and ending with and including the last octet of the security AUTHENTICATION TLV." (Annex K, p.244 of IEEE 1588 standard)
This calculation does not include the network adresses required by the security association lookup. For more information on this topic check the article Security Flaws and Workarounds for IEEE 1588 (Transparent) Clocks" from ISPCS 2009.
Q: How many entries does the key list (K.13.2) contain?
A: The minimum number of keys stored in the the list is two, a current key and a next key that are required for a single security assosciation. The number of available keys is limited by the size of the key id field, 2^16 - 1. Actual number of keys stored is completely application dependend. Security enabled transparent clocks need to store current key and next key for all security assosciations transmitted via the transparent clock.
Q: Does PTP v1 (2002) include security protection mechanisms?
A: No, the security extension has been only introduced with the v2 (2008) of the standard.
Q: What implementation of security mechanisms for PTP do exist?
A: In the plug fest 2008 the Institute for Integrated Sensor Systems at the Austrian Academy of Sciences presented a fully Annex K compliant security stack and Flexibilis Oy tested a tunneling approach different to Annex K.
Q: How many old keys are stored in the list?
A: Regarding security, keys which expired should be discarded avoiding an attack in advance.
Q: How many keys are valid at the same time? How do expiration time of current and next key overlap?
A: Within one group ( one master and its slaves) only one key is valid at the same time. When the actual key expires the next key becomes active.
Q: What is the meaning of "... sets the sa.nextKeyId to the key that would be used once the current one expires ..." (section K.14.5)?
A: If the current key which is used has to be discarded at the end of its lifetime the key id is overwritten by the next key id value stored at the node. This leaves an empty or invalid next key id, which then has to be negotiated in a challenge-response cycle to receive the new next key id value.