idnits 2.17.1
draft-mavrogiannopoulos-openconnect-00.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 (September 23, 2016) is 2772 days in the past. Is
this intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 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 September 23, 2016
5 Expires: March 27, 2017
7 The OpenConnect VPN Protocol Version 1.0
8 draft-mavrogiannopoulos-openconnect-00
10 Abstract
12 This document specifies version 1.0 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 http://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 March 27, 2017.
36 Copyright Notice
38 Copyright (c) 2016 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 (http://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) . . . . . 10
62 2.1.5. Establishment of Secondary UDP Channel (DTLS) . . . . 11
63 2.2. The CSTP Channel Protocol . . . . . . . . . . . . . . . . 14
64 2.3. The DTLS Channel Protocol . . . . . . . . . . . . . . . . 15
65 2.4. The Channel Re-Key Protocol . . . . . . . . . . . . . . . 15
66 2.5. The Keepalive and Dead Peer Detection Protocols . . . . . 16
67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 17
68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
69 5. Normative References . . . . . . . . . . . . . . . . . . . . 18
70 Appendix A. Name for Application-Layer Protocol Negotiation . . 21
71 Appendix B. Compression . . . . . . . . . . . . . . . . . . . . 21
72 Appendix C. DTD declarations . . . . . . . . . . . . . . . . . . 21
73 C.1. config-auth.dtd . . . . . . . . . . . . . . . . . . . . . 21
74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
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 While there are many competing VPN protocol solutions, none of them
85 was ever described in a publicly available document. Even open
86 source VPN solutions have their source code as the primary
87 description of their protocol. That allowed no easy study of each
88 protocol's properties and weaknesses, and that is the secondary goal
89 of this document, to describe a deployed TLS based [RFC5246] VPN
90 protocol.
92 1.1. Requirements Terminology
94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
96 document are to be interpreted as described in [RFC2119].
98 1.2. Goals of This Document
100 The OpenConnect protocol version 1.0 specification is intended
101 primarily for readers who will be implementing the protocol and those
102 doing cryptographic analysis of it.
104 2. The OpenConnect Protocol
106 The OpenConnect protocol combines the TLS protocol [RFC5246],
107 Datagram TLS protocol [RFC6347] and HTTP protocols [RFC2616] to
108 provide an Internet-Layer VPN channel. The channel is designed to
109 operate using UDP packets, and fallback on TCP if that's not
110 possible.
112 In brief the protocol initiates an HTTP over TLS connection on a
113 known port, where client authentication is performed. After this
114 step, the client initiates an HTTP CONNECT command to establish a VPN
115 channel over TCP. A secondary VPN channel over UDP will be
116 established using information provided by the server using HTTP
117 headers. At that point the raw IP packets flow, over the VPN
118 channels.
120 2.1. VPN Session Establishment
122 The client and server establish a TLS connection over a known port,
123 typically over 443, the port used for HTTPS. The client SHOULD
124 negotiate TLS 1.1 or later, and support the following TLS protocol
125 extensions.
127 Server Name Indication [RFC6066]: the client SHOULD provide the
128 DNS name of the server in the TLS handshake.
130 Application-Layer Protocol Negotiation [RFC7301]: the client MAY
131 provide this protocol name. The protocol name to be used is
132 defined in Appendix A.
134 2.1.1. Server Authentication
136 In the OpenConnect VPN protocol, the server is always authenticated
137 using its certificate. Once a client establishes a TCP connection to
138 the server's well known port, it initiates the TLS protocol. In the
139 first connection to the server, the client SHOULD verify the provided
140 by the server certificate, and SHOULD store its public key for
141 verification of subsequent sessions. Thus, subsequent sessions
142 SHOULD check whether the server's key match the initial.
144 The server's identity in the certificate SHOULD be placed in the
145 certificate's SubjectAlternativeName field, and unless a special
146 profile is assumed, it will be of type DNSName.
148 2.1.2. Client Authentication
150 The OpenConnect VPN protocol allows for the following types of client
151 authentication, or combinations of them.
153 1. Password: a user can authenticate itself using a password.
155 2. Certificate: a user can authenticate itself using a PKIX
156 certificate it possesses.
158 3. HTTP SPNEGO: a user can authenticate itself using a Kerberos
159 ticket, or any other mechanism supported by SPNEGO (i.e.,
160 GSSAPI).
162 The server is authenticated to the client using a PKIX certificate
163 presented during the TLS negotiation.
165 It is important to note that during the password and HTTP SPNEGO
166 authentication methods, any headers allowed by the HTTP protocol can
167 be present. In fact, there are legacy clients which assume that the
168 server will keep a state using cookies, and send their username and
169 password in different TLS and HTTP connections. This practice
170 prevents the server from binding the TLS channel with the VPN session
171 [RFC5056], and is discouraged. It is RECOMMENDED for clients to
172 complete authentication in the same TLS session, and rely on TLS
173 session resumption if reconnections to the server are needed.
175 After the TLS session is established the client irrespective of the
176 supported authentication methods, should send an HTTP POST request on
177 "/" with a config-auth XML structure of type 'init'. An example of
178 its contents follow.
180
181
182
183 v5.01
184
186 The precise DTD declarations for the contents of XML messages defined
187 in this document are listed in Appendix C. Also the HTTP Content-
188 Type to be used for these XML structures MUST be 'text/xml'.
190 2.1.2.1. Authentication using certificates
192 During the initial TLS protocol handshake the server may require a
193 client certificate to be presented, depending on its configuration.
195 Because the client certificate is sent in the clear during the
196 handshake it SHOULD NOT contain other identifying information other
197 than a username, or a pseudonymus identifier. It is RECOMMENDED to
198 place the user identifier in the DN field of the certificate, using
199 the UID object identifier (0.9.2342.19200300.100.1.1) [RFC4519].
201 After the TLS session is established and the the config-auth XML
202 structure of type 'init' is sent, the server should send it reply.
203 If the certificate sent by the client was successfully validated, it
204 should reply using the HTTP response code 200, and the contents of
205 the reply should be a config-auth XML structure of type 'complete',
206 as follows.
208
209
210
211 0.1(1)
212
213 SSL VPN Service
214
215
217 In that case the client should proceed to the establishment of the
218 primary channel as in Section 2.1.4.
220 2.1.2.2. Authentication using passwords
222 After the TLS session is established and the the config-auth XML
223 structure of type 'init' is sent, the server will reply using forms
224 the client software should prompt the user to fill in. Its reply
225 utilizes a config-auth XML structure of type 'auth-request'.
227
228
229
230
231 Please enter your username
232
235
236
238 The client may be asked to provide the information in separate forms
239 as above, or may be asked combined as below.
241
242
243
244
245 Please enter your username
246
250
251
253 The client software will then fill in the provided form and sent it
254 back to the server using an HTTP POST on the location specified by
255 the server (in the above examples it was "/auth"). The reply would
256 then be of type 'auth-reply' as in the following example.
258
259
260
261 v5.01
262 test
263
264
266 As mentioned above, the server may ask repeatedly for information
267 until it believes the user is authenticated. For example, the server
268 could present a second form asking for the password, after the
269 username is provided, or ask for a second password if that is
270 necessary. In these cases the server should respond with an HTTP 200
271 OK status code, and proceed sending its new request.
273 If client authentication fails, the server MUST respond with an HTTP
274 401 unauthorized status code. Otherwise, on successful
275 authentication the server should reply with a 200 HTTP code and use
276 the 'complete' config-auth XML structure as in Section 2.1.2.1.
278 Note, that sending the username and password in different messages
279 will reveal the length of them to a passive eavesdropper. For that
280 is is RECOMMENDED for clients to use the 'X-Pad' HTTP header, which
281 will contain arbitrary printable data to make the message length a
282 multiple of 64 bytes.
284 An example session is shown in figure Figure 1.
286 ,-.
287 `-'
288 /|\
289 | ,------. ,----------.
290 / \ |Server| |ServerDTLS|
291 Client `--+---' `----+-----'
292 | TLS handshake Client Hello | |
293 | -----------------------------------> |
294 | | |
295 | TLS handshake Finished | |
296 | <----------------------------------- |
297 | | |
298 | HTTP POST config-auth init | ,--------------------!.
299 | -----------------------------------> |This is an HTTP over|_\
300 | | |TLS session. |
301 | | `----------------------'
302 | config-auth auth-request | |
303 | <----------------------------------- |
304 | | |
305 | HTTP POST config-auth auth-reply | |
306 | -----------------------------------> |
307 | | |
308 | config-auth complete | |
309 | <----------------------------------- |
310 | | |
311 | HTTP CONNECT | |
312 | -----------------------------------> |
313 | | |
314 | | |
315 | =================================== |
316 ====================== CSTP VPN session is established =======================
317 | =================================== |
318 | | |
319 | | ,-------------------------!.
320 | TLS record packet with CSTP payload| |These packets show |_\
321 | -----------------------------------> |that IP traffic can start |
322 | | |prior to the DTLS channel |
323 | | |establishment. |
324 | | `---------------------------'
325 | TLS record packet with CSTP payload| |
326 | <----------------------------------- |
327 | | |
328 | DTLS handshake Client Hello |
329 | - - - - - - - - - - - - - - - - - - - - - - - - - - - >
330 | | |
331 | DTLS handshake Finished |
332 | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
333 | | |
334 | | |
335 | =================================== |
336 ====================== DTLS VPN channel is established =======================
337 | =================================== |
338 | | |
339 | DTLS record packet with payload |
340 | - - - - - - - - - - - - - - - - - - - - - - - - - - - >
341 | | |
342 | DTLS record packet with payload |
343 | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
344 Client ,--+---. ,----+-----.
345 ,-. |Server| |ServerDTLS|
346 `-' `------' `----------'
347 /|\
348 |
349 / \
351 Figure 1
353 2.1.2.3. HTTP Authentication using SPNEGO
355 That type of authentication is performed using the HTTP SPNEGO
356 protocol [RFC4559], a method which is available using the Generic
357 Security Service API [RFC2743]. The following approach is used to
358 advertise the availability of the HTTP SPNEGO protocol by the client.
359 A client which supports the HTTP SPNEGO protocol, SHOULD indicate it
360 using the following header on in its initial request to the server
361 with the config-auth 'init' XML structure.
363 X-Support-HTTP-Auth: true
365 After that the server would report a "401 Unauthorized" status code
366 and authentication would proceed as specified in the HTTP SPNEGO
367 protocol. The server may utilize the following header, to indicate
368 that alternative authentication methods are available (e.g., with
369 plain password), if authentication fails.
371 X-Support-HTTP-Auth: fallback
373 If client authentication fails, the server MUST respond with an HTTP
374 401 unauthorized status code. In that case, a client which received
375 the previous header should retry authenticating to the server without
376 sending the "X-Support-HTTP-Auth: true" header.
378 Otherwise, on successful authentication the server should reply with
379 a 200 HTTP code and use the 'complete' config-auth XML structure as
380 in Section 2.1.2.1.
382 2.1.3. Exchange of Session Parameters
384 By the receipt of a success XML structure, the client SHOULD issue an
385 HTTP CONNECT request. In addition it may provide the following
386 headers.
388 X-CSTP-Address-Type: A comma separated list of the requested
389 address types.
391 IPv4: when the client only supports IPv4 addresses.
393 IPv6: when the client only supports IPv6 addresses.
395 IPv4,IPv6: when the client supports both types of IP addresses.
397 X-CSTP-Base-MTU: The MTU of the link as estimated by the client.
399 X-CSTP-Accept-Encoding: A comma separated list of accepted
400 compression algorithms for the CSTP channel.
402 User-Agent: A string identifying the client software.
404 For the options related to compression see Appendix B for more
405 information.
407 An example CONNECT request is shown below.
409 User-Agent: Open AnyConnect VPN Agent v5.01
410 X-CSTP-Base-MTU: 1280
411 X-CSTP-Address-Type: IPv4,IPv6
412 CONNECT /CSCOSSLC/tunnel HTTP/1.1
414 After a successful receipt of an HTTP CONNECT request, the server
415 should reply and provide the client with configuration parameters.
416 The available options follow.
418 X-CSTP-Address: The IPv4 address of the client, if IPv4 has been
419 requested.
421 X-CSTP-Netmask: An IPv4 netmask to be pushed to the client, if
422 IPv4 has been requested. This should contain the mask on the
423 P-t-P link and is RECOMMENDED the server address to be the first
424 in defined network.
426 X-CSTP-Address-IP6: The IPv6 address of the client in CIDR
427 notation, if IPv6 has been requested. The prefix length is
428 RECOMMENDED to be set to 127-bits according to [RFC6164].
430 X-CSTP-DNS: The IP address of a DNS server that can be used for
431 that session.
433 X-CSTP-Default-Domain: The DNS domains the provided DNS servers
434 respond for.
436 X-CSTP-Split-Include: The network address of a route which is
437 provided by this server.
439 X-CSTP-Split-Exclude: The network address of a route that is not
440 provided by this server.
442 X-CSTP-Base-MTU: The MTU of the link as estimated by this server.
444 X-CSTP-DynDNS: Set to "true" if the server is operating with a
445 dynamic DNS address.
447 X-CSTP-Content-Encoding: if present is it set to one of the values
448 presented by the client in 'X-CSTP-Accept-Encoding' header. It
449 will be the compression algorithm used in the CSTP channel.
451 X-DTLS-Content-Encoding: if present is it set to one of the values
452 presented by the client in 'X-DTLS-Accept-Encoding' header. It
453 will be the compression algorithm used in the DTLS channel.
455 The client is expected to treat the received parameters as his
456 networking settings. If no "X-CSTP-Split-Include" headers are
457 present, the client is expected to assign its default route through
458 the VPN.
460 2.1.4. Establishment of Primary TCP Channel (CSTP)
462 The previous HTTP message is the last HTTP message sent by the
463 server. After that message, the established TCP channel is used to
464 transport IP packets between the client and the server. The
465 transferred packets encoding is discussed in Section 2.2. This
466 channel will be referred as CSTP in the rest of this document.
468 2.1.5. Establishment of Secondary UDP Channel (DTLS)
470 To establish the secondary UDP-based channel, which will be referred
471 to as the DTLS channel, the client must advertise support for it
472 during the issue of the HTTP CONNECT request (see Section 2.1.3).
473 This is done by appending the following headers to the request.
475 X-DTLS-Accept-Encoding: A comma separated list of accepted
476 compression algorithms for the DTLS channel.
478 X-DTLS-CipherSuite: Must contain the keyword PSK-NEGOTIATE.
480 The DTLS channel utilizes the PSK key exchange method. The key
481 material for this session is a 256-bit value generated with an
482 [RFC5705] exporter. The key material exporter uses the label
483 "EXPORTER-openconnect-psk" without the quotes, and without any
484 context value.
486 In its client hello message the client must copy the value received
487 in the 'X-DTLS-App-ID' header (after hex decoding it), to a TLS
488 application-specific ID field [I-D.mavrogiannopoulos-app-id]. That
489 identifier, can be used by the server to associate the client
490 initiated DTLS channel with the CSTP channel. The following headers
491 are used by the server's response to CONNECT, and are related to the
492 DTLS channel establishment.
494 X-DTLS-App-ID: A hex encoded value to be used as a DTLS
495 application-specific identifier by the client. It serves as an
496 identifier for the server to associate the incoming DTLS session
497 with the TLS session.
499 X-DTLS-Port: The port number to which the client should send UDP
500 packets for DTLS.
502 X-DTLS-CipherSuite: It must contain the value "PSK-NEGOTIATE"
503 without any quotes.
505 X-DTLS-Rekey-Time: The time (in seconds) after which the DTLS
506 session should rekey, see Section 2.4. Only considered if
507 applicable to the negotiated DTLS protocol.
509 X-DTLS-Rekey-Method: The method used in DTLS rekey, see
510 Section 2.4. Only considered if applicable to the negotiated DTLS
511 protocol.
513 2.1.5.1. Legacy Establishment of Secondary UDP Channel (DTLS)
515 Previous versions of this protocol utilized a special DTLS protocol
516 negotiation, based on an unpublished description of the DTLS
517 protocol. This section attempts to summarize this negotiation, but
518 may not be entirely accurate.
520 To establish the legacy UDP-based channel, the client must advertise
521 support for it during the issue of the HTTP CONNECT request (see
522 Section 2.1.3). This is done by appending the following headers to
523 the request.
525 X-DTLS-Accept-Encoding: A comma separated list of accepted
526 compression algorithms for the DTLS channel.
528 X-DTLS-Master-Secret: A hex encoded pre-master secret to be used
529 in the legacy DTLS session negotiation.
531 X-DTLS-CipherSuite: A colon-separated list of ciphers (e.g., the
532 string PSK-NEGOTIATE:AES256-SHA:AES128-SHA:DES-CBC3-SHA).
534 The DTLS channel utilizes session resumption as a method for
535 preshared-key authentication. That is the value presented in X-DTLS-
536 Master-Secret is set as a master secret to be resumed. The session
537 ID value is sent by the server on the response to CONNECT using the
538 'X-DTLS-Session-ID' header. That header provides a hex-encoded value
539 of the DTLS session ID to be used by the client. The following
540 headers are used by the server's response to CONNECT, and are related
541 to the DTLS channel establishment.
543 X-DTLS-Session-ID: A hex encoded value to be used as a DTLS
544 session ID by the client. It also serves as an identifier for the
545 server to associate the incoming DTLS session with the TLS
546 session.
548 X-DTLS-Port: The port number to which the client should send UDP
549 packets for DTLS.
551 X-DTLS-CipherSuite: The ciphersuite selected by the server. It
552 should be one of the options present in the client's X-DTLS-
553 CipherSuite header.
555 X-DTLS-Rekey-Time: The time (in seconds) after which the DTLS
556 session should rekey, see Section 2.4.
558 X-DTLS-Rekey-Method: The method used in DTLS rekey, see
559 Section 2.4.
561 The following table lists the ciphers negotiated via the X-DTLS-
562 CipherSuite header, and the corresponding DTLS ciphersuite.
564 +--------------------+---------------------------------+------------+
565 | OpenConnect cipher | DTLS ciphersuite | DTLS |
566 | | | version |
567 +--------------------+---------------------------------+------------+
568 | DES-CBC3-SHA | TLS_RSA_WITH_3DES_EDE_CBC_SHA1 | DTLS 0.9 |
569 | | | (pre-draft |
570 | | | version) |
571 | | | |
572 | AES128-SHA | TLS_RSA_WITH_AES_128_CBC_SHA1 | DTLS 0.9 |
573 | | | (pre-draft |
574 | | | version) |
575 | | | |
576 | AES256-SHA | TLS_RSA_WITH_AES_256_CBC_SHA1 | DTLS 0.9 |
577 | | | (pre-draft |
578 | | | version) |
579 | | | |
580 | OC- | TLS_RSA_WITH_AES_128_GCM_SHA256 | DTLS 1.2 |
581 | DTLS1_2-AES128-GCM | | |
582 | | | |
583 | OC- | TLS_RSA_WITH_AES_256_GCM_SHA256 | DTLS 1.2 |
584 | DTLS1_2-AES256-GCM | | |
585 +--------------------+---------------------------------+------------+
587 Table 1
589 The legacy DTLS protocol negotiation described in this section, is
590 similar to DTLS 1.0 except for the following deviations:
592 The negotiated protocol version for the handshake and record
593 headers is 1.0 instead of 254.255.
595 The Hello Verify and Hello verify request messages are included in
596 the handshake hashes.
598 The handshake header is not included as part of the handshake
599 hashes.
601 The ChangeCipherSpec message is 3 byte long instead of 1, and
602 contains the handshake sequence number (2-bytes long) appended to
603 the message id.
605 2.2. The CSTP Channel Protocol
607 The format of the packets sent over the primary channel consists of
608 an 8-bytes header followed by data. The whole packet in encapsulated
609 in a TLS record (see [RFC5246]). The bytes of the header indicate
610 the type of data that follow, and their contents are explained in
611 Table 2.
613 +---------------------+---------------------------------------------+
614 | byte | value |
615 +---------------------+---------------------------------------------+
616 | 0 | fixed to 0x53 (S) |
617 | | |
618 | 1 | fixed to 0x54 (T) |
619 | | |
620 | 2 | fixed to 0x46 (F) |
621 | | |
622 | 3 | fixed to 0x01 |
623 | | |
624 | 4-5 | The length of the packet that follows this |
625 | | header in big endian order |
626 | | |
627 | 6 | The type of the payload that follows (see |
628 | | Table 3 for available types) |
629 | | |
630 | 7 | fixed to 0x00 |
631 +---------------------+---------------------------------------------+
633 Table 2
635 The available payload types are listed in Table 3.
637 +---------------------+---------------------------------------------+
638 | Value | Description |
639 +---------------------+---------------------------------------------+
640 | 0x00 | DATA: the TLS record packet contains an |
641 | | IPv4 or IPv6 packet |
642 | | |
643 | 0x03 | DPD-REQ: used for dead peer detection. Once |
644 | | sent the peer should reply with a DPD-RESP |
645 | | packet, that has the same contents as the |
646 | | original request. |
647 | | |
648 | 0x04 | DPD-RESP: used as a response to a |
649 | | previously received DPD-REQ. |
650 | | |
651 | 0x05 | DISCONNECT: sent by the client (or server) |
652 | | to terminate the session. No data is |
653 | | associated with this request. The session |
654 | | will be invalidated after such request. |
655 | | |
656 | 0x07 | KEEPALIVE: sent by any peer. No data is |
657 | | associated with this request. |
658 | | |
659 | 0x08 | COMPRESSED DATA: a Data packet which is |
660 | | compressed prior to encryption. |
661 | | |
662 | 0x09 | TERMINATE: sent by the server to indicate |
663 | | that the server is shutting down. No data |
664 | | is associated with this request. |
665 +---------------------+---------------------------------------------+
667 Table 3
669 2.3. The DTLS Channel Protocol
671 The format of the packets sent over the UDP channel consists of an
672 1-byte header followed by data. The header byte indicates the type
673 of data that follow as in Table 3. The header and the data are
674 encapsulated in a DTLS record packet (see [RFC6347]).
676 2.4. The Channel Re-Key Protocol
678 During the exchange of session parameters (Section 2.1.3), the server
679 advertizes the methods available for session rekey using the "X-CSTP-
680 Rekey-Method" and "X-DTLS-Rekey-Method" HTTP headers. The available
681 options for both the server and client are listed below.
683 1. none: no rekey; the session will go on until 2^48 DTLS records
684 have been exchanged, or 2^64 TLS records.
686 2. ssl: a TLS or DTLS rehandshake will be performed periodically.
688 3. new-tunnel: the session will tear down and the client will
689 reconnect periodically.
691 When the value is other than "none" the rekey period is determinated
692 by the "X-CSTP-Rekey-Time" and "X-DTLS-Rekey-Time" headers. These
693 headers contain the time in seconds after which a session should
694 rekey.
696 It should be noted that when the "ssl" rekey option is used, care
697 must be taken by both the client and the server to ensure that either
698 safe renegotiation is used ([RFC5746]), or that the identity of the
699 peer remained the same.
701 2.5. The Keepalive and Dead Peer Detection Protocols
703 In OpenConnect there are two packet types that can be used for keep-
704 alive or dead peer detection, as shown in Table 3. These are the
705 DPD-REQ and KeepAlive packets.
707 The timings of the transmission of these packets are set by the
708 server, and they for the DPD are advisory to a client. However, any
709 peer receiving these packets MUST response with the appropriate
710 packet. For DPD-REQ packets, the response MUST be DPD-RESP, and for
711 KeepAlive packets the response must be another KeepAlive packet. The
712 main difference between these two types of packets, is that the DPD
713 packets similarly to [RFC3706] are sent when there is no traffic or
714 when the other party requests them, and allow for arbitrary data to
715 be attached, making them suitable for Path MTU detection.
717 The server advertizes the suggested periods during the exchange of
718 session parameters (Section 2.1.3). The available headers are listed
719 below.
721 X-CSTP-DPD: applicable to CSTP channel; contains a relative time
722 in seconds.
724 X-CSTP-Keepalive: applicable to CSTP channel; contains a relative
725 time in seconds.
727 X-DTLS-DPD: applicable to DTLS channel; contains a relative time
728 in seconds.
730 X-DTLS-Keepalive: applicable to DTLS channel; contains a relative
731 time in seconds.
733 3. Security Considerations
735 This document provides a description of a protocol to establish a VPN
736 over a TLS channel. All security considerations of the referenced
737 documents in particular [RFC5246] and [RFC6347] are applicable, in
738 addition the following considerations.
740 The protocol is designed to be as compatible as possible with a
741 legacy VPN protocol and as such it carries cruft, such as partial
742 dependence on a non-standard DTLS version, and utilization of an
743 awkward method to establish a DTLS session which relies on session
744 resumption. Nevertheless, these particularities are not believed to
745 cause a degradation of the overall protocol security, and could be
746 addressed with a backwards compatible protocol upgrade.
748 The protocol provides a VPN channel which carries payload hidden from
749 eavesdroppers. However, the payload's length remain visible and in
750 certain scenarios that may be sufficient to determine the transferred
751 payload. Furthermore, there are scenarios where compressed payload
752 lengths may reveal more information than the uncompressed data
753 [COMP-ISSUES][COMP-ISSUES2]. For that we RECOMMEND that
754 implementations don't enable compression by default, and only allow
755 it after notifying the users and administrators about the
756 consequences.
758 This protocol could sometimes be used because of the fact that it
759 ressembles the TLS protocol and thus is not detected by the available
760 VPN blockers. While an implementation could intentionally masquerade
761 its packets to ressemble a typical HTTPS session, a fully compliant
762 implementation will be distinct from an average HTTP session due to
763 the DTLS session establishment, and the transferred packet sizes.
765 For certificate authentication OpenConnect relies on the TLS
766 protocol. However, as mentioned in the text, TLS version 1.2 and
767 earlier do not protect the client's (or the server's) certificate
768 from eavesdroppers. For that it is RECOMMENDED that certificates to
769 be used with this protocol contain the minimum possible identifying
770 information.
772 This document defines a protocol name for Application-Layer Protocol
773 Negotiation. That, if used by a client would indicate to any
774 eavesdropping parties that the client wishes to use VPN, thus
775 compromising its intention privacy. On the other hand, providing
776 that information would help a server that re-uses the same port for
777 different protocols under TLS, to forward to the appropriate handler
778 of the connection. That is, it would allow hosting a plain HTTPS
779 server serving content, and a VPN server using openconnect at the
780 same port. It is left to the client to decide the balance between
781 privacy and usability with such servers.
783 4. Acknowledgements
785 None yet.
787 5. Normative References
789 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
790 (TLS) Protocol Version 1.2", RFC 5246,
791 DOI 10.17487/RFC5246, August 2008,
792 .
794 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
795 "Transport Layer Security (TLS) Renegotiation Indication
796 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
797 .
799 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
800 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
801 January 2012, .
803 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
804 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
805 Transfer Protocol -- HTTP/1.1", RFC 2616,
806 DOI 10.17487/RFC2616, June 1999,
807 .
809 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
810 Kerberos and NTLM HTTP Authentication in Microsoft
811 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
812 .
814 [RFC2743] Linn, J., "Generic Security Service Application Program
815 Interface Version 2, Update 1", RFC 2743,
816 DOI 10.17487/RFC2743, January 2000,
817 .
819 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
820 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
821 .
823 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
824 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
825 March 2010, .
827 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
828 (LDAP): Schema for User Applications", RFC 4519,
829 DOI 10.17487/RFC4519, June 2006,
830 .
832 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
833 Extensions: Extension Definitions", RFC 6066,
834 DOI 10.17487/RFC6066, January 2011,
835 .
837 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
838 "Transport Layer Security (TLS) Application-Layer Protocol
839 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
840 July 2014, .
842 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
843 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
844 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
845 .
847 [RFC3706] Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic-
848 Based Method of Detecting Dead Internet Key Exchange (IKE)
849 Peers", RFC 3706, DOI 10.17487/RFC3706, February 2004,
850 .
852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
853 Requirement Levels", BCP 14, RFC 2119,
854 DOI 10.17487/RFC2119, March 1997,
855 .
857 [I-D.mavrogiannopoulos-app-id]
858 Mavrogiannopoulos, N. and D. Woodhouse, "A TLS
859 application-specific identifier", draft-mavrogiannopoulos-
860 app-id-00 (work in progress), September 2016.
862 [COMP-ISSUES]
863 Bhargavan, K., Fournet, C., Kohlweiss, M., Pironti, A.,
864 and P-Y. Strub, "TLS Compression Fingerprinting and a
865 Privacy-aware API for TLS", 2012.
867 [COMP-ISSUES2]
868 Kelsey, J., "Compression and information leakage of
869 plaintex", International Workshop on Fast Software
870 Encryption , 2002.
872 [OPENCONNECT-CLIENT]
873 Woodhouse, D., "http://www.infradead.org/openconnect/",
874 2016.
876 [OPENCONNECT-SERVER]
877 Mavrogiannopoulos, N., "http://www.infradead.org/ocserv/",
878 2016.
880 Appendix A. Name for Application-Layer Protocol Negotiation
882 Protocol: openconnect-vpn/1.0
883 Identification Sequence:
884 0x6f 0x70 0x65 0x6e 0x63 0x6f 0x6e 0x6e 0x65 0x63
885 0x74 0x2d 0x76 0x70 0x6e 0x2f 0x31 0x2e 0x30
887 Appendix B. Compression
889 The available compression algorithms for the CSTP and DTLS channels
890 are shown in Table 4. Note, that all algorithms are intentionally
891 stateless to prevent the influence of independent packets (e.g., from
892 different sources) on each others compression. That does not
893 eliminate all known attacks on compression before encryption, and for
894 that reason an implentation MUST NOT enable compression by default.
896 After compression is negotiated each side may choose to compress the
897 payload and use the 'COMPRESSED DATA' header from Table 3, or may
898 send uncompressed data with the 'DATA' payload. Each side MUST be
899 able to process both payloads.
901 +---------------------+---------------------------------------------+
902 | Algorithm | Description |
903 +---------------------+---------------------------------------------+
904 | oc-lz4 | The stateless LZ4 compression algorithm. |
905 | | |
906 | lzs | The stateless LZS (stacker) compression |
907 | | algorithm. |
908 +---------------------+---------------------------------------------+
910 Table 4
912 Appendix C. DTD declarations
914 C.1. config-auth.dtd
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
938 Author's Address
940 Nikos Mavrogiannopoulos
941 Red Hat
943 EMail: nmav@redhat.com