idnits 2.17.1
draft-mavrogiannopoulos-openconnect-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** There are 9 instances of too long lines in the document, the longest one
being 6 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 2, 2020) is 1300 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'I-D.ietf-tls-dtls13' is defined on line 715, but no
explicit reference was found in the text
== Outdated reference: A later version (-43) exists of
draft-ietf-tls-dtls13-37
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)
Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group N. Mavrogiannopoulos
3 Internet-Draft Red Hat
4 Intended status: Informational October 2, 2020
5 Expires: April 5, 2021
7 The OpenConnect VPN Protocol Version 1.2
8 draft-mavrogiannopoulos-openconnect-03
10 Abstract
12 This document specifies version 1.2 of the OpenConnect Virtual
13 Private Network (VPN) protocol, a secure VPN protocol that provides
14 communications privacy over the Internet. That protocol is believed
15 to be compatible with CISCO's AnyConnect VPN protocol. The protocol
16 allows the establishment of VPN tunnels in a way that is designed to
17 prevent eavesdropping, tampering, or message forgery.
19 Status of This Memo
21 This Internet-Draft is submitted in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF). Note that other groups may also distribute
26 working documents as Internet-Drafts. The list of current Internet-
27 Drafts is at https://datatracker.ietf.org/drafts/current/.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 This Internet-Draft will expire on April 5, 2021.
36 Copyright Notice
38 Copyright (c) 2020 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (https://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
54 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
55 1.2. Goals of This Document . . . . . . . . . . . . . . . . . 3
56 2. The OpenConnect Protocol . . . . . . . . . . . . . . . . . . 3
57 2.1. VPN Session Establishment . . . . . . . . . . . . . . . . 3
58 2.1.1. Server Authentication . . . . . . . . . . . . . . . . 3
59 2.1.2. Client Authentication . . . . . . . . . . . . . . . . 4
60 2.1.3. Exchange of Session Parameters . . . . . . . . . . . 9
61 2.1.4. Establishment of Primary TCP Channel (CSTP) . . . . . 11
62 2.1.5. Establishment of Secondary UDP Channel (DTLS) . . . . 11
63 2.2. The CSTP Channel Protocol . . . . . . . . . . . . . . . . 12
64 2.3. The DTLS Channel Protocol . . . . . . . . . . . . . . . . 13
65 2.4. The Channel Re-Key Protocol . . . . . . . . . . . . . . . 13
66 2.5. The Keepalive and Dead Peer Detection Protocols . . . . . 14
67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 15
68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
69 5. Normative References . . . . . . . . . . . . . . . . . . . . 16
70 Appendix A. Name for Application-Layer Protocol Negotiation . . 19
71 Appendix B. Compression . . . . . . . . . . . . . . . . . . . . 19
72 Appendix C. DTD declarations . . . . . . . . . . . . . . . . . . 19
73 C.1. config-auth.dtd . . . . . . . . . . . . . . . . . . . . . 19
74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
76 1. Introduction
78 The purpose of this document is to specify the OpenConnect VPN
79 protocol in a detail in order to allow for multiple interoperable
80 implementations. This is the protocol used by the OpenConnect client
81 and server [OPENCONNECT-CLIENT][OPENCONNECT-SERVER], and is believed
82 to be compatible with CISCO's AnyConnect protocol.
84 This protocol's design follows a minimalistic modular philosophy. It
85 delegates several protocol-related elements often considered as core
86 VPN features and diversifiers, to standards protocols. That
87 delegation, allows a minimalistic core protocol which contains very
88 few security related elements and is decoupled from cryptography.
89 That in turn transfers the auditing requirements due to cryptographic
90 and negotiation protocols to dedicated for that purpose components.
91 In particular the Openconnect VPN protocol uses standard protocols
92 such as HTTP, TLS [RFC8446] and DTLS [RFC6347] to provide a VPN with
93 data security and authenticity.
95 1.1. Requirements Terminology
97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
99 document are to be interpreted as described in [RFC2119].
101 1.2. Goals of This Document
103 The OpenConnect protocol version 1.2 specification is intended
104 primarily for readers who will be implementing the protocol and those
105 doing cryptographic analysis of it.
107 2. The OpenConnect Protocol
109 The OpenConnect protocol combines the TLS protocol [RFC8446],
110 Datagram TLS protocol [RFC6347] and HTTP protocols [RFC2616] to
111 provide an Internet-Layer VPN channel. The channel is designed to
112 operate using UDP packets, and fallback on TCP if that's not
113 possible.
115 In brief the protocol initiates an HTTP over TLS connection on a
116 known port, where client authentication is performed. After this
117 step, the client initiates an HTTP CONNECT command to establish a VPN
118 channel over TCP. A secondary VPN channel over UDP will be
119 established using information provided by the server using HTTP
120 headers. At that point the raw IP packets flow, over the VPN
121 channels.
123 2.1. VPN Session Establishment
125 The client and server establish a TLS connection over a known port,
126 typically over 443, the port used for HTTPS. The client SHOULD
127 negotiate TLS 1.2 or later, and support the following TLS protocol
128 extensions.
130 Server Name Indication [RFC6066]: the client SHOULD provide the
131 DNS name of the server in the TLS handshake.
133 Application-Layer Protocol Negotiation [RFC7301]: the client MAY
134 provide this protocol name. The protocol name to be used is
135 defined in Appendix A.
137 2.1.1. Server Authentication
139 In the OpenConnect VPN protocol, the server is always authenticated
140 using its certificate. Once a client establishes a TCP connection to
141 the server's well known port, it initiates the TLS protocol. In the
142 first connection to the server, the client SHOULD verify the provided
143 by the server certificate, and SHOULD store its public key for
144 verification of subsequent sessions. Thus, subsequent sessions
145 SHOULD check whether the server's key match the initial.
147 The server's identity in the certificate SHOULD be placed in the
148 certificate's SubjectAlternativeName field, and unless a special
149 profile is assumed, it will be of type DNSName.
151 2.1.2. Client Authentication
153 The OpenConnect VPN protocol allows for the following types of client
154 authentication, or combinations of them.
156 1. Password: a user can authenticate itself using a password.
158 2. Certificate: a user can authenticate itself using a PKIX
159 certificate it possesses.
161 3. HTTP SPNEGO: a user can authenticate itself using a Kerberos
162 ticket, or any other mechanism supported by SPNEGO (i.e.,
163 GSSAPI).
165 The server is authenticated to the client using a PKIX certificate
166 presented during the TLS negotiation.
168 It is important to note that during the password and HTTP SPNEGO
169 authentication methods, any headers allowed by the HTTP protocol can
170 be present. In fact, there are legacy clients which assume that the
171 server will keep a state using cookies, and send their username and
172 password in different TLS and HTTP connections. This practice
173 prevents the server from binding the TLS channel with the VPN session
174 [RFC5056], and is discouraged. It is RECOMMENDED for clients to
175 complete authentication in the same TLS session, and rely on TLS
176 session resumption if reconnections to the server are needed.
178 After the TLS session is established the client irrespective of the
179 supported authentication methods, should send an HTTP POST request on
180 "/" with a config-auth XML structure of type 'init'. An example of
181 its contents follow.
183
184
185
186 v5.01
187
189 The precise DTD declarations for the contents of XML messages defined
190 in this document are listed in Appendix C. Also the HTTP Content-
191 Type to be used for these XML structures MUST be 'text/xml'.
193 2.1.2.1. Authentication using certificates
195 During the initial TLS protocol handshake the server may require a
196 client certificate to be presented, depending on its configuration.
198 Because under TLS 1.2 the client certificate is sent in the clear
199 during the handshake, the certificate SHOULD NOT contain other
200 identifying information other than a username, or a pseudonymus
201 identifier. It is RECOMMENDED to place the user identifier in the DN
202 field of the certificate, using the UID object identifier
203 (0.9.2342.19200300.100.1.1) [RFC4519].
205 After the TLS session is established and the the config-auth XML
206 structure of type 'init' is sent, the server should send it reply.
207 If the certificate sent by the client was successfully validated, it
208 should reply using the HTTP response code 200, and the contents of
209 the reply should be a config-auth XML structure of type 'complete',
210 as follows.
212
213
214
215 0.1(1)
216
217 SSL VPN Service
218
219
221 In that case the client should proceed to the establishment of the
222 primary channel as in Section 2.1.4.
224 2.1.2.2. Authentication using passwords
226 After the TLS session is established and the the config-auth XML
227 structure of type 'init' is sent, the server will reply using forms
228 the client software should prompt the user to fill in. Its reply
229 utilizes a config-auth XML structure of type 'auth-request'.
231
232
233
234
235 Please enter your username
236
239
240
242 The client may be asked to provide the information in separate forms
243 as above, or may be asked combined as below.
245
246
247
248
249 Please enter your username
250
254
255
257 The client software will then fill in the provided form and sent it
258 back to the server using an HTTP POST on the location specified by
259 the server (in the above examples it was "/auth"). The reply would
260 then be of type 'auth-reply' as in the following example.
262
263
264
265 v5.01
266 test
267
268
270 As mentioned above, the server may ask repeatedly for information
271 until it believes the user is authenticated. For example, the server
272 could present a second form asking for the password, after the
273 username is provided, or ask for a second password if that is
274 necessary. In these cases the server should respond with an HTTP 200
275 OK status code, and proceed sending its new request.
277 If client authentication fails, the server MUST respond with an HTTP
278 401 unauthorized status code. Otherwise, on successful
279 authentication the server should reply with a 200 HTTP code and use
280 the 'complete' config-auth XML structure as in Section 2.1.2.1.
282 Note, that including the username and password in XML messages will
283 reveal the length of them to a passive eavesdropper. For that is is
284 RECOMMENDED for clients to use an 'X-Pad' HTTP header, containing
285 arbitrary printable data to make the message length a multiple of 64
286 bytes.
288 An example session is shown in figure Figure 1.
290 ,-.
291 `-'
292 /|\
293 | ,------. ,----------.
294 / \ |Server| |ServerDTLS|
295 Client `--+---' `----+-----'
296 | TLS handshake Client Hello | |
297 | -----------------------------------> |
298 | | |
299 | TLS handshake Finished | |
300 | <----------------------------------- |
301 | | |
302 | HTTP POST config-auth init | ,--------------------!.
303 | -----------------------------------> |This is an HTTP over|_\
304 | | |TLS session. |
305 | | `----------------------'
306 | config-auth auth-request | |
307 | <----------------------------------- |
308 | | |
309 | HTTP POST config-auth auth-reply | |
310 | -----------------------------------> |
311 | | |
312 | config-auth complete | |
313 | <----------------------------------- |
314 | | |
315 | HTTP CONNECT | |
316 | -----------------------------------> |
317 | | |
318 | | |
319 | =================================== |
320 ====================== CSTP VPN session is established =======================
321 | =================================== |
322 | | |
323 | | ,-------------------------!.
324 | TLS record packet with CSTP payload| |These packets show |_\
325 | -----------------------------------> |that IP traffic can start |
326 | | |prior to the DTLS channel |
327 | | |establishment. |
328 | | `---------------------------'
329 | TLS record packet with CSTP payload| |
330 | <----------------------------------- |
331 | | |
332 | DTLS handshake Client Hello |
333 | - - - - - - - - - - - - - - - - - - - - - - - - - - - >
334 | | |
335 | DTLS handshake Finished |
336 | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
337 | | |
338 | | |
339 | =================================== |
340 ====================== DTLS VPN channel is established =======================
341 | =================================== |
342 | | |
343 | DTLS record packet with payload |
344 | - - - - - - - - - - - - - - - - - - - - - - - - - - - >
345 | | |
346 | DTLS record packet with payload |
347 | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
348 Client ,--+---. ,----+-----.
349 ,-. |Server| |ServerDTLS|
350 `-' `------' `----------'
351 /|\
352 |
353 / \
355 Figure 1
357 2.1.2.3. HTTP Authentication using SPNEGO
359 That type of authentication is performed using the HTTP SPNEGO
360 protocol [RFC4559], a method which is available using the Generic
361 Security Service API [RFC2743]. The following approach is used to
362 advertise the availability of the HTTP SPNEGO protocol by the client.
363 A client which supports the HTTP SPNEGO protocol, SHOULD indicate it
364 using the following header on in its initial request to the server
365 with the config-auth 'init' XML structure.
367 X-Support-HTTP-Auth: true
369 After that the server would report a "401 Unauthorized" status code
370 and authentication would proceed as specified in the HTTP SPNEGO
371 protocol. The server may utilize the following header, to indicate
372 that alternative authentication methods are available (e.g., with
373 plain password), if authentication fails.
375 X-Support-HTTP-Auth: fallback
377 If client authentication fails, the server MUST respond with an HTTP
378 401 unauthorized status code. In that case, a client which received
379 the previous header should retry authenticating to the server without
380 sending the "X-Support-HTTP-Auth: true" header.
382 Otherwise, on successful authentication the server should reply with
383 a 200 HTTP code and use the 'complete' config-auth XML structure as
384 in Section 2.1.2.1.
386 2.1.3. Exchange of Session Parameters
388 By the receipt of a success XML structure, the client SHOULD issue an
389 HTTP CONNECT request. In addition it may provide the following
390 headers.
392 X-CSTP-Address-Type: A comma separated list of the requested
393 address types.
395 IPv4: when the client only supports IPv4 addresses.
397 IPv6: when the client only supports IPv6 addresses.
399 IPv4,IPv6: when the client supports both types of IP addresses.
401 X-CSTP-Base-MTU: The MTU of the link as estimated by the client.
403 X-CSTP-Accept-Encoding: A comma separated list of accepted
404 compression algorithms for the CSTP channel.
406 User-Agent: A string identifying the client software.
408 For the options related to compression see Appendix B for more
409 information.
411 An example CONNECT request is shown below.
413 User-Agent: Open AnyConnect VPN Agent v5.01
414 X-CSTP-Base-MTU: 1280
415 X-CSTP-Address-Type: IPv4,IPv6
416 CONNECT /CSCOSSLC/tunnel HTTP/1.1
418 After a successful receipt of an HTTP CONNECT request, the server
419 should reply and provide the client with configuration parameters.
420 The available options follow.
422 X-CSTP-Address: The IPv4 address of the client, if IPv4 has been
423 requested.
425 X-CSTP-Netmask: An IPv4 netmask to be pushed to the client, if
426 IPv4 has been requested. This should contain the mask on the
427 P-t-P link and is RECOMMENDED the server address to be the first
428 in defined network.
430 X-CSTP-Address-IP6: The IPv6 address of the client in CIDR
431 notation, if IPv6 has been requested. The prefix length is
432 RECOMMENDED to be set to 127-bits according to [RFC6164].
434 X-CSTP-DNS: The IP address of a DNS server that can be used for
435 that session.
437 X-CSTP-Default-Domain: The DNS default search domains. Typically
438 a subset of X-CSTP-Split-DNS. If multiple, the domains are space
439 separated.
441 X-CSTP-Split-DNS: A DNS domain the provided DNS servers respond
442 for. Multiple such headers may be present for different domains.
444 X-CSTP-Split-Include: The network address of a route which is
445 provided by this server. Multiple such headers may be present.
447 X-CSTP-Split-Exclude: The network address of a route that is not
448 provided by this server. Multiple such headers may be present.
450 X-CSTP-Base-MTU: The MTU of the link as estimated by this server.
452 X-CSTP-DynDNS: Set to "true" if the server is operating with a
453 dynamic DNS address.
455 X-CSTP-Content-Encoding: if present is it set to one of the values
456 presented by the client in 'X-CSTP-Accept-Encoding' header. It
457 will be the compression algorithm used in the CSTP channel.
459 X-DTLS-Content-Encoding: if present is it set to one of the values
460 presented by the client in 'X-DTLS-Accept-Encoding' header. It
461 will be the compression algorithm used in the DTLS channel.
463 The client is expected to treat the received parameters as his
464 networking settings. If no "X-CSTP-Split-Include" headers are
465 present, the client is expected to assign its default route through
466 the VPN.
468 2.1.4. Establishment of Primary TCP Channel (CSTP)
470 The previous HTTP message is the last HTTP message sent by the
471 server. After that message, the established TCP channel is used to
472 transport IP packets between the client and the server. The
473 transferred packets encoding is discussed in Section 2.2. This
474 channel will be referred as CSTP in the rest of this document.
476 2.1.5. Establishment of Secondary UDP Channel (DTLS)
478 To establish the secondary UDP-based channel, which will be referred
479 to as the DTLS channel, the client must advertise support for it
480 during the issue of the HTTP CONNECT request (see Section 2.1.3).
481 This is done by appending the following headers to the request.
483 X-DTLS-Accept-Encoding: A comma separated list of accepted
484 compression algorithms for the DTLS channel.
486 X-DTLS-CipherSuite: Must contain the keyword PSK-NEGOTIATE.
488 The DTLS channel utilizes the DTLS 1.2 protocol (or later version)
489 with the PSK key exchange method. The key material for this session
490 is a 256-bit value generated with an [RFC5705] exporter. The key
491 material exporter uses the label "EXPORTER-openconnect-psk" without
492 the quotes, and without any context value.
494 In its client hello message the client must copy the value received
495 in the 'X-DTLS-App-ID' header (after hex decoding it), to the session
496 ID field of the DTLS client hello. That identifier, is not used for
497 session resumption, and is used by the server to associate the DTLS
498 channel with the CSTP channel. The following headers are used by the
499 server's response to CONNECT, and are related to the DTLS channel
500 establishment.
502 X-DTLS-App-ID: A hex encoded value to be used as a DTLS
503 application-specific identifier by the client. It serves as an
504 identifier for the server to associate the incoming DTLS session
505 with the TLS session.
507 X-DTLS-Port: The port number to which the client should send UDP
508 packets for DTLS.
510 X-DTLS-CipherSuite: It must contain the value "PSK-NEGOTIATE"
511 without any quotes.
513 X-DTLS-Rekey-Time: The time (in seconds) after which the DTLS
514 session should rekey, see Section 2.4. Only considered if
515 applicable to the negotiated DTLS protocol.
517 X-DTLS-Rekey-Method: The method used in DTLS rekey, see
518 Section 2.4. Only considered if applicable to the negotiated DTLS
519 protocol.
521 2.2. The CSTP Channel Protocol
523 The format of the packets sent over the primary channel consists of
524 an 8-bytes header followed by data. The whole packet in encapsulated
525 in a TLS record (see [RFC8446]). The bytes of the header indicate
526 the type of data that follow, and their contents are explained in
527 Table 1.
529 +---------------------+---------------------------------------------+
530 | byte | value |
531 +---------------------+---------------------------------------------+
532 | 0 | fixed to 0x53 (S) |
533 | | |
534 | 1 | fixed to 0x54 (T) |
535 | | |
536 | 2 | fixed to 0x46 (F) |
537 | | |
538 | 3 | fixed to 0x01 |
539 | | |
540 | 4-5 | The length of the packet that follows this |
541 | | header in big endian order |
542 | | |
543 | 6 | The type of the payload that follows (see |
544 | | Table 2 for available types) |
545 | | |
546 | 7 | fixed to 0x00 |
547 +---------------------+---------------------------------------------+
549 Table 1
551 The available payload types are listed in Table 2.
553 +---------------------+---------------------------------------------+
554 | Value | Description |
555 +---------------------+---------------------------------------------+
556 | 0x00 | DATA: the TLS record packet contains an |
557 | | IPv4 or IPv6 packet |
558 | | |
559 | 0x03 | DPD-REQ: used for dead peer detection. Once |
560 | | sent the peer should reply with a DPD-RESP |
561 | | packet, that has the same contents as the |
562 | | original request. |
563 | | |
564 | 0x04 | DPD-RESP: used as a response to a |
565 | | previously received DPD-REQ. |
566 | | |
567 | 0x05 | DISCONNECT: sent by the client (or server) |
568 | | to terminate the session. This is followed |
569 | | by one byte indicating the disconnect |
570 | | reason. When the reason is '0xb0' the |
571 | | session should be invalidated after the |
572 | | request. |
573 | | |
574 | 0x07 | KEEPALIVE: sent by any peer. No data is |
575 | | associated with this request. |
576 | | |
577 | 0x08 | COMPRESSED DATA: a Data packet which is |
578 | | compressed prior to encryption. |
579 | | |
580 | 0x09 | TERMINATE: sent by the server to indicate |
581 | | that the server is shutting down. No data |
582 | | is associated with this request. |
583 +---------------------+---------------------------------------------+
585 Table 2
587 2.3. The DTLS Channel Protocol
589 The format of the packets sent over the UDP channel consists of an
590 1-byte header followed by data. The header byte indicates the type
591 of data that follow as in Table 2. The header and the data are
592 encapsulated in a DTLS record packet (see [RFC6347]).
594 2.4. The Channel Re-Key Protocol
596 During the exchange of session parameters (Section 2.1.3), the server
597 advertizes the methods available for session rekey using the "X-CSTP-
598 Rekey-Method" and "X-DTLS-Rekey-Method" HTTP headers. The available
599 options for both the server and client are listed below.
601 1. none: no rekey; the session will go on until 2^48 DTLS records
602 have been exchanged, or 2^64 TLS records.
604 2. ssl: a TLS or DTLS rekey will be performed periodically. Under
605 TLS/DTLS 1.2 this is performed using a rehandshake, and in later
606 versions using a rekey.
608 3. new-tunnel: the session will tear down and the client will
609 reconnect periodically.
611 When the value is other than "none" the rekey period is determinated
612 by the "X-CSTP-Rekey-Time" and "X-DTLS-Rekey-Time" headers. These
613 headers contain the time in seconds after which a session should
614 rekey.
616 It should be noted that when the "ssl" rekey option is used under
617 TLS1.2, care must be taken by both the client and the server to
618 ensure that either safe renegotiation is used ([RFC5746]), or that
619 the identity of the peer remained the same.
621 2.5. The Keepalive and Dead Peer Detection Protocols
623 In OpenConnect there are two packet types that can be used for keep-
624 alive or dead peer detection, as shown in Table 2. These are the
625 DPD-REQ and KeepAlive packets.
627 The timings of the transmission of these packets are set by the
628 server, and they for the DPD are advisory to a client. However, any
629 peer receiving these packets MUST response with the appropriate
630 packet. For DPD-REQ packets, the response MUST be DPD-RESP, and for
631 KeepAlive packets the response must be another KeepAlive packet. The
632 main difference between these two types of packets, is that the DPD
633 packets similarly to [RFC3706] are sent when there is no traffic or
634 when the other party requests them, and allow for arbitrary data to
635 be attached, making them suitable for Path MTU detection.
637 The server advertizes the suggested periods during the exchange of
638 session parameters (Section 2.1.3). The available headers are listed
639 below.
641 X-CSTP-DPD: applicable to CSTP channel; contains a relative time
642 in seconds.
644 X-CSTP-Keepalive: applicable to CSTP channel; contains a relative
645 time in seconds.
647 X-DTLS-DPD: applicable to DTLS channel; contains a relative time
648 in seconds.
650 X-DTLS-Keepalive: applicable to DTLS channel; contains a relative
651 time in seconds.
653 3. Security Considerations
655 This document provides a description of a protocol to establish a VPN
656 over a TLS 1.2 or later channel. All security considerations of the
657 referenced documents in particular [RFC8446] and [RFC6347] are
658 applicable, in addition the following considerations.
660 The protocol is designed to be as compatible as possible with a
661 legacy VPN protocol. This compatibility is not believed to cause a
662 degradation of the overall protocol security.
664 The protocol provides a VPN channel which carries payload hidden from
665 eavesdroppers. However, the payload's length remain visible and in
666 certain scenarios that may be sufficient to determine the transferred
667 payload. Furthermore, there are scenarios where compressed payload
668 lengths may reveal more information than the uncompressed data
669 [COMP-ISSUES][COMP-ISSUES2]. For that we RECOMMEND that
670 implementations don't enable compression by default, and only allow
671 it when explicitly enabled by administrators who are aware of the
672 consequences.
674 This protocol could sometimes be used because it ressembles the TLS
675 protocol and thus is not detected by the available VPN blockers.
676 While an implementation could intentionally masquerade its packets to
677 ressemble a typical HTTPS session, a fully compliant implementation
678 will be distinct from an average HTTP session due to the DTLS session
679 establishment, and the transferred packet sizes.
681 For certificate authentication OpenConnect relies on the TLS
682 protocol. However, as mentioned in the text, TLS version 1.2 and
683 earlier do not protect the client's (or the server's) certificate
684 from eavesdroppers. For that it is RECOMMENDED that certificates to
685 be used with this protocol contain the minimum possible identifying
686 information.
688 This document defines a protocol name for Application-Layer Protocol
689 Negotiation. That, if used by a client would indicate to any
690 eavesdropping parties that the client wishes to use VPN, thus
691 compromising its intention privacy. On the other hand, providing
692 that information would help a server that re-uses the same port for
693 different protocols under TLS, to forward to the appropriate handler
694 of the connection. That is, it would allow hosting a plain HTTPS
695 server serving content, and a VPN server using openconnect at the
696 same port. It is left to the client implementation to decide the
697 balance between privacy and usability with such servers.
699 4. Acknowledgements
701 None yet.
703 5. Normative References
705 [COMP-ISSUES]
706 Bhargavan, K., Fournet, C., Kohlweiss, M., Pironti, A.,
707 and P-Y. Strub, "TLS Compression Fingerprinting and a
708 Privacy-aware API for TLS", 2012.
710 [COMP-ISSUES2]
711 Kelsey, J., "Compression and information leakage of
712 plaintex", International Workshop on Fast Software
713 Encryption , 2002.
715 [I-D.ietf-tls-dtls13]
716 Rescorla, E., Tschofenig, H., and N. Modadugu, "The
717 Datagram Transport Layer Security (DTLS) Protocol Version
718 1.3", draft-ietf-tls-dtls13-37 (work in progress), March
719 2020.
721 [OPENCONNECT-CLIENT]
722 Woodhouse, D., "http://www.infradead.org/openconnect/",
723 2016.
725 [OPENCONNECT-SERVER]
726 Mavrogiannopoulos, N., "http://www.infradead.org/ocserv/",
727 2016.
729 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
730 Requirement Levels", BCP 14, RFC 2119,
731 DOI 10.17487/RFC2119, March 1997,
732 .
734 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
735 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
736 Transfer Protocol -- HTTP/1.1", RFC 2616,
737 DOI 10.17487/RFC2616, June 1999,
738 .
740 [RFC2743] Linn, J., "Generic Security Service Application Program
741 Interface Version 2, Update 1", RFC 2743,
742 DOI 10.17487/RFC2743, January 2000,
743 .
745 [RFC3706] Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic-
746 Based Method of Detecting Dead Internet Key Exchange (IKE)
747 Peers", RFC 3706, DOI 10.17487/RFC3706, February 2004,
748 .
750 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
751 (LDAP): Schema for User Applications", RFC 4519,
752 DOI 10.17487/RFC4519, June 2006,
753 .
755 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
756 Kerberos and NTLM HTTP Authentication in Microsoft
757 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
758 .
760 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
761 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
762 .
764 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
765 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
766 March 2010, .
768 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
769 "Transport Layer Security (TLS) Renegotiation Indication
770 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
771 .
773 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
774 Extensions: Extension Definitions", RFC 6066,
775 DOI 10.17487/RFC6066, January 2011,
776 .
778 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
779 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
780 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
781 .
783 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
784 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
785 January 2012, .
787 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
788 "Transport Layer Security (TLS) Application-Layer Protocol
789 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
790 July 2014, .
792 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
793 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
794 .
796 Appendix A. Name for Application-Layer Protocol Negotiation
798 Protocol: openconnect-vpn/1.2
799 Identification Sequence:
800 0x6f 0x70 0x65 0x6e 0x63 0x6f 0x6e 0x6e 0x65 0x63
801 0x74 0x2d 0x76 0x70 0x6e 0x2f 0x31 0x2e 0x32
803 Appendix B. Compression
805 The available compression algorithms for the CSTP and DTLS channels
806 are shown in Table 3. Note, that all algorithms are intentionally
807 stateless to prevent the influence of independent packets (e.g., from
808 different sources) on each others compression. That does not
809 eliminate all known attacks on compression before encryption, and for
810 that reason an implentation MUST NOT enable compression by default.
812 After compression is negotiated each side may choose to compress the
813 payload and use the 'COMPRESSED DATA' header from Table 2, or may
814 send uncompressed data with the 'DATA' payload. Each side MUST be
815 able to process both payloads.
817 +---------------------+---------------------------------------------+
818 | Algorithm | Description |
819 +---------------------+---------------------------------------------+
820 | oc-lz4 | The stateless LZ4 compression algorithm. |
821 | | |
822 | lzs | The stateless LZS (stacker) compression |
823 | | algorithm. |
824 +---------------------+---------------------------------------------+
826 Table 3
828 Appendix C. DTD declarations
830 C.1. config-auth.dtd
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
854 Author's Address
856 Nikos Mavrogiannopoulos
857 Red Hat
859 EMail: nmav@redhat.com