draft-ietf-ntp-using-nts-for-ntp-02.txt   draft-ietf-ntp-using-nts-for-ntp-03.txt 
NTP Working Group D. Sibold NTP Working Group D. Sibold
Internet-Draft PTB Internet-Draft PTB
Intended status: Standards Track S. Roettger Intended status: Standards Track S. Roettger
Expires: April 7, 2016 Google Inc Expires: June 23, 2016 Google Inc
K. Teichel K. Teichel
PTB PTB
October 05, 2015 December 21, 2015
Using the Network Time Security Specification to Secure the Network Time Using the Network Time Security Specification to Secure the Network Time
Protocol Protocol
draft-ietf-ntp-using-nts-for-ntp-02 draft-ietf-ntp-using-nts-for-ntp-03
Abstract Abstract
This document describes how to use the measures described in the This document describes how to use the measures described in the
Network Time Security (NTS) specification to secure time Network Time Security (NTS) specification to secure time
synchronization with servers using the Network Time Protocol (NTP). synchronization with servers using the Network Time Protocol (NTP).
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 7, 2016. This Internet-Draft will expire on June 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 3. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4
4. Overview of NTS-Secured NTP . . . . . . . . . . . . . . . . . 4 4. Overview of NTS-Secured NTP . . . . . . . . . . . . . . . . . 4
4.1. Symmetric and Client/Server Mode . . . . . . . . . . . . 4 4.1. Symmetric and Client/Server Mode . . . . . . . . . . . . 4
4.2. Broadcast Mode . . . . . . . . . . . . . . . . . . . . . 4 4.2. Broadcast Mode . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 5
5.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. The Client . . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 5 5.1.1. The Client in Unicast Mode . . . . . . . . . . . . . 5
5.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 7 5.1.2. The Client in Broadcast Mode . . . . . . . . . . . . 7
5.2. The Server . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. The Server . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. The Server in Unicast Mode . . . . . . . . . . . . . 9 5.2.1. The Server in Unicast Mode . . . . . . . . . . . . . 9
5.2.2. The Server in Broadcast Mode . . . . . . . . . . . . 9 5.2.2. The Server in Broadcast Mode . . . . . . . . . . . . 10
6. Implementation Notes: ASN.1 Structures and Use of the CMS . . 10 6. Implementation Notes: ASN.1 Structures and Use of the CMS . . 10
6.1. Unicast Messages . . . . . . . . . . . . . . . . . . . . 10 6.1. Unicast Messages . . . . . . . . . . . . . . . . . . . . 11
6.1.1. Association Messages . . . . . . . . . . . . . . . . 10 6.1.1. Association Messages . . . . . . . . . . . . . . . . 11
6.1.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 11 6.1.2. Cookie Messages . . . . . . . . . . . . . . . . . . . 11
6.1.3. Time Synchronization Messages . . . . . . . . . . . . 11 6.1.3. Time Synchronization Messages . . . . . . . . . . . . 11
6.2. Broadcast Messages . . . . . . . . . . . . . . . . . . . 12 6.2. Broadcast Messages . . . . . . . . . . . . . . . . . . . 12
6.2.1. Broadcast Parameter Messages . . . . . . . . . . . . 12 6.2.1. Broadcast Parameter Messages . . . . . . . . . . . . 12
6.2.2. Broadcast Time Synchronization Message . . . . . . . 12 6.2.2. Broadcast Time Synchronization Message . . . . . . . 12
6.2.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 12 6.2.3. Broadcast Keycheck . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Employing Alternative Means for Association and Cookie 7.1. Field Type Registry . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1. Employing Alternative Means for Association and Cookie
Exchange . . . . . . . . . . . . . . . . . . . . . . . . 13 Exchange . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 13 8.2. Usage of NTP Pools . . . . . . . . . . . . . . . . . . . 13
7.3. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 13 8.3. Server Seed Lifetime . . . . . . . . . . . . . . . . . . 13
7.4. Supported Hash Algorithms . . . . . . . . . . . . . . . . 13 8.4. Supported Hash Algorithms . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 14 Appendix A. Flow Diagrams of Client Behaviour . . . . . . . . . 15
Appendix B. Bit Lengths for Employed Primitives . . . . . . . . 17 Appendix B. Bit Lengths for Employed Primitives . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
One of the most popular time synchronization protocols, the Network One of the most popular time synchronization protocols, the Network
Time Protocol (NTP) [RFC5905], currently does not provide adequate Time Protocol (NTP) [RFC5905], currently does not provide adequate
intrinsic security precautions. The Network Time Security draft intrinsic security precautions. The Network Time Security draft
[I-D.ietf-ntp-network-time-security] specifies security measures [I-D.ietf-ntp-network-time-security] specifies security measures
which can be used to enable time synchronization protocols to verify which can be used to enable time synchronization protocols to verify
authenticity of the time server and integrity of the time authenticity of the time server and integrity of the time
synchronization protocol packets. synchronization protocol packets.
skipping to change at page 5, line 19 skipping to change at page 5, line 27
After the client has received the necessry broadcast parameters, After the client has received the necessry broadcast parameters,
"broadcast time synchronization" message exchanges are utilized in "broadcast time synchronization" message exchanges are utilized in
combination with optional "broadcast keycheck" exchanges to protect combination with optional "broadcast keycheck" exchanges to protect
authenticity and integrity of NTP broadcast time synchronization authenticity and integrity of NTP broadcast time synchronization
packets. As in the case of unicast time synchronization messages, packets. As in the case of unicast time synchronization messages,
this is also achieved by MACs. this is also achieved by MACs.
5. Protocol Sequence 5. Protocol Sequence
Throughout this section, the nonces, cookies and MACs mentioned have Throughout this section, the server seed, the nonces, cookies and
bit lengths of B_nonce, B_cookie and B_mac, respectively. These bit MACs mentioned have bit lengths of B_seed, B_nonce, B_cookie and
lengths are defined in Appendix B (Appendix B). B_mac, respectively. These bit lengths are defined in Appendix B
(Appendix B).
Note for clarification that different message exchanges use different
nonces. A nonce is always generated by the client for a request
message, and then used by the server in its response. After this, it
is not to be used again.
5.1. The Client 5.1. The Client
5.1.1. The Client in Unicast Mode 5.1.1. The Client in Unicast Mode
For a unicast run, the client performs the following steps: For a unicast run, the client performs the following steps:
NOTE: Steps 1 through 4 MAY alternatively be replaced an alternative NOTE: Steps 1 through 4 MAY alternatively be replaced an alternative
secure mechanism for association and cookie exchange. An secure mechanism for association and cookie exchange. An
implementation MAY choose to replace either steps 1 and 2 or all implementation MAY choose to replace either steps 1 and 2 or all
skipping to change at page 6, line 43 skipping to change at page 7, line 8
* It checks that the decrypted message is of the expected format: * It checks that the decrypted message is of the expected format:
the concatenation of a B_nonce bit nonce and a B_cookie bit the concatenation of a B_nonce bit nonce and a B_cookie bit
cookie. cookie.
* It verifies that the received nonce matches the nonce sent in * It verifies that the received nonce matches the nonce sent in
the client_cook message. the client_cook message.
If one of those checks fails, the client MUST abort the run. If one of those checks fails, the client MUST abort the run.
Step 5: The client sends a time_request message to the server. The Step 5: The client sends a time_request message to the server. The
client MUST save the included nonce and the transmit_timestamp client MUST append a MAC to the time_request message. The client
(from the time synchronization data) as a correlated pair for MUST save the included nonce and the transmit_timestamp (from the
later verification steps. time synchronization data) as a correlated pair for later
verification steps.
Step 6: It awaits a reply in the form of a time_response message. Step 6: It awaits a reply in the form of a time_response message.
Upon receipt, it checks: Upon receipt, it checks:
* that the transmitted version number matches the one negotiated * that the transmitted version number matches the one negotiated
previously, previously,
* that the transmitted nonce belongs to a previous time_request * that the transmitted nonce belongs to a previous time_request
message, message,
skipping to change at page 9, line 33 skipping to change at page 9, line 45
in [I-D.ietf-ntp-network-time-security]. in [I-D.ietf-ntp-network-time-security].
o Upon receipt of a client_cook message, the server checks whether o Upon receipt of a client_cook message, the server checks whether
it supports the given cryptographic algorithms. It then it supports the given cryptographic algorithms. It then
calculates the cookie according to the formula given in calculates the cookie according to the formula given in
[I-D.ietf-ntp-network-time-security]. With this, it MUST [I-D.ietf-ntp-network-time-security]. With this, it MUST
construct a server_cook message as described in construct a server_cook message as described in
[I-D.ietf-ntp-network-time-security]. [I-D.ietf-ntp-network-time-security].
o Upon receipt of a time_request message, the server re-calculates o Upon receipt of a time_request message, the server re-calculates
the cookie, then computes the necessary time synchronization data the cookie, verifies integrity of the message, then computes the
and constructs a time_response message as given in necessary time synchronization data and constructs a time_response
[I-D.ietf-ntp-network-time-security]. message as given in [I-D.ietf-ntp-network-time-security].
The server MUST refresh its server seed periodically (see The server MUST refresh its server seed periodically (see
[I-D.ietf-ntp-network-time-security]). [I-D.ietf-ntp-network-time-security]).
In addition to the server MAY be ready to perform the following In addition to the server MAY be ready to perform the following
action: action:
o If an external mechanism for association and key exchange is used, o If an external mechanism for association and key exchange is used,
the server has to react accordingly. the server has to react accordingly.
skipping to change at page 11, line 19 skipping to change at page 11, line 31
Like "client_assoc", this message is realized as an NTP packet with Like "client_assoc", this message is realized as an NTP packet with
an extension field which holds an "NTS-Plain" archetype structure, an extension field which holds an "NTS-Plain" archetype structure,
i.e. just an NTS message object of the type "ServerAssocData". The i.e. just an NTS message object of the type "ServerAssocData". The
latter holds all the data necessary for NTS. latter holds all the data necessary for NTS.
6.1.2. Cookie Messages 6.1.2. Cookie Messages
6.1.2.1. Message Type: "client_cook" 6.1.2.1. Message Type: "client_cook"
This message type is realized as an NTP packet with an extension This message type is realized as an NTP packet with an extension
field which holds a CMS structure of archetype "NTS-Certified", field which holds a CMS structure of archetype "NTS-Plain",
containing in its core an NTS message object of the type containing in its core an NTS message object of the type
"ClientCookieData". The latter holds all the data necessary for the "ClientCookieData". The latter holds all the data necessary for the
NTS security mechanisms. NTS security mechanisms.
6.1.2.2. Message Type: "server_cook" 6.1.2.2. Message Type: "server_cook"
This message type is realized as an NTP packet with an extension This message type is realized as an NTP packet with an extension
field containing a CMS structure of archetype "NTS-Encrypted-and- field containing a CMS structure of archetype "NTS-Encrypted-and-
Signed". The NTS message object in that structure is a Signed". The NTS message object in that structure is a
"ServerCookieData" object, which holds all data required by NTS for "ServerCookieData" object, which holds all data required by NTS for
this message type. this message type.
6.1.3. Time Synchronization Messages 6.1.3. Time Synchronization Messages
6.1.3.1. Message Type: "time_request" 6.1.3.1. Message Type: "time_request"
This message type is realized as an NTP packet which actually This message type is realized as an NTP packet with regular NTP time
contains regular NTP time synchronization data, as an unsecured NTP synchronization data. Furthermore, the packet has an extension field
packet from a client to a server would. Furthermore, the packet has which contains an ASN.1 object of type "TimeRequestSecurityData"
an extension field which contains an ASN.1 object of type (packed in a CMS structure of archetype "NTS-Plain"). Finally, this
"TimeRequestSecurityData" (packed in a CMS structure of archetype NTP packet has another extension field which contains a Message
"NTS-Plain"). Authentication Code generated over the whole packet (including the
extension field).
6.1.3.2. Message Type: "time_response" 6.1.3.2. Message Type: "time_response"
This message is also realized as an NTP packet with regular NTP time This message is also realized as an NTP packet with regular NTP time
synchronization data. The packet also has an extension field which synchronization data. The packet also has an extension field which
contains an ASN.1 object of type "TimeResponseSecurityData". contains an ASN.1 object of type "TimeResponseSecurityData".
Finally, this NTP packet has another extension field which contains a Finally, this NTP packet has another extension field which contains a
Message Authentication Code generated over the whole packet Message Authentication Code generated over the whole packet
(including the extension field). (including the extension field).
6.2. Broadcast Messages 6.2. Broadcast Messages
6.2.1. Broadcast Parameter Messages 6.2.1. Broadcast Parameter Messages
6.2.1.1. Message Type: "client_bpar" 6.2.1.1. Message Type: "client_bpar"
This first broadcast message is realized as an NTP packet which is This first broadcast message is realized as an NTP packet which is
empty except for an extension field which contains an ASN.1 object of empty except for an extension field which contains an ASN.1 object of
type "BroadcastParameterRequest" (packed in a CMS structure of type "BroadcastParameterRequest" (packed in a CMS structure of
archetype "CMS-Plain"). This is sufficient to transport all data archetype "NTS-Plain"). This is sufficient to transport all data
specified by NTS. specified by NTS.
6.2.1.2. Message Type: "server_bpar" 6.2.1.2. Message Type: "server_bpar"
This message type is realized as an NTP packet whose extension field This message type is realized as an NTP packet whose extension field
carries the necessary CMS structure (archetype: "NTS-Signed"). The carries the necessary CMS structure (archetype: "NTS-Signed"). The
NTS message object in this case is an ASN.1 object of type NTS message object in this case is an ASN.1 object of type
"BroadcastParameterResponse". "BroadcastParameterResponse".
6.2.2. Broadcast Time Synchronization Message 6.2.2. Broadcast Time Synchronization Message
skipping to change at page 13, line 5 skipping to change at page 13, line 19
6.2.3.2. Message Type: "server_keycheck" 6.2.3.2. Message Type: "server_keycheck"
This message is also realized as an NTP packet with an extension This message is also realized as an NTP packet with an extension
field, which contains an ASN.1 object of type field, which contains an ASN.1 object of type
"ServerKeyCheckSecurityData" (packed in a CMS structure of archetype "ServerKeyCheckSecurityData" (packed in a CMS structure of archetype
"NTS-Plain"). Additionally, this NTP packet has another extension "NTS-Plain"). Additionally, this NTP packet has another extension
field which contains a Message Authentication Code generated over the field which contains a Message Authentication Code generated over the
whole packet (including the extension field). whole packet (including the extension field).
7. Security Considerations 7. IANA Considerations
7.1. Employing Alternative Means for Association and Cookie Exchange 7.1. Field Type Registry
Within the "NTP Extensions Field Types" registry table, add one field
type:
Field Type Meaning References
---------- ------------------------------------ ----------
TBD1 NTS-Related Content [this doc]
8. Security Considerations
8.1. Employing Alternative Means for Association and Cookie Exchange
If an implementation uses alternative means to perform association If an implementation uses alternative means to perform association
and cookie exchange, it MUST make sure that an adversary cannot abuse and cookie exchange, it MUST make sure that an adversary cannot abuse
the server to obtain a cookie belonging to a chosen KIV. the server to obtain a cookie belonging to a chosen KIV.
7.2. Usage of NTP Pools 8.2. Usage of NTP Pools
The certification-based authentication scheme described in The certification-based authentication scheme described in
[I-D.ietf-ntp-network-time-security] is not applicable to the concept [I-D.ietf-ntp-network-time-security] is not applicable to the concept
of NTP pools. Therefore, NTS is unable to provide secure usage of of NTP pools. Therefore, NTS is unable to provide secure usage of
NTP pools. NTP pools.
7.3. Server Seed Lifetime 8.3. Server Seed Lifetime
tbd tbd
7.4. Supported Hash Algorithms 8.4. Supported Hash Algorithms
The list of the hash algorithms supported by the server has to The list of the hash algorithms supported by the server has to
fulfill the following requirements: fulfill the following requirements:
o it MUST NOT include SHA-1 or weaker algorithms, o it MUST NOT include SHA-1 or weaker algorithms,
o it MUST include SHA-256 or stronger algorithms. o it MUST include SHA-256 or stronger algorithms.
8. Acknowledgements 9. Acknowledgements
The authors would like to thank Russ Housley, Steven Bellovin, David The authors would like to thank Russ Housley, Steven Bellovin, David
Mills and Kurt Roeckx for discussions and comments on the design of Mills and Kurt Roeckx for discussions and comments on the design of
NTS. Also, thanks to Harlan Stenn for his technical review and NTS. Also, thanks to Harlan Stenn for his technical review and
specific text contributions to this document. specific text contributions to this document.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, Transform Introduction", RFC 4082, DOI 10.17487/RFC4082,
skipping to change at page 14, line 20 skipping to change at page 14, line 45
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <http://www.rfc-editor.org/info/rfc5652>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <http://www.rfc-editor.org/info/rfc5905>.
9.2. Informative References 10.2. Informative References
[I-D.ietf-ntp-cms-for-nts-message] [I-D.ietf-ntp-cms-for-nts-message]
Sibold, D., Teichel, K., Roettger, S., and R. Housley, Sibold, D., Teichel, K., Roettger, S., and R. Housley,
"Protecting Network Time Security Messages with the "Protecting Network Time Security Messages with the
Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms- Cryptographic Message Syntax (CMS)", draft-ietf-ntp-cms-
for-nts-message-04 (work in progress), July 2015. for-nts-message-04 (work in progress), July 2015.
[I-D.ietf-ntp-network-time-security] [I-D.ietf-ntp-network-time-security]
Sibold, D., Roettger, S., and K. Teichel, "Network Time Sibold, D., Roettger, S., and K. Teichel, "Network Time
Security", draft-ietf-ntp-network-time-security-09 (work Security", draft-ietf-ntp-network-time-security-11 (work
in progress), July 2015. in progress), October 2015.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>. October 2014, <http://www.rfc-editor.org/info/rfc7384>.
Appendix A. Flow Diagrams of Client Behaviour Appendix A. Flow Diagrams of Client Behaviour
+---------------------+ +---------------------+
|Association Messages | |Association Messages |
+----------+----------+ +----------+----------+
| |
skipping to change at page 17, line 7 skipping to change at page 18, line 7
| +-------------+ +-----------------+ | | +-------------+ +-----------------+ |
| |Sync. Process| |Discard Previous | | | |Sync. Process| |Discard Previous | |
| +------+------+ +--------+--------+ | | +------+------+ +--------+--------+ |
| | | | | | | |
+-----------+ +-----------------------------------+ +-----------+ +-----------------------------------+
Figure 2: The client's behaviour in NTS broadcast mode. Figure 2: The client's behaviour in NTS broadcast mode.
Appendix B. Bit Lengths for Employed Primitives Appendix B. Bit Lengths for Employed Primitives
Define the following bit lengths for nonces, cookies and MACs: Define the following bit lengths for server seed, nonces, cookies and
MACs:
B_seed = 128,
B_nonce = 128, B_nonce = 128,
B_cookie = 128, and B_cookie = 128, and
B_mac = 128. B_mac = 128.
Authors' Addresses Authors' Addresses
Dieter Sibold Dieter Sibold
 End of changes. 26 change blocks. 
49 lines changed or deleted 73 lines changed or added

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