< draft-mavrogiannopoulos-openconnect-02.txt		draft-mavrogiannopoulos-openconnect-03.txt >
	Network Working Group N. Mavrogiannopoulos		Network Working Group N. Mavrogiannopoulos
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Intended status: Informational October 14, 2018		Intended status: Informational October 2, 2020
	Expires: April 17, 2019		Expires: April 5, 2021
	The OpenConnect VPN Protocol Version 1.1		The OpenConnect VPN Protocol Version 1.2
	draft-mavrogiannopoulos-openconnect-02		draft-mavrogiannopoulos-openconnect-03
	Abstract		Abstract
	This document specifies version 1.1 of the OpenConnect Virtual		This document specifies version 1.2 of the OpenConnect Virtual
	Private Network (VPN) protocol, a secure VPN protocol that provides		Private Network (VPN) protocol, a secure VPN protocol that provides
	communications privacy over the Internet. That protocol is believed		communications privacy over the Internet. That protocol is believed
	to be compatible with CISCO's AnyConnect VPN protocol. The protocol		to be compatible with CISCO's AnyConnect VPN protocol. The protocol
	allows the establishment of VPN tunnels in a way that is designed to		allows the establishment of VPN tunnels in a way that is designed to
	prevent eavesdropping, tampering, or message forgery.		prevent eavesdropping, tampering, or message forgery.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 17, 2019.		This Internet-Draft will expire on April 5, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3		1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
	1.2. Goals of This Document . . . . . . . . . . . . . . . . . 3		1.2. Goals of This Document . . . . . . . . . . . . . . . . . 3
	2. The OpenConnect Protocol . . . . . . . . . . . . . . . . . . 3		2. The OpenConnect Protocol . . . . . . . . . . . . . . . . . . 3
	2.1. VPN Session Establishment . . . . . . . . . . . . . . . . 3		2.1. VPN Session Establishment . . . . . . . . . . . . . . . . 3
	2.1.1. Server Authentication . . . . . . . . . . . . . . . . 3		2.1.1. Server Authentication . . . . . . . . . . . . . . . . 3
	2.1.2. Client Authentication . . . . . . . . . . . . . . . . 4		2.1.2. Client Authentication . . . . . . . . . . . . . . . . 4
	2.1.3. Exchange of Session Parameters . . . . . . . . . . . 9		2.1.3. Exchange of Session Parameters . . . . . . . . . . . 9
	2.1.4. Establishment of Primary TCP Channel (CSTP) . . . . . 10		2.1.4. Establishment of Primary TCP Channel (CSTP) . . . . . 11
	2.1.5. Establishment of Secondary UDP Channel (DTLS) . . . . 11		2.1.5. Establishment of Secondary UDP Channel (DTLS) . . . . 11
	2.2. The CSTP Channel Protocol . . . . . . . . . . . . . . . . 14		2.2. The CSTP Channel Protocol . . . . . . . . . . . . . . . . 12
	2.3. The DTLS Channel Protocol . . . . . . . . . . . . . . . . 15		2.3. The DTLS Channel Protocol . . . . . . . . . . . . . . . . 13
	2.4. The Channel Re-Key Protocol . . . . . . . . . . . . . . . 15		2.4. The Channel Re-Key Protocol . . . . . . . . . . . . . . . 13
	2.5. The Keepalive and Dead Peer Detection Protocols . . . . . 16		2.5. The Keepalive and Dead Peer Detection Protocols . . . . . 14
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 17		3. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
	5. Normative References . . . . . . . . . . . . . . . . . . . . 18		5. Normative References . . . . . . . . . . . . . . . . . . . . 16
	Appendix A. Name for Application-Layer Protocol Negotiation . . 21		Appendix A. Name for Application-Layer Protocol Negotiation . . 19
	Appendix B. Compression . . . . . . . . . . . . . . . . . . . . 21		Appendix B. Compression . . . . . . . . . . . . . . . . . . . . 19
	Appendix C. DTD declarations . . . . . . . . . . . . . . . . . . 21		Appendix C. DTD declarations . . . . . . . . . . . . . . . . . . 19
	C.1. config-auth.dtd . . . . . . . . . . . . . . . . . . . . . 21		C.1. config-auth.dtd . . . . . . . . . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The purpose of this document is to specify the OpenConnect VPN		The purpose of this document is to specify the OpenConnect VPN
	protocol in a detail in order to allow for multiple interoperable		protocol in a detail in order to allow for multiple interoperable
	implementations. This is the protocol used by the OpenConnect client		implementations. This is the protocol used by the OpenConnect client
	and server [OPENCONNECT-CLIENT][OPENCONNECT-SERVER], and is believed		and server [OPENCONNECT-CLIENT][OPENCONNECT-SERVER], and is believed
	to be compatible with CISCO's AnyConnect protocol.		to be compatible with CISCO's AnyConnect protocol.
	This protocol's design follows a minimalistic modular philosophy. It		This protocol's design follows a minimalistic modular philosophy. It
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	data security and authenticity.		data security and authenticity.
	1.1. Requirements Terminology		1.1. Requirements Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.2. Goals of This Document		1.2. Goals of This Document
	The OpenConnect protocol version 1.1 specification is intended		The OpenConnect protocol version 1.2 specification is intended
	primarily for readers who will be implementing the protocol and those		primarily for readers who will be implementing the protocol and those
	doing cryptographic analysis of it.		doing cryptographic analysis of it.
	2. The OpenConnect Protocol		2. The OpenConnect Protocol
	The OpenConnect protocol combines the TLS protocol [RFC8446],		The OpenConnect protocol combines the TLS protocol [RFC8446],
	Datagram TLS protocol [RFC6347] and HTTP protocols [RFC2616] to		Datagram TLS protocol [RFC6347] and HTTP protocols [RFC2616] to
	provide an Internet-Layer VPN channel. The channel is designed to		provide an Internet-Layer VPN channel. The channel is designed to
	operate using UDP packets, and fallback on TCP if that's not		operate using UDP packets, and fallback on TCP if that's not
	possible.		possible.
	skipping to change at page 3, line 37 ¶		skipping to change at page 3, line 37 ¶
	step, the client initiates an HTTP CONNECT command to establish a VPN		step, the client initiates an HTTP CONNECT command to establish a VPN
	channel over TCP. A secondary VPN channel over UDP will be		channel over TCP. A secondary VPN channel over UDP will be
	established using information provided by the server using HTTP		established using information provided by the server using HTTP
	headers. At that point the raw IP packets flow, over the VPN		headers. At that point the raw IP packets flow, over the VPN
	channels.		channels.
	2.1. VPN Session Establishment		2.1. VPN Session Establishment
	The client and server establish a TLS connection over a known port,		The client and server establish a TLS connection over a known port,
	typically over 443, the port used for HTTPS. The client SHOULD		typically over 443, the port used for HTTPS. The client SHOULD
	negotiate TLS 1.1 or later, and support the following TLS protocol		negotiate TLS 1.2 or later, and support the following TLS protocol
	extensions.		extensions.
	Server Name Indication [RFC6066]: the client SHOULD provide the		Server Name Indication [RFC6066]: the client SHOULD provide the
	DNS name of the server in the TLS handshake.		DNS name of the server in the TLS handshake.
	Application-Layer Protocol Negotiation [RFC7301]: the client MAY		Application-Layer Protocol Negotiation [RFC7301]: the client MAY
	provide this protocol name. The protocol name to be used is		provide this protocol name. The protocol name to be used is
	defined in Appendix A.		defined in Appendix A.
	2.1.1. Server Authentication		2.1.1. Server Authentication
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	The precise DTD declarations for the contents of XML messages defined		The precise DTD declarations for the contents of XML messages defined
	in this document are listed in Appendix C. Also the HTTP Content-		in this document are listed in Appendix C. Also the HTTP Content-
	Type to be used for these XML structures MUST be 'text/xml'.		Type to be used for these XML structures MUST be 'text/xml'.
	2.1.2.1. Authentication using certificates		2.1.2.1. Authentication using certificates
	During the initial TLS protocol handshake the server may require a		During the initial TLS protocol handshake the server may require a
	client certificate to be presented, depending on its configuration.		client certificate to be presented, depending on its configuration.
	Because the client certificate is sent in the clear during the		Because under TLS 1.2 the client certificate is sent in the clear
	handshake it SHOULD NOT contain other identifying information other		during the handshake, the certificate SHOULD NOT contain other
	than a username, or a pseudonymus identifier. It is RECOMMENDED to		identifying information other than a username, or a pseudonymus
	place the user identifier in the DN field of the certificate, using		identifier. It is RECOMMENDED to place the user identifier in the DN
	the UID object identifier (0.9.2342.19200300.100.1.1) [RFC4519].		field of the certificate, using the UID object identifier
			(0.9.2342.19200300.100.1.1) [RFC4519].
	After the TLS session is established and the the config-auth XML		After the TLS session is established and the the config-auth XML
	structure of type 'init' is sent, the server should send it reply.		structure of type 'init' is sent, the server should send it reply.
	If the certificate sent by the client was successfully validated, it		If the certificate sent by the client was successfully validated, it
	should reply using the HTTP response code 200, and the contents of		should reply using the HTTP response code 200, and the contents of
	the reply should be a config-auth XML structure of type 'complete',		the reply should be a config-auth XML structure of type 'complete',
	as follows.		as follows.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE config-auth SYSTEM "config-auth.dtd">		<!DOCTYPE config-auth SYSTEM "config-auth.dtd">
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	could present a second form asking for the password, after the		could present a second form asking for the password, after the
	username is provided, or ask for a second password if that is		username is provided, or ask for a second password if that is
	necessary. In these cases the server should respond with an HTTP 200		necessary. In these cases the server should respond with an HTTP 200
	OK status code, and proceed sending its new request.		OK status code, and proceed sending its new request.
	If client authentication fails, the server MUST respond with an HTTP		If client authentication fails, the server MUST respond with an HTTP
	401 unauthorized status code. Otherwise, on successful		401 unauthorized status code. Otherwise, on successful
	authentication the server should reply with a 200 HTTP code and use		authentication the server should reply with a 200 HTTP code and use
	the 'complete' config-auth XML structure as in Section 2.1.2.1.		the 'complete' config-auth XML structure as in Section 2.1.2.1.
	Note, that sending the username and password in different messages		Note, that including the username and password in XML messages will
	will reveal the length of them to a passive eavesdropper. For that		reveal the length of them to a passive eavesdropper. For that is is
	is is RECOMMENDED for clients to use the 'X-Pad' HTTP header, which		RECOMMENDED for clients to use an 'X-Pad' HTTP header, containing
	will contain arbitrary printable data to make the message length a		arbitrary printable data to make the message length a multiple of 64
	multiple of 64 bytes.		bytes.
	An example session is shown in figure Figure 1.		An example session is shown in figure Figure 1.
	,-.		,-.
	`-'		`-'
	/|\		/|\
	| ,------. ,----------.		| ,------. ,----------.
	/ \ |Server| |ServerDTLS|		/ \ |Server| |ServerDTLS|
	Client `--+---' `----+-----'		Client `--+---' `----+-----'
	| TLS handshake Client Hello | |		| TLS handshake Client Hello | |
	skipping to change at page 10, line 20 ¶		skipping to change at page 10, line 20 ¶
	P-t-P link and is RECOMMENDED the server address to be the first		P-t-P link and is RECOMMENDED the server address to be the first
	in defined network.		in defined network.
	X-CSTP-Address-IP6: The IPv6 address of the client in CIDR		X-CSTP-Address-IP6: The IPv6 address of the client in CIDR
	notation, if IPv6 has been requested. The prefix length is		notation, if IPv6 has been requested. The prefix length is
	RECOMMENDED to be set to 127-bits according to [RFC6164].		RECOMMENDED to be set to 127-bits according to [RFC6164].
	X-CSTP-DNS: The IP address of a DNS server that can be used for		X-CSTP-DNS: The IP address of a DNS server that can be used for
	that session.		that session.
	X-CSTP-Default-Domain: The DNS domains the provided DNS servers		X-CSTP-Default-Domain: The DNS default search domains. Typically
	respond for.		a subset of X-CSTP-Split-DNS. If multiple, the domains are space
			separated.
			X-CSTP-Split-DNS: A DNS domain the provided DNS servers respond
			for. Multiple such headers may be present for different domains.
	X-CSTP-Split-Include: The network address of a route which is		X-CSTP-Split-Include: The network address of a route which is
	provided by this server.		provided by this server. Multiple such headers may be present.
	X-CSTP-Split-Exclude: The network address of a route that is not		X-CSTP-Split-Exclude: The network address of a route that is not
	provided by this server.		provided by this server. Multiple such headers may be present.
	X-CSTP-Base-MTU: The MTU of the link as estimated by this server.		X-CSTP-Base-MTU: The MTU of the link as estimated by this server.
	X-CSTP-DynDNS: Set to "true" if the server is operating with a		X-CSTP-DynDNS: Set to "true" if the server is operating with a
	dynamic DNS address.		dynamic DNS address.
	X-CSTP-Content-Encoding: if present is it set to one of the values		X-CSTP-Content-Encoding: if present is it set to one of the values
	presented by the client in 'X-CSTP-Accept-Encoding' header. It		presented by the client in 'X-CSTP-Accept-Encoding' header. It
	will be the compression algorithm used in the CSTP channel.		will be the compression algorithm used in the CSTP channel.
	skipping to change at page 11, line 19 ¶		skipping to change at page 11, line 25 ¶
	To establish the secondary UDP-based channel, which will be referred		To establish the secondary UDP-based channel, which will be referred
	to as the DTLS channel, the client must advertise support for it		to as the DTLS channel, the client must advertise support for it
	during the issue of the HTTP CONNECT request (see Section 2.1.3).		during the issue of the HTTP CONNECT request (see Section 2.1.3).
	This is done by appending the following headers to the request.		This is done by appending the following headers to the request.
	X-DTLS-Accept-Encoding: A comma separated list of accepted		X-DTLS-Accept-Encoding: A comma separated list of accepted
	compression algorithms for the DTLS channel.		compression algorithms for the DTLS channel.
	X-DTLS-CipherSuite: Must contain the keyword PSK-NEGOTIATE.		X-DTLS-CipherSuite: Must contain the keyword PSK-NEGOTIATE.
	The DTLS channel utilizes the PSK key exchange method. The key		The DTLS channel utilizes the DTLS 1.2 protocol (or later version)
	material for this session is a 256-bit value generated with an		with the PSK key exchange method. The key material for this session
	[RFC5705] exporter. The key material exporter uses the label		is a 256-bit value generated with an [RFC5705] exporter. The key
	"EXPORTER-openconnect-psk" without the quotes, and without any		material exporter uses the label "EXPORTER-openconnect-psk" without
	context value.		the quotes, and without any context value.
	In its client hello message the client must copy the value received		In its client hello message the client must copy the value received
	in the 'X-DTLS-App-ID' header (after hex decoding it), to the session		in the 'X-DTLS-App-ID' header (after hex decoding it), to the session
	ID field of the DTLS client hello. That identifier, is not used for		ID field of the DTLS client hello. That identifier, is not used for
	session resumption, and is used by the server to associate the DTLS		session resumption, and is used by the server to associate the DTLS
	channel with the CSTP channel. The following headers are used by the		channel with the CSTP channel. The following headers are used by the
	server's response to CONNECT, and are related to the DTLS channel		server's response to CONNECT, and are related to the DTLS channel
	establishment.		establishment.
	X-DTLS-App-ID: A hex encoded value to be used as a DTLS		X-DTLS-App-ID: A hex encoded value to be used as a DTLS
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 9 ¶
	without any quotes.		without any quotes.
	X-DTLS-Rekey-Time: The time (in seconds) after which the DTLS		X-DTLS-Rekey-Time: The time (in seconds) after which the DTLS
	session should rekey, see Section 2.4. Only considered if		session should rekey, see Section 2.4. Only considered if
	applicable to the negotiated DTLS protocol.		applicable to the negotiated DTLS protocol.
	X-DTLS-Rekey-Method: The method used in DTLS rekey, see		X-DTLS-Rekey-Method: The method used in DTLS rekey, see
	Section 2.4. Only considered if applicable to the negotiated DTLS		Section 2.4. Only considered if applicable to the negotiated DTLS
	protocol.		protocol.
	Note that in future versions of the Datagram TLS protocol (see
	[I-D.ietf-tls-dtls13]), clients should supply the value in 'X-DTLS-
	App-ID' header as a PSK identity after hex decoding it.
	2.1.5.1. Legacy Establishment of Secondary UDP Channel (DTLS)
	Previous versions of this protocol utilized a special DTLS protocol
	negotiation, based on an unpublished description of the DTLS
	protocol. This section attempts to summarize this negotiation, but
	may not be entirely accurate.
	To establish the legacy UDP-based channel, the client must advertise
	support for it during the issue of the HTTP CONNECT request (see
	Section 2.1.3). This is done by appending the following headers to
	the request.
	X-DTLS-Accept-Encoding: A comma separated list of accepted
	compression algorithms for the DTLS channel.
	X-DTLS-Master-Secret: A hex encoded pre-master secret to be used
	in the legacy DTLS session negotiation.
	X-DTLS-CipherSuite: A colon-separated list of ciphers (e.g., the
	string PSK-NEGOTIATE:AES256-SHA:AES128-SHA:DES-CBC3-SHA).
	The DTLS channel utilizes session resumption as a method for
	preshared-key authentication. That is the value presented in X-DTLS-
	Master-Secret is set as a master secret to be resumed. The session
	ID value is sent by the server on the response to CONNECT using the
	'X-DTLS-Session-ID' header. That header provides a hex-encoded value
	of the DTLS session ID to be used by the client. The following
	headers are used by the server's response to CONNECT, and are related
	to the DTLS channel establishment.
	X-DTLS-Session-ID: A hex encoded value to be used as a DTLS
	session ID by the client. It also serves as an identifier for the
	server to associate the incoming DTLS session with the TLS
	session.
	X-DTLS-Port: The port number to which the client should send UDP
	packets for DTLS.
	X-DTLS-CipherSuite: The ciphersuite selected by the server. It
	should be one of the options present in the client's X-DTLS-
	CipherSuite header.
	X-DTLS-Rekey-Time: The time (in seconds) after which the DTLS
	session should rekey, see Section 2.4.
	X-DTLS-Rekey-Method: The method used in DTLS rekey, see
	Section 2.4.
	The following table lists the ciphers negotiated via the X-DTLS-
	CipherSuite header, and the corresponding DTLS ciphersuite.
	+--------------------+---------------------------------+------------+
	| OpenConnect cipher | DTLS ciphersuite | DTLS |
	| | | version |
	+--------------------+---------------------------------+------------+
	| DES-CBC3-SHA | TLS_RSA_WITH_3DES_EDE_CBC_SHA1 | DTLS 0.9 |
	| | | (pre-draft |
	| | | version) |
	| | | |
	| AES128-SHA | TLS_RSA_WITH_AES_128_CBC_SHA1 | DTLS 0.9 |
	| | | (pre-draft |
	| | | version) |
	| | | |
	| AES256-SHA | TLS_RSA_WITH_AES_256_CBC_SHA1 | DTLS 0.9 |
	| | | (pre-draft |
	| | | version) |
	| | | |
	| OC- | TLS_RSA_WITH_AES_128_GCM_SHA256 | DTLS 1.2 |
	| DTLS1_2-AES128-GCM | | |
	| | | |
	| OC- | TLS_RSA_WITH_AES_256_GCM_SHA256 | DTLS 1.2 |
	| DTLS1_2-AES256-GCM | | |
	+--------------------+---------------------------------+------------+
	Table 1
	The legacy DTLS protocol negotiation described in this section, is
	similar to DTLS 1.0 except for the following deviations:
	The negotiated protocol version for the handshake and record
	headers is 1.0 instead of 254.255.
	The Hello Verify and Hello verify request messages are included in
	the handshake hashes.
	The handshake header is not included as part of the handshake
	hashes.
	The ChangeCipherSpec message is 3 byte long instead of 1, and
	contains the handshake sequence number (2-bytes long) appended to
	the message id.
	2.2. The CSTP Channel Protocol		2.2. The CSTP Channel Protocol
	The format of the packets sent over the primary channel consists of		The format of the packets sent over the primary channel consists of
	an 8-bytes header followed by data. The whole packet in encapsulated		an 8-bytes header followed by data. The whole packet in encapsulated
	in a TLS record (see [RFC8446]). The bytes of the header indicate		in a TLS record (see [RFC8446]). The bytes of the header indicate
	the type of data that follow, and their contents are explained in		the type of data that follow, and their contents are explained in
	Table 2.		Table 1.
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	| byte | value |		| byte | value |
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	| 0 | fixed to 0x53 (S) |		| 0 | fixed to 0x53 (S) |
	| | |		| | |
	| 1 | fixed to 0x54 (T) |		| 1 | fixed to 0x54 (T) |
	| | |		| | |
	| 2 | fixed to 0x46 (F) |		| 2 | fixed to 0x46 (F) |
	| | |		| | |
	| 3 | fixed to 0x01 |		| 3 | fixed to 0x01 |
	| | |		| | |
	| 4-5 | The length of the packet that follows this |		| 4-5 | The length of the packet that follows this |
	| | header in big endian order |		| | header in big endian order |
	| | |		| | |
	| 6 | The type of the payload that follows (see |		| 6 | The type of the payload that follows (see |
	| | Table 3 for available types) |		| | Table 2 for available types) |
	| | |		| | |
	| 7 | fixed to 0x00 |		| 7 | fixed to 0x00 |
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	Table 2		Table 1
	The available payload types are listed in Table 3.		The available payload types are listed in Table 2.
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	| Value | Description |		| Value | Description |
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	| 0x00 | DATA: the TLS record packet contains an |		| 0x00 | DATA: the TLS record packet contains an |
	| | IPv4 or IPv6 packet |		| | IPv4 or IPv6 packet |
	| | |		| | |
	| 0x03 | DPD-REQ: used for dead peer detection. Once |		| 0x03 | DPD-REQ: used for dead peer detection. Once |
	| | sent the peer should reply with a DPD-RESP |		| | sent the peer should reply with a DPD-RESP |
	| | packet, that has the same contents as the |		| | packet, that has the same contents as the |
	| | original request. |		| | original request. |
	| | |		| | |
	| 0x04 | DPD-RESP: used as a response to a |		| 0x04 | DPD-RESP: used as a response to a |
	| | previously received DPD-REQ. |		| | previously received DPD-REQ. |
	| | |		| | |
	| 0x05 | DISCONNECT: sent by the client (or server) |		| 0x05 | DISCONNECT: sent by the client (or server) |
	| | to terminate the session. No data is |		| | to terminate the session. This is followed |
	| | associated with this request. The session |		| | by one byte indicating the disconnect |
	| | will be invalidated after such request. |		| | reason. When the reason is '0xb0' the |
			| | session should be invalidated after the |
			| | request. |
	| | |		| | |
	| 0x07 | KEEPALIVE: sent by any peer. No data is |		| 0x07 | KEEPALIVE: sent by any peer. No data is |
	| | associated with this request. |		| | associated with this request. |
	| | |		| | |
	| 0x08 | COMPRESSED DATA: a Data packet which is |		| 0x08 | COMPRESSED DATA: a Data packet which is |
	| | compressed prior to encryption. |		| | compressed prior to encryption. |
	| | |		| | |
	| 0x09 | TERMINATE: sent by the server to indicate |		| 0x09 | TERMINATE: sent by the server to indicate |
	| | that the server is shutting down. No data |		| | that the server is shutting down. No data |
	| | is associated with this request. |		| | is associated with this request. |
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	Table 3		Table 2
	2.3. The DTLS Channel Protocol		2.3. The DTLS Channel Protocol
	The format of the packets sent over the UDP channel consists of an		The format of the packets sent over the UDP channel consists of an
	1-byte header followed by data. The header byte indicates the type		1-byte header followed by data. The header byte indicates the type
	of data that follow as in Table 3. The header and the data are		of data that follow as in Table 2. The header and the data are
	encapsulated in a DTLS record packet (see [RFC6347]).		encapsulated in a DTLS record packet (see [RFC6347]).
	2.4. The Channel Re-Key Protocol		2.4. The Channel Re-Key Protocol
	During the exchange of session parameters (Section 2.1.3), the server		During the exchange of session parameters (Section 2.1.3), the server
	advertizes the methods available for session rekey using the "X-CSTP-		advertizes the methods available for session rekey using the "X-CSTP-
	Rekey-Method" and "X-DTLS-Rekey-Method" HTTP headers. The available		Rekey-Method" and "X-DTLS-Rekey-Method" HTTP headers. The available
	options for both the server and client are listed below.		options for both the server and client are listed below.
	1. none: no rekey; the session will go on until 2^48 DTLS records		1. none: no rekey; the session will go on until 2^48 DTLS records
	have been exchanged, or 2^64 TLS records.		have been exchanged, or 2^64 TLS records.
	2. ssl: a TLS or DTLS rehandshake will be performed periodically.		2. ssl: a TLS or DTLS rekey will be performed periodically. Under
			TLS/DTLS 1.2 this is performed using a rehandshake, and in later
			versions using a rekey.
	3. new-tunnel: the session will tear down and the client will		3. new-tunnel: the session will tear down and the client will
	reconnect periodically.		reconnect periodically.
	When the value is other than "none" the rekey period is determinated		When the value is other than "none" the rekey period is determinated
	by the "X-CSTP-Rekey-Time" and "X-DTLS-Rekey-Time" headers. These		by the "X-CSTP-Rekey-Time" and "X-DTLS-Rekey-Time" headers. These
	headers contain the time in seconds after which a session should		headers contain the time in seconds after which a session should
	rekey.		rekey.
	It should be noted that when the "ssl" rekey option is used, care		It should be noted that when the "ssl" rekey option is used under
	must be taken by both the client and the server to ensure that either		TLS1.2, care must be taken by both the client and the server to
	safe renegotiation is used ([RFC5746]), or that the identity of the		ensure that either safe renegotiation is used ([RFC5746]), or that
	peer remained the same.		the identity of the peer remained the same.
	2.5. The Keepalive and Dead Peer Detection Protocols		2.5. The Keepalive and Dead Peer Detection Protocols
	In OpenConnect there are two packet types that can be used for keep-		In OpenConnect there are two packet types that can be used for keep-
	alive or dead peer detection, as shown in Table 3. These are the		alive or dead peer detection, as shown in Table 2. These are the
	DPD-REQ and KeepAlive packets.		DPD-REQ and KeepAlive packets.
	The timings of the transmission of these packets are set by the		The timings of the transmission of these packets are set by the
	server, and they for the DPD are advisory to a client. However, any		server, and they for the DPD are advisory to a client. However, any
	peer receiving these packets MUST response with the appropriate		peer receiving these packets MUST response with the appropriate
	packet. For DPD-REQ packets, the response MUST be DPD-RESP, and for		packet. For DPD-REQ packets, the response MUST be DPD-RESP, and for
	KeepAlive packets the response must be another KeepAlive packet. The		KeepAlive packets the response must be another KeepAlive packet. The
	main difference between these two types of packets, is that the DPD		main difference between these two types of packets, is that the DPD
	packets similarly to [RFC3706] are sent when there is no traffic or		packets similarly to [RFC3706] are sent when there is no traffic or
	when the other party requests them, and allow for arbitrary data to		when the other party requests them, and allow for arbitrary data to
	skipping to change at page 17, line 8 ¶		skipping to change at page 15, line 11 ¶
	X-DTLS-DPD: applicable to DTLS channel; contains a relative time		X-DTLS-DPD: applicable to DTLS channel; contains a relative time
	in seconds.		in seconds.
	X-DTLS-Keepalive: applicable to DTLS channel; contains a relative		X-DTLS-Keepalive: applicable to DTLS channel; contains a relative
	time in seconds.		time in seconds.
	3. Security Considerations		3. Security Considerations
	This document provides a description of a protocol to establish a VPN		This document provides a description of a protocol to establish a VPN
	over a TLS channel. All security considerations of the referenced		over a TLS 1.2 or later channel. All security considerations of the
	documents in particular [RFC8446] and [RFC6347] are applicable, in		referenced documents in particular [RFC8446] and [RFC6347] are
	addition the following considerations.		applicable, in addition the following considerations.
	The protocol is designed to be as compatible as possible with a		The protocol is designed to be as compatible as possible with a
	legacy VPN protocol and as such it carries cruft, such as partial		legacy VPN protocol. This compatibility is not believed to cause a
	dependence on a non-standard DTLS version, and utilization of an		degradation of the overall protocol security.
	awkward method to establish a DTLS session which relies on session
	resumption. Nevertheless, these particularities are not believed to
	cause a degradation of the overall protocol security, and could be
	addressed with a backwards compatible protocol upgrade.
	The protocol provides a VPN channel which carries payload hidden from		The protocol provides a VPN channel which carries payload hidden from
	eavesdroppers. However, the payload's length remain visible and in		eavesdroppers. However, the payload's length remain visible and in
	certain scenarios that may be sufficient to determine the transferred		certain scenarios that may be sufficient to determine the transferred
	payload. Furthermore, there are scenarios where compressed payload		payload. Furthermore, there are scenarios where compressed payload
	lengths may reveal more information than the uncompressed data		lengths may reveal more information than the uncompressed data
	[COMP-ISSUES][COMP-ISSUES2]. For that we RECOMMEND that		[COMP-ISSUES][COMP-ISSUES2]. For that we RECOMMEND that
	implementations don't enable compression by default, and only allow		implementations don't enable compression by default, and only allow
	it after notifying the users and administrators about the		it when explicitly enabled by administrators who are aware of the
	consequences.		consequences.
	This protocol could sometimes be used because of the fact that it		This protocol could sometimes be used because it ressembles the TLS
	ressembles the TLS protocol and thus is not detected by the available		protocol and thus is not detected by the available VPN blockers.
	VPN blockers. While an implementation could intentionally masquerade		While an implementation could intentionally masquerade its packets to
	its packets to ressemble a typical HTTPS session, a fully compliant		ressemble a typical HTTPS session, a fully compliant implementation
	implementation will be distinct from an average HTTP session due to		will be distinct from an average HTTP session due to the DTLS session
	the DTLS session establishment, and the transferred packet sizes.		establishment, and the transferred packet sizes.
	For certificate authentication OpenConnect relies on the TLS		For certificate authentication OpenConnect relies on the TLS
	protocol. However, as mentioned in the text, TLS version 1.2 and		protocol. However, as mentioned in the text, TLS version 1.2 and
	earlier do not protect the client's (or the server's) certificate		earlier do not protect the client's (or the server's) certificate
	from eavesdroppers. For that it is RECOMMENDED that certificates to		from eavesdroppers. For that it is RECOMMENDED that certificates to
	be used with this protocol contain the minimum possible identifying		be used with this protocol contain the minimum possible identifying
	information.		information.
	This document defines a protocol name for Application-Layer Protocol		This document defines a protocol name for Application-Layer Protocol
	Negotiation. That, if used by a client would indicate to any		Negotiation. That, if used by a client would indicate to any
	eavesdropping parties that the client wishes to use VPN, thus		eavesdropping parties that the client wishes to use VPN, thus
	compromising its intention privacy. On the other hand, providing		compromising its intention privacy. On the other hand, providing
	that information would help a server that re-uses the same port for		that information would help a server that re-uses the same port for
	different protocols under TLS, to forward to the appropriate handler		different protocols under TLS, to forward to the appropriate handler
	of the connection. That is, it would allow hosting a plain HTTPS		of the connection. That is, it would allow hosting a plain HTTPS
	server serving content, and a VPN server using openconnect at the		server serving content, and a VPN server using openconnect at the
	same port. It is left to the client to decide the balance between		same port. It is left to the client implementation to decide the
	privacy and usability with such servers.		balance between privacy and usability with such servers.
	4. Acknowledgements		4. Acknowledgements
	None yet.		None yet.
	5. Normative References		5. Normative References
	[COMP-ISSUES]		[COMP-ISSUES]
	Bhargavan, K., Fournet, C., Kohlweiss, M., Pironti, A.,		Bhargavan, K., Fournet, C., Kohlweiss, M., Pironti, A.,
	and P-Y. Strub, "TLS Compression Fingerprinting and a		and P-Y. Strub, "TLS Compression Fingerprinting and a
	Privacy-aware API for TLS", 2012.		Privacy-aware API for TLS", 2012.
	[COMP-ISSUES2]		[COMP-ISSUES2]
	Kelsey, J., "Compression and information leakage of		Kelsey, J., "Compression and information leakage of
	plaintex", International Workshop on Fast Software		plaintex", International Workshop on Fast Software
	Encryption , 2002.		Encryption , 2002.
	[I-D.ietf-tls-dtls13]		[I-D.ietf-tls-dtls13]
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", draft-ietf-tls-dtls13-28 (work in progress), July		1.3", draft-ietf-tls-dtls13-37 (work in progress), March
	2018.		2020.
	[OPENCONNECT-CLIENT]		[OPENCONNECT-CLIENT]
	Woodhouse, D., "http://www.infradead.org/openconnect/",		Woodhouse, D., "http://www.infradead.org/openconnect/",
	2016.		2016.
	[OPENCONNECT-SERVER]		[OPENCONNECT-SERVER]
	Mavrogiannopoulos, N., "http://www.infradead.org/ocserv/",		Mavrogiannopoulos, N., "http://www.infradead.org/ocserv/",
	2016.		2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 21, line 7 ¶		skipping to change at page 19, line 7 ¶
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <https://www.rfc-editor.org/info/rfc7301>.		July 2014, <https://www.rfc-editor.org/info/rfc7301>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	Appendix A. Name for Application-Layer Protocol Negotiation		Appendix A. Name for Application-Layer Protocol Negotiation
	Protocol: openconnect-vpn/1.1		Protocol: openconnect-vpn/1.2
	Identification Sequence:		Identification Sequence:
	0x6f 0x70 0x65 0x6e 0x63 0x6f 0x6e 0x6e 0x65 0x63		0x6f 0x70 0x65 0x6e 0x63 0x6f 0x6e 0x6e 0x65 0x63
	0x74 0x2d 0x76 0x70 0x6e 0x2f 0x31 0x2e 0x31		0x74 0x2d 0x76 0x70 0x6e 0x2f 0x31 0x2e 0x32
	Appendix B. Compression		Appendix B. Compression
	The available compression algorithms for the CSTP and DTLS channels		The available compression algorithms for the CSTP and DTLS channels
	are shown in Table 4. Note, that all algorithms are intentionally		are shown in Table 3. Note, that all algorithms are intentionally
	stateless to prevent the influence of independent packets (e.g., from		stateless to prevent the influence of independent packets (e.g., from
	different sources) on each others compression. That does not		different sources) on each others compression. That does not
	eliminate all known attacks on compression before encryption, and for		eliminate all known attacks on compression before encryption, and for
	that reason an implentation MUST NOT enable compression by default.		that reason an implentation MUST NOT enable compression by default.
	After compression is negotiated each side may choose to compress the		After compression is negotiated each side may choose to compress the
	payload and use the 'COMPRESSED DATA' header from Table 3, or may		payload and use the 'COMPRESSED DATA' header from Table 2, or may
	send uncompressed data with the 'DATA' payload. Each side MUST be		send uncompressed data with the 'DATA' payload. Each side MUST be
	able to process both payloads.		able to process both payloads.
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	| Algorithm | Description |		| Algorithm | Description |
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	| oc-lz4 | The stateless LZ4 compression algorithm. |		| oc-lz4 | The stateless LZ4 compression algorithm. |
	| | |		| | |
	| lzs | The stateless LZS (stacker) compression |		| lzs | The stateless LZS (stacker) compression |
	| | algorithm. |		| | algorithm. |
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	Table 4		Table 3
	Appendix C. DTD declarations		Appendix C. DTD declarations
	C.1. config-auth.dtd		C.1. config-auth.dtd
	<!ELEMENT config-auth (version*,auth*)>		<!ELEMENT config-auth (version*,auth*)>
	<!ATTLIST config-auth client CDATA #FIXED "vpn">		<!ATTLIST config-auth client CDATA #FIXED "vpn">
	<!ATTLIST config-auth type (init|auth-reply|auth-request|complete) "init">		<!ATTLIST config-auth type (init|auth-reply|auth-request|complete) "init">
	<!ELEMENT version (#PCDATA)>		<!ELEMENT version (#PCDATA)>
	<!ATTLIST version who (sg|vpn) "sg">		<!ATTLIST version who (sg|vpn) "sg">
	<!ELEMENT auth (title*,username*,password*,message*,form*)>		<!ELEMENT auth (title*,username*,password*,message*,form*)>
End of changes. 39 change blocks.
	179 lines changed or deleted		88 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/