@@ -473,6 +473,10 @@ fast hardware. SSL/TLS authentication must be used in this mode.
- bit 1: The peer supports peer-id floating mechanism
- bit 2: The client expects a push-reply and the server may
send this reply without waiting for a push-request first.
+ - bit 3: The client is capable of doing key derivation using
+ RFC5705 key material exporter.
+ - bit 4: The client is capable of accepting additional arguments
+ to the `AUTH_PENDING` message.
:code:`IV_NCP=2`
Negotiable ciphers, client supports ``--cipher`` pushed by
@@ -600,14 +600,30 @@ to signal a pending authenticating to the client. A pending auth means
that the connecting requires extra authentication like a one time
password or doing a single sign one via web.
- client-pending-auth {CID} {EXTRA}
-
-The server will send AUTH_PENDING and INFO_PRE,{EXTRA} to the client.
-The client is expected to inform the user that authentication is pending and
-display the extra information. For the format of EXTRA see below
-For the OpenVPN server this is stateless operation and needs to be
-followed by a client-deny/client-auth[-nt] command (that is the result of the
-out of band authentication).
+ client-pending-auth {CID} {EXTRA} {TIMEOUT}
+
+The server will send AUTH_PENDING and INFO_PRE,{EXTRA} to the client. If the
+client supports accepting keywords to AUTH_PENDING (announced via IV_PROTO),
+TIMEOUT parameter will be also be announced to the client to allow it to modify
+its own timeout. The client is expected to inform the user that authentication
+is pending and display the extra information and also show the user the
+remaining time to complete the auth if applicable.
+
+Receiving a AUTH_PENDING message will make the client change its timeout the
+timeout proposed by the server, even if the timeout is shorter.
+If the client does not receive a packet from the server for hand-window the
+connection times out regardless of the timeout. This ensures that the connection
+still times out relatively quickly in case of network problems. The client will
+continously send PULL_REQUEST messages to the server until the timeout is reached.
+This message also triggers an ACK message from the server that resets the
+hand-window based timeout.
+
+Both client and server limit the maximum timeout to the smaller value of half the
+--tls-reneg minimum time and --hand-window time (defaults to 60s).
+
+For the format of EXTRA see below. For the OpenVPN server this is a stateless
+operation and needs to be followed by a client-deny/client-auth[-nt] command
+(that is the result of the out of band authentication).
Before issuing a client-pending-auth to a client instead of a
client-auth/client-deny, the server should check the IV_SSO
@@ -620,7 +636,7 @@ set
setenv IV_SSO openurl,crtext
The variable name IV_SSO is historic as AUTH_PENDING was first used
-to signal single sign on support. To keep compatiblity with existing
+to signal single sign on support. To keep compatibility with existing
implementations the name IV_SSO is kept in lieu of a better name.
openurl
@@ -636,6 +652,11 @@ The space in a control message is limited, so this url should be kept
short to avoid issues. If a loger url is required a URL that redirects
to the longer URL should be sent instead.
+A complete documentation how URLs should be handled on the client is available
+in the openvpn3 repository:
+
+https://github.com/OpenVPN/openvpn3/blob/master/doc/webauth.md
+
url_proxy
========
To avoid issues with OpenVPN connection persist-tun and not able
@@ -233,6 +233,10 @@ check_incoming_control_channel(struct context *c)
{
receive_cr_response(c, &buf);
}
+ else if (buf_string_match_head_str(&buf, "AUTH_PENDING"))
+ {
+ receive_auth_pending(c, &buf);
+ }
else
{
msg(D_PUSH_ERRORS, "WARNING: Received unknown control message: %s", BSTR(&buf));
@@ -292,7 +296,12 @@ check_connection_established(struct context *c)
}
#endif
/* fire up push request right away (already 1s delayed) */
- c->c2.push_request_timeout = now + c->options.handshake_window;
+ /* We might receive a AUTH_PENDING request before we armed this
+ * timer. In that case we don't change the value */
+ if (c->c2.push_request_timeout < now)
+ {
+ c->c2.push_request_timeout = now + c->options.handshake_window;
+ }
event_timeout_init(&c->c2.push_request_interval, 0, now);
reset_coarse_timers(c);
}
@@ -39,6 +39,31 @@
/*
* min/max functions
*/
+static inline unsigned int
+max_uint(unsigned int x, unsigned int y)
+{
+ if (x > y)
+ {
+ return x;
+ }
+ else
+ {
+ return y;
+ }
+}
+
+static inline unsigned int
+min_uint(unsigned int x, unsigned int y)
+{
+ if (x < y)
+ {
+ return x;
+ }
+ else
+ {
+ return y;
+ }
+}
static inline int
max_int(int x, int y)
@@ -231,6 +231,66 @@ receive_cr_response(struct context *c, const struct buffer *buffer)
msg(D_PUSH, "CR response was sent by client ('%s')", m);
}
+/**
+ * Parse the keyword for the AUTH_PENDING request
+ * @param buffer buffer containing the keywords, the buffer's
+ * content will be modified by this function
+ * @param server_timeout timeout pushed by the server or unchanged
+ * if the server does not push a timeout
+ */
+static void
+parse_auth_pending_keywords(const struct buffer *buffer,
+ unsigned int *server_timeout)
+{
+ struct buffer buf = *buffer;
+
+ /* does the buffer start with "AUTH_PENDING," ? */
+ if (!buf_advance(&buf, strlen("AUTH_PENDING"))
+ || !(buf_read_u8(&buf) == ',') || !BLEN(&buf))
+ {
+ return;
+ }
+
+ /* parse the keywords in the same way that push options are parsed */
+ char line[OPTION_LINE_SIZE];
+
+ while (buf_parse(&buf, ',', line, sizeof(line)))
+ {
+ if (sscanf(line, "timeout %u", server_timeout) == 1)
+ {
+ ;
+ }
+ else
+ {
+ msg(D_PUSH, "ignoring AUTH_PENDING parameter: %s", line);
+ }
+ }
+}
+
+void
+receive_auth_pending(struct context *c, const struct buffer *buffer)
+{
+ if (!c->options.pull)
+ return;
+
+ /* Cap the increase at the maximum time we are willing stay in the
+ * pending authentication state */
+ unsigned int max_timeout = max_uint(c->options.renegotiate_seconds/2,
+ c->options.handshake_window);
+
+ /* try to parse parameter keywords, default to hand-winow timeout if the
+ * server does not supply a timeout */
+ unsigned int server_timeout = c->options.handshake_window;
+ parse_auth_pending_keywords(buffer, &server_timeout);
+
+ msg(D_PUSH, "AUTH_PENDING received, extending handshake timeout from %us "
+ "to %us", c->options.handshake_window,
+ min_uint(max_timeout, server_timeout));
+
+ struct key_state *ks = &c->c2.tls_multi->session[TM_ACTIVE].key[KS_PRIMARY];
+ c->c2.push_request_timeout = ks->established + min_uint(max_timeout, server_timeout);
+}
+
/**
* Add an option to the given push list by providing a format string.
*
@@ -372,7 +432,17 @@ send_push_request(struct context *c)
struct tls_session *session = &c->c2.tls_multi->session[TM_ACTIVE];
struct key_state *ks = &session->key[KS_PRIMARY];
- if (c->c2.push_request_timeout > now)
+ /* We timeout here under two conditions:
+ * a) we reached the hard limit of push_request_timeout
+ * b) we have not seen anything from the server in hand_window time
+ *
+ * for non auth-pending scenario, push_request_timeout is the same as
+ * hand_window timeout. For b) every PUSH_REQUEST is a acknowledged by
+ * the server by a P_ACK_V1 packet that reset the keepalive timer
+ */
+
+ if (c->c2.push_request_timeout > now
+ && (now - ks->peer_last_packet) < c->options.handshake_window)
{
return send_control_channel_string(c, "PUSH_REQUEST", D_PUSH);
}
@@ -89,5 +89,14 @@ void send_restart(struct context *c, const char *kill_msg);
*/
void send_push_reply_auth_token(struct tls_multi *multi);
+/**
+ * Parses an AUTH_PENDING message and if in pull mode extends the timeout
+ *
+ * @param c The context struct
+ * @param buffer Buffer containing the control message with AUTH_PENDING
+ */
+void
+receive_auth_pending(struct context *c, const struct buffer *buffer);
+
#endif /* if P2MP */
#endif /* ifndef PUSH_H */
@@ -2218,6 +2218,7 @@ push_peer_info(struct buffer *buf, struct tls_session *session)
if(session->opt->pull)
{
iv_proto |= IV_PROTO_REQUEST_PUSH;
+ iv_proto |= IV_PROTO_AUTH_PENDING_KW;
}
buf_printf(&out, "IV_PROTO=%d\n", iv_proto);
@@ -3669,6 +3670,8 @@ tls_pre_decrypt(struct tls_multi *multi,
}
}
}
+ /* Remember that we received a valid control channel packet */
+ ks->peer_last_packet = now;
done:
buf->len = 0;
@@ -117,6 +117,9 @@
#define IV_PROTO_REQUEST_PUSH (1<<2)
+/** Supports signaling keywords with AUTH_PENDING, e.g. timeout=xy */
+#define IV_PROTO_AUTH_PENDING_KW (1<<4)
+
/* Default field in X509 to be username */
#define X509_USERNAME_FIELD_DEFAULT "CN"
@@ -178,6 +178,7 @@ struct key_state
time_t established; /* when our state went S_ACTIVE */
time_t must_negotiate; /* key negotiation times out if not finished before this time */
time_t must_die; /* this object is destroyed at this time */
+ time_t peer_last_packet; /* Last time we received a paket in this control session */
int initial_opcode; /* our initial P_ opcode */
struct session_id session_id_remote; /* peer's random session ID */
This allows a client to extend the timeout of pull-request response while waiting for the user to complete a pending authentication. A timeout of 60s for a normal authentication might still works for a simple 2FA (but still challenging). With a sophisticated (or overly complicated) web based authentication 60s are quite short. To avoid not detecting network problem in this phase, we use the constant sending of PUSH_REQUEST/AUTH_PENDING as keepalive signal and still timeout the session after the handshake window time. Signed-off-by: Arne Schwabe <arne@rfc2549.org> --- doc/man-sections/server-options.rst | 4 ++ doc/management-notes.txt | 39 ++++++++++++---- src/openvpn/forward.c | 11 ++++- src/openvpn/integer.h | 25 ++++++++++ src/openvpn/push.c | 72 ++++++++++++++++++++++++++++- src/openvpn/push.h | 9 ++++ src/openvpn/ssl.c | 3 ++ src/openvpn/ssl.h | 3 ++ src/openvpn/ssl_common.h | 1 + 9 files changed, 156 insertions(+), 11 deletions(-)