Cisco Layer Two Forwarding (Protocol) "L2F"
RFC 2341
| Document | Type |
RFC
- Historic
(May 1998)
Was
draft-valencia-l2f
(individual)
|
|
|---|---|---|---|
| Authors | Morgan Littlewood , Andy Valencia , Tim Kolar , Tim Kolar , Tim Kolar | ||
| Last updated | 2013-03-02 | ||
| RFC stream | Legacy stream | ||
| Formats | |||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 2341
NTP Working Group D. Franke
Internet-Draft
Intended status: Standards Track D. Sibold
Expires: January 2, 2019 K. Teichel
PTB
July 01, 2018
Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-12
Abstract
This memo specifies Network Time Security (NTS), a mechanism for
using Transport Layer Security (TLS) and Authenticated Encryption
with Associated Data (AEAD) to provide cryptographic security for the
Network Time Protocol.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Franke, et al. Expires January 2, 2019 [Page 1]
Internet-Draft NTS4NTP July 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. TLS profile for Network Time Security . . . . . . . . . . . . 5
4. The NTS Key Establishment protocol . . . . . . . . . . . . . 6
4.1. NTS-KE Record Types . . . . . . . . . . . . . . . . . . . 8
4.1.1. End of Message . . . . . . . . . . . . . . . . . . . 8
4.1.2. NTS Next Protocol Negotiation . . . . . . . . . . . . 9
4.1.3. Error . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.4. Warning . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.5. AEAD Algorithm Negotiation . . . . . . . . . . . . . 10
4.1.6. New Cookie for NTPv4 . . . . . . . . . . . . . . . . 11
4.2. Key Extraction (generally) . . . . . . . . . . . . . . . 11
5. NTS Extension Fields for NTPv4 . . . . . . . . . . . . . . . 11
5.1. Key Extraction (for NTPv4) . . . . . . . . . . . . . . . 11
5.2. Packet structure overview . . . . . . . . . . . . . . . . 12
5.3. The Unique Identifier extension field . . . . . . . . . . 12
5.4. The NTS Cookie extension field . . . . . . . . . . . . . 13
5.5. The NTS Cookie Placeholder extension field . . . . . . . 13
5.6. The NTS Authenticator and Encrypted Extension Fields
extension field . . . . . . . . . . . . . . . . . . . . . 13
6. Protocol details . . . . . . . . . . . . . . . . . . . . . . 15
7. Suggested format for NTS cookies . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 24
9.1. Implementation PoC 1 . . . . . . . . . . . . . . . . . . 24
9.1.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 24
9.1.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 24
9.1.3. Contact Information . . . . . . . . . . . . . . . . . 25
9.1.4. Last Update . . . . . . . . . . . . . . . . . . . . . 25
9.2. Implementation PoC 2 . . . . . . . . . . . . . . . . . . 25
9.2.1. Coverage . . . . . . . . . . . . . . . . . . . . . . 25
9.2.2. Licensing . . . . . . . . . . . . . . . . . . . . . . 25
9.2.3. Contact Information . . . . . . . . . . . . . . . . . 25
9.2.4. Last Update . . . . . . . . . . . . . . . . . . . . . 25
9.3. Interoperability . . . . . . . . . . . . . . . . . . . . 25
10. Security considerations . . . . . . . . . . . . . . . . . . . 26
10.1. Avoiding DDoS amplification . . . . . . . . . . . . . . 26
10.2. Initial verification of server certificates . . . . . . 26
10.3. Usage of NTP pools . . . . . . . . . . . . . . . . . . . 27
10.4. Delay attacks . . . . . . . . . . . . . . . . . . . . . 27
10.5. Random number generation . . . . . . . . . . . . . . . . 28
Franke, et al. Expires January 2, 2019 [Page 2]
Internet-Draft NTS4NTP July 2018
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
11.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 28
11.2. Confidentiality . . . . . . . . . . . . . . . . . . . . 29
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Terms and Abbreviations . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction
This memo specifies Network Time Security (NTS), a cryptographic
security mechanism for network time synchronization. A complete
specification is provided for application of NTS to the client-server
mode of the Network Time Protocol (NTP) [RFC5905].
1.1. Objectives
The objectives of NTS are as follows:
o Identity: Through the use of the X.509 PKI, implementations may
cryptographically establish the identity of the parties they are
communicating with.
o Authentication: Implementations may cryptographically verify that
any time synchronization packets are authentic, i.e., that they
were produced by an identified party and have not been modified in
transit.
o Confidentiality: Although basic time synchronization data is
considered non-confidential and sent in the clear, NTS includes
support for encrypting NTP extension fields.
o Replay prevention: Client implementations may detect when a
received time synchronization packet is a replay of a previous
packet.
o Request-response consistency: Client implementations may verify
that a time synchronization packet received from a server was sent
in response to a particular request from the client.
o Unlinkability: For mobile clients, NTS will not leak any
information additional to NTP which would permit a passive
adversary to determine that two packets sent over different
networks came from the same client.
Franke, et al. Expires January 2, 2019 [Page 3]
Internet-Draft NTS4NTP July 2018
o Non-amplification: Implementations (especially server
implementations) may avoid acting as DDoS amplifiers by never
responding to a request with a packet larger than the request
packet.
o Scalability: Server implementations may serve large numbers of
clients without having to retain any client-specific state.
1.2. Protocol overview
The Network Time Protocol includes many different operating modes to
support various network topologies. In addition to its best-known
and most-widely-used client-server mode, it also includes modes for
synchronization between symmetric peers, a control mode for server
monitoring and administration and a broadcast mode. These various
modes have differing and partly contradictory requirements for
security and performance. Symmetric and control modes demand mutual
authentication and mutual replay protection, and for certain message
types control mode may require confidentiality as well as
authentication. Client-server mode places more stringent
requirements on resource utilization than other modes, because
servers may have vast number of clients and be unable to afford to
maintain per-client state. However, client-server mode also has more
relaxed security needs, because only the client requires replay
protection: it is harmless for stateless servers to process replayed
packets. The security demands of symmetric and control modes, on the
other hand, are in conflict with the resource-utilization demands of
client-server mode: any scheme which provides replay protection
inherently involves maintaining some state to keep track of what
messages have already been seen.
This memo specifies NTS exclusively for the client-server mode of
NTP. To this end, NTS is structured as a suite of two protocols:
The "NTS Extension Fields for NTPv4's L2F_CONF response, as well as all future non-
L2F_CONF packets received.
The CLID value from the last valid L2F_CONF message received MUST be
recorded and used as the CLID field value for all subsequent packets
sent to the peer.
Packets with an unknown Client ID MUST be silently discarded.
For the initial packet sent during tunnel establishment, where no
L2F_CONF has yet been received, the CLID field MUST be set to 0.
Thus, during L2F_CONF each side is told its CLID value. All later
packets sent, tagged with this CLID value, serve as a tag which
uniquely identifies this peer.
4.2.8 Length
Length is the size in octets of the entire packet, including header,
all fields present, and payload. Length does not reflect the
addition of the checksum, if one is present. The packet should be
silently discarded if the received packet is shorter than the
indicated length. Additional bytes present in the packet beyond the
indicated length MUST be silently ignored.
4.2.9 Packet Checksum
The Checksum is present if the C bit is present in the header flags.
It is a 16-bit CRC as used by PPP/HDLC (specifically, FCS-16 [3]).
Is is applied over the entire packet starting with the first byte of
L2F flags, through the last byte of payload data. The checksum is
then added as two bytes immediately following the last byte of
payload data.
Valencia, et. al. Historic [Page 13]
RFC 2341 Cisco L2F May 1998
4.2.10 Payload Offset
The Offset is present if the F bit is set in the header flags. This
field specifies the number of bytes past the L2F header at which the
payload data is expected to start. If it is 0, or the F bit is not
set, the first byte following the last byte of L2F header is the
first byte of payload data.
It is recommended that data skipped due to the payload offset be
initialized to 0's.
For architectures where it is more efficient to have the payload
start at an aligned 32-bit boundary with respect to the L2F header,
it is recommended that the F bit be set, and an offset of 0 be used.
4.2.11 Packet Key
The Key field is present if the K bit is set in the L2F header. The
Key is based on the authentication response last given to the peer
during tunnel creation (the details of tunnel creation are provided
in the next section). It serves as a key during the life of a
session to resist attacks based on spoofing. If a packet is received
in which the Key does not match the expected value, the packet MUST
be silently discarded. Such handling takes precedence over 4.4.1.
The Key value is generated by taking the 128-bit authentication
response from the peer, interpreting it as four adjacent 32-bit words
in network byte order, XOR'ing these words together, and using the
resulting 32-bit value as the Key.
4.2.12 Packet priority
If the P bit in the L2F header is set, this packet is a "priority"
packet. When possible for an implementation, a packet received with
the P bit should be processed in preference to previously received
unprocessed packets without the P bit.
The P bit may be set by an implementation based on criteria beyond
the scope of this specification. However, it is recommended that PPP
keepalive traffic, if any, be sent with this bit set.
4.3 L2F Tunnel Establishment
When the point-to-point link is first initiated between the NAS and
the Home Gateway, the endpoints communicate on MID 0 prior to
providing general L2F services to clients. This communication is
used to verify the presence of L2F on the remote end, and to permit
any needed authentication.
Valencia, et. al. Historic [Page 14]
RFC 2341 Cisco L2F May 1998
The protocol for such negotiation is always 1, indicating L2F
management. The message itself is structured as a sequence of single
octets indicating an option, followed by zero or more further octets
formatted as needed for the option.
4.3.1 Normal Tunnel Negotiation Sequence
The establishment sequence is best illustrated by a "typical"
connection sequence. Detailed description of each functions follows,
along with descriptions of the handling of exceptional conditions.
Each packet is described as a source->destination on one line, a
description of the L2F packet field contents on the next, and the
contents of the packet's body on following lines. The exact encoding
of octets will be described later.
Note that this example uses the Key option, but does not use the
Offset and Checksum options. The Length field would be present,
reflecting the actual length of the packets as encoded as an octet
stream.
1. NAS->GW:
Proto=L2F, Seq=0, MID=0, CLID=0, Key=0
L2F_CONF
Name: NAS_name
Challenge: Rnd
Assigned_CLID: 22
The NAS decides that a tunnel must be initiated from the NAS to the
GW. An L2F packet is sent with the Proto field indicating an L2F
management message is contained.
Because the tunnel is being initiated, Key is set to 0. The sequence
number starts at 0; the MID is 0 to reflect the establishment of the
tunnel itself. Since the NAS has not yet received an L2F_CONF, the
CLID is set to 0.
The body of the packet specifies the claimed name of the NAS, and a
challenge random number which GW will use in authenticating itself as
a valid tunnel endpoint. Assigned_CLID is generated to be a value
not currently assigned out to any other tunnel to any other Home
Gateway.
Valencia, et. al. Historic [Page 15]
RFC 2341 Cisco L2F May 1998
2. GW->NAS:
Proto=L2F, Seq=0, MID=0, CLID=22, Key=0
L2F_CONF
Name: GW_name
Challenge: Rnd2
Assigned_CLID: 73
The Home Gateway has processed the previous packet, and sends a
response. The protocol continues to be L2F, with a sequence number 0
(each side maintains its own sequence number for transmissions). MID
continues to be 0 to reflect tunnel establishment. CLID reflects the
Assigned_CLID field of the L2F_CONF received. The Key continues to
be 0 during this phase of tunnel establishment.
The body contains the Home Gateway's name, its own random number
challenge, and its own Assigned_CLID for the NAS to place in the CLID
field of future packets. The CLID is generated in an analogous
manner to that of the NAS. After this, all packets received from the
NAS must be tagged with a CLID field containing 73, and all packets
sent to the NAS must be tagged with a CLID field containing 22.
3. NAS->GW
Proto=L2F, Seq=1, MID=0, CLID=73, Key=C(Rnd2)
L2F_OPEN
Response: C(Rnd2)
The NAS responds with its Key now set to reflect the shared secret.
The Key is a CHAP-style hash of the random number received; each
packet hereafter will reflect this calculated value, which serves as
a key for the life of the tunnel. Both the Home Gateway and the NAS
use such Keys for the life of the tunnel. The Key is a 32-bit
representation of the MD5 digest resulting from encrypting the shared
secret; the full MD5 digest is included in the L2F_OPEN response, in
the "response" field.
4. GW->NAS
Proto=L2F, Seq=1, MID=0, CLID=22, Key=C(Rnd)
L2F_OPEN
Response: C(Rnd)
The Home Gateway provides closure of the key from the NAS, reflected
in both the Key field as well as the "response" field. The tunnel is
now available for clients to be established.
Valencia, et. al. Historic [Page 16]
RFC 2341 Cisco L2F May 1998
4.3.2 Normal Client Negotiation Sequence
This section describes the establishment of a Virtual dial-up client
on a NAS into a Home Gateway. It assumes a tunnel has been created
in the way described in 4.3.1. The client for this example is a PPP
client configured for CHAP.
Treatment of Checksum, Length, and Offset are as in 4.3.1.
1. NAS->GW
Proto=L2F, Seq=2, MID=1, CLID=73, Key=C(Rnd2)
L2F_OPEN
Type: CHAP
Name: CHAP-name
Challenge: Rnd3
Response: <Value received, presumably C(Rnd3)>
ID: <ID used in challenge>
The NAS has received a call, tried CHAP with a challenge value of
Rnd3, and found that the client responded. The claimed name lead the
NAS to believe it was a Virtual dial-up client hosted by the Home
Gateway. The next free MID is allocated, and the information
associated with the CHAP challenge/response is included in the
connect notification.
2. GW->NAS
Proto=L2F, Seq=2, MID=1, CLID=22, Key=C(Rnd)
L2F_OPEN
The Home Gateway, by sending back the L2F_OPEN, accepts the client.
3. NAS->GW
Proto=PPP, Seq=0, MID=1, CLID=73, Key=C(Rnd2)
<Frame follows>
4. GW->NAS
Proto=PPP, Seq=0, MID=1, CLID=22, Key=C(Rnd)
<Frame follows>
Traffic is now free to flow in either direction as sent by the remote
client or the home site. The contents is uninterpreted data, HDLC in
this case. Data traffic, since it is not the L2F protocol, does not
usually use the Seq field, which is set to 0 in non-L2F messages (see
the S bit in section 4.2.5 for details on an exception to this).
Valencia, et. al. Historic [Page 17]
RFC 2341 Cisco L2F May 1998
4.4 L2F management message types
When an L2F packet's Proto field specifies L2F management, the body
of the packet is encoded as zero or more options. An option is a
single octet "message type", followed by zero or more sub-options.
Each sub-option is a single byte sub-option value, and further bytes
as appropriate for the sub-option.
Options in L2F are:
Hex Value Abbreviation Description
-------- ------------ -----------
0x00 Invalid Invalid message
0x01 L2F_CONF Request configuration
0x02 L2F_CONF_NAME Name of peer sending L2F_CONF
0x03 L2F_CONF_CHAL Random number peer challenges with
0x04 L2F_CONF_CLID Assigned_CLID for peer to use
0x02 L2F_OPEN Accept configuration
0x01 L2F_OPEN_NAME Name received from client
0x02 L2F_OPEN_CHAL Challenge client received
0x03 L2F_OPEN_RESP Challenge response from client
0x04 L2F_ACK_LCP1 LCP CONFACK accepted from client
0x05 L2F_ACK_LCP2 LCP CONFACK sent to client
0x06 L2F_OPEN_TYPE Type of authentication used
0x07 L2F_OPEN_ID ID associated with authentication
0x08 L2F_REQ_LCP0 First LCP CONFREQ from client
0x03 L2F_CLOSE Request disconnect
0x01 L2F_CLOSE_WHY Reason code for close
0x02 L2F_CLOSE_STR ASCII string description
0x04 L2F_ECHO Verify presence of peer
0x05 L2F_ECHO_RESP Respond to L2F_ECHO
4.4.1 L2F message type: Invalid
If a message is received with this value, or any value higher than
the last recognized option value, or if an illegal packet as defined
by other parts of this specification is received, the packet is
considered invalid. The packet MUST be discarded, and an L2F_CLOSE
of the entire tunnel MUST be requested. Upon receipt of an
L2F_CLOSE, the tunnel itself may be closed. All other received
message MUST be discarded. An implementation MAY close the tunnel
after an interval of time appropriate to the characteristics of the
tunnel.
Valencia, et. al. Historic [Page 18]
quot; are a collection of NTP
extension fields for cryptographically securing NTPv4 using
previously-established key material. They are suitable for
securing client-server mode because the server can implement them
without retaining per-client state, but on the other hand are
suitable *only* for client-server mode because only the client,
and not the server, is protected from replay.
The "NTS Key Establishment" protocol (NTS-KE) is a mechanism for
establishing key material for use with the NTS Extension Fields
for NTPv4. It uses TLS to exchange keys and negotiate some
additional protocol options, but then quickly closes the TLS
channel and permits the server to discard all associated state.
Franke, et al. Expires January 2, 2019 [Page 4]
Internet-Draft NTS4NTP July 2018
The typical protocol flow is as follows. The client connects to the
server on the NTS TCP port and the two parties perform a TLS
handshake. Via the TLS channel, the parties negotiate some
additional protocol parameters and the server sends the client a
supply of cookies. The parties use TLS key export [RFC5705] to
extract key material which will be used in the next phase of the
protocol. This negotiation takes only a single round trip, after
which the server closes the connection and discards all associated
state. At this point the NTS-KE phase of the protocol is complete.
Time synchronization proceeds over the NTP UDP port. The client
sends the server an NTP client packet which includes several
extension fields. Included among these fields are a cookie
(previously provided by the server), and an authentication tag,
computed using key material extracted from the NTS-KE handshake. The
server uses the cookie to recover this key material (previously
discarded to avoid maintaining state) and sends back an authenticated
response. The response includes a fresh, encrypted cookie which the
client then sends back in the clear with its next request. (This
constant refreshing of cookies is necessary in order to achieve NTS's
unlinkability goal.)
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. TLS profile for Network Time Security
Network Time Security makes use of TLS for NTS key establishment.
Since securing time protocols is (as of 2017) a novel application of
TLS, no backward-compatibility concerns exist to justify using
obsolete, insecure, or otherwise broken TLS features or versions. We
therefore put forward the following requirements and guidelines,
roughly representing 2017's best practices.
Implementations MUST NOT negotiate TLS versions earlier than 1.2.
Implementations willing to negotiate more than one possible version
of TLS SHOULD NOT respond to handshake failures by retrying with a
downgraded protocol version. If they do, they MUST implement
[RFC7507].
TLS clients MUST NOT offer, and TLS servers MUST NOT select, RC4
cipher suites. [RFC7465]
Franke, et al. Expires January 2, 2019 [Page 5]
Internet-Draft NTS4NTP July 2018
TLS 1.2 clients SHOULD offer, and TLS servers SHOULD accept, the TLS
Renegotiation Indication Extension [RFC5746]. Regardless, they MUST
NOT initiate or permit insecure renegotiation.
TLS 1.2 clients SHOULD offer, and TLS 1.2 servers SHOULD accept, the
TLS Session Hash and Extended Master Secret Extension [RFC7627].
Use of the Application-Layer Protocol Negotiation Extension [RFC7301]
is integral to NTS and support for it is REQUIRED for
interoperability.
4. The NTS Key Establishment protocol
The NTS key establishment protocol is conducted via TCP port
[[TBD1]]. The two endpoints carry out a TLS handshake in conformance
with Section 3, with the client offering (via an ALPN [RFC7301]
extension), and the server accepting, an application-layer protocol
of "ntske/1". Immediately following a successful handshake, the
client SHALL send a single request (as Application Data encapsulated
in the TLS-protected channel), then the server SHALL send a single
response followed by a TLS "Close notify" alert and then discard the
channel state.
The client's request and the server's response each SHALL consist of
a sequence of records formatted according to Figure 1. The sequence
SHALL be terminated by a "End of Message" record, which has a Record
Type of zero and a zero-length body. Furthermore, requests and non-
error responses each SHALL include exactly one NTS Next Protocol
Negotiation record.
Clients and servers MAY enforce length limits on requests and
responses, however servers MUST accept requests of at least 1024
octets, and clients SHOULD accept responses of at least 65536 octets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Record Type | Body Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Record Body .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Franke, et al. Expires January 2, 2019 [Page 6]
Internet-Draft NTS4NTP July 2018
The requirement that all NTS-KE messages be terminated by an End of
Message record makes them self-delimiting.
The fields of an NTS-KE record are defined as follows:
C (Critical Bit): Determines the disposition of unrecognized
Record Types. Implementations which receive a record with an
unrecognized Record Type MUST ignore the record if the Critical
Bit is 0, and MUST treat it as an error if the Critical Bit is 1.
Record Type: A 15-bit integer in network byte order. The
semantics of record types 0-5 are specified in this memo;
additional type numbers SHALL be tracked through the IANA Network
Time Security Key Establishment Record Types registry.
Body Length: The length of the Record Body field, in octets, as a
16-bit integer in network byte order. Record bodies MAY have any
representable length and need not be aligned to a word boundary.
Record Body: The syntax and semantics of this field SHALL be
determined by the Record Type.
For clarity regarding bit-endianness: the Critical Bit is the most-
significant bit of the first octet. In C, given a network buffer
`unsigned char b[]` containing an NTS-KE record, the critical bit is
`b[0] >> 7` while the record type is `((b[0] & 0x7f) << 8) + b[1]`.
Figure 2 provides a schematic overview of the key exchange. It
displays the protocol steps to be performed by the NTS client and
server and record types to be exchanged.
Franke, et al. Expires January 2, 2019 [Page 7]
Internet-Draft NTS4NTP July 2018
+---------------------------------------+
| - verify client request message |
| - extract TLS key material |
| - generate KE response message |
| - included Record Types: |
| - NTS Next Protocol Negotiation |
| - AEAD Alg. Negotiation |
| - New Cookie for NTPv4 |
| - <New Cookie for NTPv4> |
| - End of Message |
+-----------------+---------------------+
|
|
Server -----------+---------------+-----+----------------------->
^ \
/ \
/ TLS application \
/ data \
/ \
/ V
Client -----+---------------------------------+---------------->
| |
| |
| |
+-----------+----------------------+ +------+-----------------+
|- generate KE request message | |- verify server response|
| - include Record Types: | | message |
| o NTS Next Protocol Negotiation | |- extract cookie(s) |
| o AEAD Alg. Negotiation | | |
| o End of Message | | |
+----------------------------------+ +------------------------+
Figure 2: NTS Key Exchange messages
4.1. NTS-KE Record Types
The following NTS-KE Record Types are defined.
4.1.1. End of Message
The End of Message record has a Record Type number of 0 and an zero-
length body. It MUST occur exactly once as the final record of every
NTS-KE request and response. The Critical Bit MUST be set.
Franke, et al. Expires January 2, 2019 [Page 8]
Internet-Draft NTS4NTP July 2018
4.1.2. NTS Next Protocol Negotiation
The NTS Next Protocol Negotiation record has a Record Type of 1. It
MUST occur exactly once in every NTS-KE request and response. Its
body consists of a sequence of 16-bit unsigned integers in network
byte order. Each integer represents a Protocol ID from the IANA
Network Time Security Next Protocols registry. The Critical Bit MUST
be set.
The Protocol IDs listed in the client's NTS Next Protocol Negotiation
record denote those protocols which the client wishes to speak using
the key material established through this NTS-KE session. The
Protocol IDs listed in the server's response MUST comprise a subset
of those listed in the request, and denote those protocols which the
server is willing and able to speak using the key material
established through this NTS-KE session. The client MAY proceed with
one or more of them. The request MUST list at least one protocol,
but the response MAY be empty.
4.1.3. Error
The Error record has a Record Type number of 2. Its body is exactly
two octets long, consisting of an unsigned 16-bit integer in network
byte order, denoting an error code. The Critical Bit MUST be set.
Clients MUST NOT include Error records in their request. If clients
receive a server response which includes an Error record, they MUST
discard any negotiated key material and MUST NOT proceed to the Next
Protocol.
The following error codes are defined.
Error code 0 means "Unrecognized Critical Record". The server
MUST respond with this error code if the request included a record
which the server did not understand and which had its Critical Bit
set. The client SHOULD NOT retry its request without
modification.
Error code 1 means "Bad Request". The server MUST respond with
this error if, upon the expiration of an implementation-defined
timeout, it has not yet received a complete and syntactically
well-formed request from the client. This error is likely to be
the result of a dropped packet, so the client SHOULD start over
with a new TLS handshake and retry its request.
Franke, et al. Expires January 2, 2019 [Page 9]
Internet-Draft NTS4NTP July 2018
4.1.4. Warning
The Warning record has a Record Type number of 3. Its body is
exactly two octets long, consisting of an unsigned 16-bit integer in
network byte order, denoting a warning code. The Critical Bit MUST
be set.
Clients MUST NOT include Warning records in their request. If
clients receive a server response which includes a Warning record,
they MAY discard any negotiated key material and abort without
proceeding to the Next Protocol. Unrecognized warning codes MUST be
treated as errors.
This memo defines no warning codes.
4.1.5. AEAD Algorithm Negotiation
The AEAD Algorithm Negotiation record has a Record Type number of 4.
Its body consists of a sequence of unsigned 16-bit integers in
network byte order, denoting Numeric Identifiers from the IANA AEAD
registry [RFC5116]. The Critical Bit MAY be set.
If the NTS Next Protocol Negotiation record offers Protocol ID 0 (for
NTPv4), then this record MUST be included exactly once. Other
protocols MAY require it as well.
When included in a request, this record denotes which AEAD algorithms
the client is willing to use to secure the Next Protocol, in
decreasing preference order. When included in a response, this
record denotes which algorithm the server chooses to use, or is empty
if the server supports none of the algorithms offered. In requests,
the list MUST include at least one algorithm. In responses, it MUST
include at most one. Honoring the client's preference order is
OPTIONAL: servers may select among any of the client's offered
choices, even if they are able to support some other algorithm which
the client prefers more.
Server implementations of NTS extension fields for NTPv4 (Section 5)
MUST support AEAD_AES_SIV_CMAC_256 [RFC5297] (Numeric Identifier 15).
That is, if the client includes AEAD_AES_SIV_CMAC_256 in its AEAD
Algorithm Negotiation record, and the server accepts Protocol ID 0
(NTPv4) in its NTS Next Protocol Negotiation record, then the
server's AEAD Algorithm Negotiation record MUST NOT be empty.
Franke, et al. Expires January 2, 2019 [Page 10]
Internet-Draft NTS4NTP July 2018
4.1.6. New Cookie for NTPv4
The New Cookie for NTPv4 record has a Record Type number of 5. The
contents of its body SHALL be implementation-defined and clients MUST
NOT attempt to interpret them. See Section 7 for a suggested
construction.
Clients MUST NOT send records of this type. Servers MUST send at
least one record of this type, and SHOULD send eight of them, if they
accept Protocol ID 0 (NTPv4) as a Next Protocol. The Critical Bit
SHOULD NOT be set.
4.2. Key Extraction (generally)
Following a successful run of the NTS-KE protocol, key material SHALL
be extracted according to RFC 5705 [RFC5705]. Inputs to the exporter
function are to be constructed in a manner specific to the negotiated
Next Protocol. However, all protocols which utilize NTS-KE MUST
conform to the following two rules:
The disambiguating label string MUST be "EXPORTER-network-time-
security/1".
The per-association context value MUST be provided, and MUST begin
with the two-octet Protocol ID which was negotiated as a Next
Protocol.
5. NTS Extension Fields for NTPv4
5.1. Key Extraction (for NTPv4)
Following a successful run of the NTS-KE protocol wherein Protocol ID
0 (NTPv4) is selected as a Next Protocol, two AEAD keys SHALL be
extracted: a client-to-server (C2S) key and a server-to-client (S2C)
key. These keys SHALL be computed according to RFC 5705 [RFC5705],
using the following inputs.
The disambiguating label string SHALL be "EXPORTER-network-time-
security/1&RFC 2341 Cisco L2F May 1998
Note that packets with an invalid Key are discarded, but disconnect
is not initiated. This prevents denial-of-service attacks. Invalid
option types within a message MUST be treated as if the entire
message type was invalid.
4.4.2 L2F_CONF
The L2F message type is used to establish the tunnel between the NAS
and the Home Gateway. MID is always set to 0. The body of such a
message starts with the octet 0x01 (L2F_CONF), followed by all three
of the sub-options below.
The L2F_CONF_NAME sub-option MUST be present. It is encoded as the
octet value 0x02, followed by an octet specifying a non-zero length,
followed by the indicated number of bytes, which are interpreted as
the sender's ASCII name.
The L2F_CONF_CHAL sub-option MUST be present. It is encoded as the
octet value 0x03, followed by a non-zero octet, followed by a number
of bytes specified by this non-zero octet.
The challenge value should be generated using whatever techniques
provide the highest quality of random numbers available to a given
implementation.
The L2F_CONF_CLID sub-option MUST be present. It is encoded as the
octet 0x04, followed by four bytes of Assigned_CLID value. The
Assigned_CLID value is generated as a non-zero 16-bit integer value
unique across all tunnels which exist on the sending system. The
least significant two octets of Assigned_CLID are set to this value,
and the most significant two octets MUST be set to 0.
The CLID field is sent as 0 in the initial L2F_CONF packet from NAS
to Home Gateway, and otherwise MUST be sent containing the value
specified in the Assigned_CLID field of the last L2F_CONF message
received.
Key MUST be set to 0 in all L2F_CONF packets, and no key field is
included in the packet.
When sent from a NAS to a Home Gateway, the L2F_CONF is the initial
packet in the conversation.
When sent from the Home Gateway to the NAS, an L2F_CONF indicates the
Home Gateway's recognition of the tunnel creation request. The Home
Gateway MUST provide its name and its own challenge in the message
body.
Valencia, et. al. Historic [Page 19]
RFC 2341 Cisco L2F May 1998
In all packets following the L2F_CONF, the Key MUST be set to the
CHAP-style hash of the received challenge bytes. The CHAP-style hash
is done over the concatenation of the low 8 bits of the assigned
CLID, the secret, and the challenge value. Generation of the 32-bit
key value is discussed in section 4.2.11.
4.4.3 L2F_OPEN, tunnel establishment
The L2F_OPEN message is used to provide tunnel setup closure (for a
MID of 0) or to establish a client connection within a tunnel
previously established by L2F_CONF and L2F_OPEN messages (MID not
equal to 0). This section describes tunnel establishment; section
4.4.4 following describes clients established within the tunnel.
An L2F_OPEN for tunnel establishment MUST contain only the sub-option
0x03, L2F_OPEN_RESP. This option MUST be followed by the octet 0x10,
specifying the size of the 128-bit MD5 digest resulting from
encrypting the challenge value in the L2F_CONF, along with the low
byte of the Assigned_CLID. After this byte MUST be the sixteen bytes
of the generated MD5 digest.
If during tunnel establishment an L2F_OPEN is received with an
incorrect L2F_OPEN_RESP, the packet MUST be silently discarded. It
is recommended that such an event generate a log event as well.
4.4.4 L2F_OPEN, client establishment
An L2F_OPEN (with non-zero MID) sent from the NAS to the Home Gateway
indicates the presence of a new dial-in client. When sent back from
the Home Gateway to the NAS, it indicates acceptance of the client.
This message starts with the octet 0x02. When sent from the NAS, it
may contain further sub-options. When sent from the Home Gateway, it
may not contain any sub-options. All further discussion of sub-
options in this section apply only to the NAS to Home Gateway
direction.
The L2F_OPEN_TYPE sub-option MUST be present. It is encoded as the
octet 0x06, followed by a single byte describing the type of
authentication the NAS exchanged with the client in detecting the
client's claimed identification. Implicit in the authentication type
is the encapsulation to be carried over the life of the session. The
authentication types are:
0x01 Textual username/password exchange for SLIP
0x02 PPP CHAP
0x03 PPP PAP
0x04 PPP no authentication
0x05 SLIP no authentication
Valencia, et. al. Historic [Page 20]
RFC 2341 Cisco L2F May 1998
The L2F_OPEN_NAME sub-option is encoded as the octet 0x01, followed
by an octet specifying the length of the name, followed by the
indicated number of bytes of the name. This field MUST be present
for any authentication type except 0x04 (None). It MUST contain the
name specified in the client's authentication response.
The L2F_OPEN_CHAL sub-option is encoded as the octet 0x02, followed
by an octet specifying the length of the challenge sent, followed by
the challenge itself. This field is only present for CHAP, and MUST
contain the challenge value sent to the client by the NAS.
The L2F_OPEN_RESP sub-option is encoded as the octet 0x03, followed
by an octet specifying the length of the response received, followed
by the client's response to the challenge. For CHAP, this field
contains the response value received by the NAS. For PAP or textual
authentication, it contains the clear text password received from the
client by the NAS. This field is absent for authentication 0x04
"None".
The L2F_ACK_LCP1 and L2F_ACK_LCP2 sub-options are encoded as the
octets 0x04 and 0x05 respectively, followed in either case by two
octets in network byte order specifying the length of the LCP CONFACK
last received from or sent to the client. Following these octets is
an exact copy of the CONFACK packet. L2F_ACK_LCP1 specifies a copy
of the closing CONFACK received from the client, and L2F_ACK_LCP2
specifies a copy of the closing CONFACK sent to the client by the
NAS.
The L2F_REQ_LCP0 sub-option is encoded as the octet 0x08, followed by
two octets in network byte order specifying the length of the LCP
CONFREQ initially received from the client. This may be used by the
Home Gateway to detect capabilities of the client which were
negotiated away while starting LCP with the NAS. Detection of such
options may be used by the Home Gateway to decide to renegotiate LCP.
The L2F_OPEN_ID sub-option is encoded as the octet 0x06, followed by
a single octet. This sub-option is only present for CHAP; the single
octet contains the CHAP Identifier value sent to the client during
the CHAP challenge.
The Home Gateway may choose to ignore any sub-option of the L2F_OPEN,
and accept the connection anyway. The Home Gateway would then have
to undertake its own LCP negotiations and authentication. To
maximize the transparency of the L2F tunnel, it is recommended that
extra negotiations and authentication be avoided if possible.
Valencia, et. al. Historic [Page 21]
RFC 2341 Cisco L2F May 1998
4.4.5 L2F_CLOSE
This message is encoded as the byte 0x03. An L2F_CLOSE may be sent
by either side of the tunnel at any time. When sent with MID of 0,
it indicates the desire to terminate the entire tunnel and all
clients within the tunnel. When sent from the Home Gateway in
response to an L2F_OPEN, it indicates that the Home Gateway has
declined the connection. When sent with a non-zero MID, it indicates
the termination of that client within the tunnel.
The L2F_CLOSE_WHY sub-option is encoded as the byte 0x01 followed
four bytes in network byte order specifying a bit mask of reasons for
the disconnection. The bits are encoded as:
0x00000001 Authentication failed
0x00000002 Out of resources
0x00000004 Administrative intervention
0x00000008 User quota exceeded
0x00000010 Protocol error
0x00000020 Unknown user
0x00000040 Incorrect password
0x00000080 PPP configuration incompatible
0x00000100 Wrong multilink PPP destination
Bits in the mask 0xFF000000 are reserved for per-vendor
interpretation.
An implementation can choose to not provide status bits even if it
detects a condition described by one of these bits. For instance, an
implementation may choose to not use 0x00000020 due to security
considerations, as it can be used to probe user name space.
The L2F_CLOSE_STR sub-option is encoded as the byte 0x02, followed by
a two-byte length in network byte order, followed by the indicated
number of bytes, which are interpreted as descriptive ASCII text
associated with the disconnection. This string may be ignored, but
could be recorded in a log to provide detailed or auxiliary
information associated with the L2F_CLOSE.
4.4.6 L2F_ECHO
Transmission of L2F_ECHO messages is optional. If an implementation
transmits L2F_ECHO messages, it MUST not transmit more than one such
request each second. The payload size MUST be 64 bytes or less in
length. It is recommended that at least 5 L2F_ECHO messages be sent
without response before an implementation assumes that its peer has
terminated.
Valencia, et. al. Historic [Page 22]
RFC 2341 Cisco L2F May 1998
The L2F_ECHO message is encoded as the single byte 0x04. It may be
sent by either side once the tunnel is established. MID MUST be 0.
An L2F_ECHO_RESP (documented below) MUST be sent back in response.
4.4.7 L2F_ECHO_RESP
All implementations MUST respond to L2F_ECHO, using L2F_ECHO_RESP.
The received packet MUST be sent back verbatim, except that the CLID,
sequence number, and checksum (if any) MUST be updated, and the
L2F_ECHO message type changed to an L2F_ECHO_RESP. Payload data
following the 0x04 octet, if any, MUST be preserved in the response.
When an L2F_ECHO_RESP is received, the payload data may be used to
associate this response with a previously sent L2F_ECHO, or the
packet may be silently discarded.
4.5 L2F Message Delivery
L2F is designed to operate over point-to-point unreliable links. It
is not designed to provide flow control of the data traffic, nor does
it provide reliable delivery of this traffic; each protocol tunnel
carried via L2F is expected to manage flow control and retry itself.
Thus, it is only L2F control messages which must be retransmitted;
this process is described in this section.
4.5.1 Sequenced delivery
All L2F control messages (i.e., those L2F packets with a protocol
type of 0x01) are transmitted with a sequence number. The sequence
number is a per-L2F tunnel free running counter which is incremented
(modulo 256) after each packet is transmitted. It is used to permit
the receiving end to detect duplicated or out-of-order packets, and
to discard such packets. Section 4.2.5 describes the process in
detail.
4.5.2 Flow control
L2F control messages are expected to be exchanged lock-step. Thus,
per-client activities can not occur until tunnel setup is complete.
Neither can one client be serviced until the L2F message exchange is
complete for a previous client. Thus, it is expected that rarely--if
ever--should a flow control action be required. If the input queue
of L2F control messages reaches an objectionable level for an
implementation, the implementation may silently discard all messages
in the queue to stabilize the situation.
Valencia, et. al. Historic [Page 23]
RFC 2341 Cisco L2F May 1998
4.5.3 Tunnel State table
The following enumerates the handling of L2F messages for tunnel
creation in state table format. Events name an L2F_ message type
(the L2F_ portion of the named message is omitted to permit a more
compact table). A start ("*") matches any event not otherwise
matched for the named state.
A NAS starts at initial state Start0, sending a packet before waiting
for its first event. A Home Gateway starts at Start1, waiting for an
initial packet to start service.
If an event is not matched for a given state, the packet associated
with that event is silently discarded.
Tunnel establishment (MID == 0), NAS side.
State Event Action New State
----- ----- ------ ---------
Start0 Send CONF Start1
Start1 CONF Send OPEN Start2
Start1 timeout 1-3 Send CONF Start1
Start1 timeout 4 Clean up tunnel (done)
Start2 OPEN (initiate 1st client) Open1
Start2 timeout 1-3 Send OPEN Start2
Start2 timeout 4 Clean up tunnel (done)
Open1 OPEN Send OPEN Open1
Open1 CLOSE Send CLOSE Close1
Open1 no MIDs open Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up tunnel (done)
Close2 CLOSE Clean up tunnel (done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up tunnel (done)
Tunnel establishment (MID == 0), Home Gateway side.
State Event Action New State
----- ----- ------ ---------
Start0 CONF Send CONF Start1
Start1 CONF Send CONF Start1
Start1 OPEN Send OPEN Open1
Start1 timeout 4 Clean up tunnel (done)
Open1 OPEN Send OPEN Open1
Open1 OPEN (MID > 0) (1st client, below) Open2
Open1 CLOSE Send CLOSE Close1
Open1 timeout 4 Clean up tunnel (done)
Valencia, et. al. Historic [Page 24]
RFC 2341 Cisco L2F May 1998
Open2 OPEN (MID > 0) (below) Open2
Open2 CLOSE Send CLOSE Close1
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up tunnel (done)
4.5.4 Client State table
This table is similar to the previous one, but enumerates the states
for a client connection within a tunnel in the opened state from
4.5.3. As this sequence addresses clients, MID will be non-zero.
Client establishment (MID != 0), NAS side.
State Event Action New State
----- ----- ------ ---------
Start0 Send OPEN Start1
Start1 OPEN (enable forwarding) Open1
Start1 CLOSE Clean up MID (MID done)
Start1 timeout 1-3 Send OPEN Start1
Start1 timeout 4 Clean up MID (MID done)
Start1 client done Send CLOSE Close2
Open1 OPEN (no change) Open1
Open1 CLOSE Send CLOSE Close1
Open1 client done Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up MID (MID done)
Close2 CLOSE Clean up MID (MID done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up MID (MID done)
Client establishment (MID != 0), Home Gateway side.
State Event Action New State
----- ----- ------ ---------
Start0 OPEN Send OPEN Open1
Start0 OPEN (fail) Send CLOSE Close3
Open1 OPEN Send OPEN Open1
Open1 CLOSE Send CLOSE Close1
Open1 client done Send CLOSE Close2
Close1 CLOSE Send CLOSE Close1
Close1 timeout 4 Clean up MID (MID done)
Close2 CLOSE Clean up MID (MID done)
Close2 timeout 1-3 Send CLOSE Close2
Close2 timeout 4 Clean up MID (MID done)
Close3 OPEN Send CLOSE Close3
Close3 timeout 4 Clean up MID (MID done)
Valencia, et. al. Historic [Page 25]
RFC 2341 Cisco L2F May 1998
quot;.
The per-association context value SHALL consist of the following
five octets:
The first two octets SHALL be zero (the Protocol ID for NTPv4).
The next two octets SHALL be the Numeric Identifier of the
negotiated AEAD Algorithm, in network byte order.
Franke, et al. Expires January 2, 2019 [Page 11]
Internet-Draft NTS4NTP July 2018
The final octet SHALL be 0x00 for the C2S key and 0x01 for the
S2C key.
Implementations wishing to derive additional keys for private or
experimental use MUST NOT do so by extending the above-specified
syntax for per-association context values. Instead, they SHOULD use
their own disambiguating label string. Note that RFC 5705 provides
that disambiguating label strings beginning with "EXPERIMENTAL" MAY
be used without IANA registration.
5.2. Packet structure overview
In general, an NTS-protected NTPv4 packet consists of:
The usual 48-octet NTP header, which is authenticated but not
encrypted.
Some extension fields which are authenticated but not encrypted.
An extension field which contains AEAD output (i.e., an
authentication tag and possible ciphertext). The corresponding
plaintext, if non-empty, consists of some extension fields which
benefit from both encryption and authentication.
Possibly, some additional extension fields which are neither
encrypted nor authenticated. These are discarded by the receiver.
Always included among the authenticated or authenticated-and-
encrypted extension fields are a cookie extension field and a unique-
identifier extension field. The purpose of the cookie extension
field is to enable the server to offload storage of session state
onto the client. The purpose of the unique-identifier extension
field is to protect the client from replay attacks.
5.3. The Unique Identifier extension field
The Unique Identifier extension field has a Field Type of [[TBD2]].
When the extension field is included in a client packet (mode 3), its
body SHALL consist of a string of octets generated uniformly at
random. The string MUST be at least 32 octets long. When the
extension field is included in a server packet (mode 4), its body
SHALL contain the same octet string as was provided in the client
packet to which the server is responding. Its use in modes other
than client-server is not defined.
The Unique Identifier extension field provides the client with a
cryptographically strong means of detecting replayed packets. It MAY
also be used standalone, without NTS, in which case it provides the
Franke, et al. Expires January 2, 2019 [Page 12]
Internet-Draft NTS4NTP July 2018
client with a means of detecting spoofed packets from off-path
attackers. Historically, NTP's origin timestamp field has played
both these roles, but for cryptographic purposes this is suboptimal
because it is only 64 bits long and, depending on implementation
details, most of those bits may be predictable. In contrast, the
Unique Identifier extension field enables a degree of
unpredictability and collision-resistance more consistent with
cryptographic best practice.
5.4. The NTS Cookie extension field
The NTS Cookie extension field has a Field Type of [[TBD3]]. Its
purpose is to carry information which enables the server to recompute
keys and other session state without having to store any per-client
state. The contents of its body SHALL be implementation-defined and
clients MUST NOT attempt to interpret them. See Section 7 for a
suggested construction. The NTS Cookie extension field MUST NOT be
included in NTP packets whose mode is other than 3 (client) or 4
(server).
5.5. The NTS Cookie Placeholder extension field
The NTS Cookie Placeholder extension field has a Field Type of
[[TBD4]]. When this extension field is included in a client packet
(mode 3), it communicates to the server that the client wishes it to
send additional cookies in its response. This extension field MUST
NOT be included in NTP packets whose mode is other than 3.
Whenever an NTS Cookie Placeholder extension field is present, it
MUST be accompanied by an NTS Cookie extension field, and the body
length of the NTS Cookie Placeholder extension field MUST be the same
as the body length of the NTS Cookie extension field. (This length
requirement serves to ensure that the response will not be larger
than the request, in order to improve timekeeping precision and
prevent DDoS amplification). The contents of the NTS Cookie
Placeholder extension field's body are undefined and, aside from
checking its length, MUST be ignored by the server.
5.6. The NTS Authenticator and Encrypted Extension Fields extension
field
The NTS Authenticator and Encrypted Extension Fields extension field
is the central cryptographic element of an NTS-protected NTP packet.
Its Field Type is [[TBD5]] and the format of its body SHALL be as
follows:
Nonce length: Two octets in network byte order, giving the length
of the Nonce field and interpreted as an unsigned integer.
Franke, et al. Expires January 2, 2019 [Page 13]
Internet-Draft NTS4NTP July 2018
Nonce: A nonce as required by the negotiated AEAD Algorithm.
Ciphertext: The output of the negotiated AEAD Algorithm. The
structure of this field is determined by the negotiated algorithm,
but it typically contains an authentication tag in addition to the
actual ciphertext.
Padding: several octets of padding, with every octet set to the
number of padding octets included, e.g., "01", "02 02", or "03 03
03". Constraints on the number of padding octets included are
enumerated below.
The Ciphertext field SHALL be formed by providing the following
inputs to the negotiated AEAD Algorithm:
K: For packets sent from the client to the server, the C2S key
SHALL be used. For packets sent from the server to the client,
the S2C key SHALL be used.
A: The associated data SHALL consist of the portion of the NTP
packet beginning from the start of the NTP header and ending at
the end of the last extension field which precedes the NTS
Authenticator and Encrypted Extension Fields extension field.
P: The plaintext SHALL consist of all (if any) NTP extension
fields to be encrypted. The format of any such fields SHALL be in
accordance with RFC 7822 [RFC7822], and if multiple extension
fields are present they SHALL be joined by concatenation.
N: The nonce SHALL be formed however required by the negotiated
AEAD Algorithm.
The number of padding octets included SHALL conform to the following
constraints:
The number MUST be at least 1, so that the final octet of the
extension field always gives the padding length.
The number MUST NOT be greater than 255, since high numbers are
unrepresentable in a single octet
The number MUST result in an extension field length which is legal
per [RFC7822]. That is, the number of padding octets must be
chosen so that the total length of the extension field (including
the Field Type and Length subfields) is a multiple of 4 greater
than or equal to 16, and greater than or equal to 28 if the
extension field is the last one in the packet.
Franke, et al. Expires January 2, 2019 [Page 14]
Internet-Draft NTS4NTP July 2018
For mode 3 (client) packets only, the number MUST be at least
MAX(MIN(N_MAX, 16) - N_len, 0) + 4, where `N_len` represents the
actual length of the nonce and N_MAX is, per [RFC5116], the
maximum permitted nonce length for the AEAD algorithm in use.
This constraint ensures that servers can always use an adequately
long nonce without causing the size of their response packet to
exceed the size of the request packet. Servers SHOULD enforce
this constraint by dropping client packets that do not conform to
it. Clients MUST NOT enforce it since it is not binding on mode 4
(server) packets to begin with.
The NTS Authenticator and Encrypted Extension Fields extension field
MUST NOT be included in NTP packets whose mode is other than 3
(client) or 4 (server).
6. Protocol details
A client sending an NTS-protected request SHALL include the following
extension fields as displayed in Figure 3:
Exactly one Unique Identifier extension field, which MUST be
authenticated, MUST NOT be encrypted, and whose contents MUST NOT
duplicate those of any previous request.
Exactly one NTS Cookie extension field, which MUST be
authenticated and MUST NOT be encrypted. The cookie MUST be one
which the server previously provided the client; it may have been
provided during the NTS-KE handshake or in response to a previous
NTS-protected NTP request. To protect client's privacy, the same
cookie SHOULD NOT be included in multiple requests. If the client
does not have any cookies that it has not already sent, it SHOULD
re-run the NTS-KE protocol before continuing.
Exactly one NTS Authenticator and Encrypted Extension Fields
extension field, generated using an AEAD Algorithm and C2S key
established through NTS-KE.
The client MAY include one or more NTS Cookie Placeholder extension
field, which MUST be authenticated and MAY be encrypted. The number
of NTS Cookie Placeholder extension fields that the client includes
SHOULD be such that if the client includes N placeholders and the
server sends back N+1 cookies, the number of unused cookies stored by
the client will come to eight. When both the client and server
adhere to all cookie-management guidance provided in this memo, the
number of placeholder extension fields will equal the number of
dropped packets since the last successful volley.
Franke, et al. Expires January 2, 2019 [Page 15]
Internet-Draft NTS4NTP July 2018
The client MAY include additional (non-NTS-related) extension fields,
which MAY appear prior to the NTS Authenticator and Encrypted
Extension Fields extension fields (therefore authenticated but not
encrypted), within it (therefore encrypted and authenticated), or
after it (therefore neither encrypted nor authenticated). In
general, however, the server MUST discard any unauthenticated
extension fields and process the packet as though they were not
present. Servers MAY implement exceptions to this requirement for
particular extension fields if their specification explicitly
provides for such.
Upon receiving an NTS-protected request, the server SHALL (through
some implementation-defined mechanism) use the cookie to recover the
AEAD Algorithm, C2S key, and S2C key associated with the request, and
then use the C2S key to authenticate the packet and decrypt the
ciphertext. If the cookie is valid and authentication and decryption
succeed, then the server SHALL include the following extension fields
in its response:
Exactly one Unique Identifier extension field, which MUST be
authenticated, MUST NOT be encrypted, and whose contents SHALL
echo those provided by the client.
Exactly one NTS Authenticator and Encrypted Extension Fields
extension field, generated using the AEAD algorithm and S2C key
recovered from the cookie provided by the client.
One or more NTS Cookie extension fields, which MUST be encrypted
and authenticated. The number of NTS Cookie extension fields
included SHOULD be equal to, and MUST NOT exceed, one plus the
number of valid NTS Cookie Placeholder extension fields included
in the request.
We emphasize the contrast that NTS Cookie extension fields MUST NOT
be encrypted when sent from client to server, but MUST be encrypted
from sent from server to client. The former is necessary in order
for the server to be able to recover the C2S and S2C keys, while the
latter is necessary to satisfy the unlinkability goals discussed in
Section 11.1. We emphasize also that " encrypted" means encapsulated
within the the NTS Authenticator and Encrypted Extensions extension
field. While the body of a NTS Cookie extension field will generally
consist of some sort of AEAD output (regardless of whether the
recommendations of Section 7 are precisely followed), this is not
sufficient to make the extension field "encrypted".
The server MAY include additional (non-NTS-related) extension fields,
which MAY appear prior to the NTS Authenticator and Encrypted
Extension Fields extension field (therefore authenticated but not
Franke, et al. Expires January 2, 2019 [Page 16]
Internet-Draft NTS4NTP July 2018
5. Protocol Considerations
Several aspects of operation over L2F, while outside the realm of the
protocol description itself, serve to clarify the operation of L2F.
5.1 PPP Features
Because L2F in operation carries uninterpreted frames, it permits
operation of features without explicit knowledge of these features.
For instance, if a PPP session is carried, L2F is simply transporting
HDLC frames. The two PPP endpoints can negotiate higher-level
features, such as reliable link, compression, multi-link, or
encryption. These features then operate between the two PPP
endpoints (the dial-in client on one end, and the Home Gateway on the
other), with L2F continuing to simply ship HDLC frames back and
forth.
For similar reasons, PPP echo requests, NCP configuration
negotiation, and even termination requests, are all simply tunneled
HDLC frames.
5.2 Termination
As L2F simply tunnels link-layer frames, it does not detect frames
like PPP TERMREQ. L2F termination in these scenarios is driven from
a protocol endpoint; for instance, if a Home Gateway receives a
TERMREQ, its action will be to "hang up" the PPP session. It is the
responsibility of the L2F implementation at the Home Gateway to
convert a "hang up" into an L2F_CLOSE action, which will shut down
client's session in the tunnel cleanly. L2F_CLOSE_WHY and
L2F_CLOSE_STR may be included to describe the reason for the
shutdown.
5.3 Extended Authentication
L2F is compatible with both PAP and CHAP protocols. SLIP does not
provide authentication within the protocol itself, and thus requires
an ASCII exchange of username and password before SLIP is started.
L2F is compatible with this mode of operation as well.
One-time password cards have become very common. To the extent the
NAS can capture and forward the one-time password, L2F operation is
compatible with password cards. For the most general solution, an
arbitrary request/response exchange must be supported. In an L2F
environment, the protocol must be structured so that the NAS can
detect the apparent identity of the user and establish a tunnel
connection to the Home Gateway, where the arbitrary exchange can
occur.
Valencia, et. al. Historic [Page 26]
RFC 2341 Cisco L2F May 1998
5.4 MNP4 and Apple Remote Access Protocol
L2F appears compatible with Apple's ARAP protocol. Its operation
under L2F has not been described simply because this experimental RFC
does not have a corresponding implementation of such operation.
5.5 Operation of IP and UDP
L2F tries to be self-describing, operating at a level above the
particular media over which it is carried. However, some details of
its connection to media are required to permit interoperable
implementations. This section describes the issues which have been
found when operating L2F over IP and UDP.
L2F uses the well-known UDP port 1701 [4]. The entire L2F packet,
including payload and L2F header, is sent within a UDP datagram. The
source and destination ports are the same (1701), with demultiplexing
being achieved using CLID values. It is legal for the source IP
address of a given CLID to change over the life of a connection, as
this may correspond to a peer with multiple IP interfaces responding
to a network topology change. Responses should reflect the last
source IP address for that CLID.
IP fragmentation may occur as the L2F packet travels over the IP
substrate. L2F makes no special efforts to optimize this. A NAS
implementation MAY cause its LCP to negotiate for a specific MRU,
which could optimize for NAS environments in which the MTUs of the
path over which the L2F packets are likely to travel have a
consistent value.
6.0 Acknowledgments
L2F uses a packet format inspired by GRE [5]. Thanks to Fred Baker
for consultation, Dave Carrel for consulting on security aspects, and
to Paul Traina for philosophical guidance.
7.0 References
[1] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over
Serial Lines: SLIP", RFC 1055, June 1988.
[2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[3] Simpson, W., "PPP in HDLC-like Framing", STD 51,, RFC 1662,
July 1994.
Valencia, et. al. Historic [Page 27]
RFC 2341 Cisco L2F May 1998
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[5] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
Encapsulation (GRE)", RFC 1701, October 1994.
8.0 Security Considerations
Security issues are discussed in Section 3.1.
9.0 Authors' Addresses
Tim Kolar
Cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: tkolar@cisco.com
Morgan Littlewood
Cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: littlewo@cisco.com
Andy Valencia
Cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
EMail: valencia@cisco.com
Valencia, et. al. Historic [Page 28]
RFC 2341 Cisco L2F May 1998
9.0 Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Valencia, et. al. Historic [Page 29]