New upstream version 3.14

17 files changed, 161 insertions, 122 deletions

diff --git a/docs/api/remctl.3 b/docs/api/remctl.3
index e1875fa..7bb5e76 100644
--- a/docs/api/remctl.3
+++ b/docs/api/remctl.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL 3"
-.TH REMCTL 3 "2016-10-11" "3.13" "remctl Library Reference"
+.TH REMCTL 3 "2018-04-01" "3.14" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -157,8 +157,8 @@ result as a remctl_result struct.
 port to connect to; if 0, the library first attempts to connect to the
 registered port of 4373 and then tries the legacy port of 4444 if that
 fails.  Future versions of the library will drop this fallback to 4444.
-\&\fIprincipal\fR is the service principal to use for authentication; if \s-1NULL,
-\&\s0\f(CW\*(C`host/\f(CIhost\f(CW\*(C'\fR is used, with the realm determined by domain-realm
+\&\fIprincipal\fR is the service principal to use for authentication; if \s-1NULL,\s0
+\&\f(CW\*(C`host/\f(CIhost\f(CW\*(C'\fR is used, with the realm determined by domain-realm
 mapping.  \fIcommand\fR is the command to run as a NULL-terminated array of
 NUL-terminated strings.
 .PP
diff --git a/docs/api/remctl_close.3 b/docs/api/remctl_close.3
index 8719fbf..46cf0e0 100644
--- a/docs/api/remctl_close.3
+++ b/docs/api/remctl_close.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_CLOSE 3"
-.TH REMCTL_CLOSE 3 "2016-10-11" "3.13" "remctl Library Reference"
+.TH REMCTL_CLOSE 3 "2018-04-01" "3.14" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
diff --git a/docs/api/remctl_command.3 b/docs/api/remctl_command.3
index 55c6e19..ce138d5 100644
--- a/docs/api/remctl_command.3
+++ b/docs/api/remctl_command.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_COMMAND 3"
-.TH REMCTL_COMMAND 3 "2016-10-11" "3.13" "remctl Library Reference"
+.TH REMCTL_COMMAND 3 "2018-04-01" "3.14" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
diff --git a/docs/api/remctl_error.3 b/docs/api/remctl_error.3
index b07ac1a..cf7db75 100644
--- a/docs/api/remctl_error.3
+++ b/docs/api/remctl_error.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_ERROR 3"
-.TH REMCTL_ERROR 3 "2016-10-11" "3.13" "remctl Library Reference"
+.TH REMCTL_ERROR 3 "2018-04-01" "3.14" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
diff --git a/docs/api/remctl_new.3 b/docs/api/remctl_new.3
index 96b8813..4f68caf 100644
--- a/docs/api/remctl_new.3
+++ b/docs/api/remctl_new.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_NEW 3"
-.TH REMCTL_NEW 3 "2016-10-11" "3.13" "remctl Library Reference"
+.TH REMCTL_NEW 3 "2018-04-01" "3.14" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -145,7 +145,7 @@ struct remctl *\fBremctl_new\fR(void);
 .IX Header "DESCRIPTION"
 \&\fIremctl_new()\fR creates a new remctl client.  The resulting remctl struct is
 opaque from the perspective of the caller, but should be the first
-argument to all subsequent calls into the remctl \s-1API. \s0 Normally, the next
+argument to all subsequent calls into the remctl \s-1API.\s0  Normally, the next
 call after \fIremctl_new()\fR would be \fIremctl_open()\fR to connect to a remote
 server.
 .PP
diff --git a/docs/api/remctl_noop.3 b/docs/api/remctl_noop.3
index 216ad26..24184c2 100644
--- a/docs/api/remctl_noop.3
+++ b/docs/api/remctl_noop.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_NOOP 3"
-.TH REMCTL_NOOP 3 "2016-10-11" "3.13" "remctl Library Reference"
+.TH REMCTL_NOOP 3 "2018-04-01" "3.14" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
diff --git a/docs/api/remctl_open.3 b/docs/api/remctl_open.3
index 0474f2d..935fd68 100644
--- a/docs/api/remctl_open.3
+++ b/docs/api/remctl_open.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_OPEN 3"
-.TH REMCTL_OPEN 3 "2016-10-11" "3.13" "remctl Library Reference"
+.TH REMCTL_OPEN 3 "2018-04-01" "3.14" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -159,7 +159,7 @@ int \fBremctl_open_fd\fR(struct remctl *\fIr\fR, const char *\fIhost\fR,
 \&\fIremctl_open()\fR opens a \s-1TCP\s0 connection to the given \fIhost\fR on the given
 \&\fIport\fR and then authenticates using the remctl protocol and the service
 principal \fIprincipal\fR.  \fIr\fR is a remctl struct created via \fIremctl_new()\fR.
-\&\fIhost\fR must not be \s-1NULL. \s0 If \fIport\fR is 0, the library first attempts to
+\&\fIhost\fR must not be \s-1NULL.\s0  If \fIport\fR is 0, the library first attempts to
 connect to the registered port of 4373 and then tries the legacy port of
 4444 if that fails.  Future versions of the library will drop this
 fallback to 4444.  If \fIprincipal\fR is \s-1NULL,\s0 a service principal of
diff --git a/docs/api/remctl_output.3 b/docs/api/remctl_output.3
index a927d1e..491fa8d 100644
--- a/docs/api/remctl_output.3
+++ b/docs/api/remctl_output.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_OUTPUT 3"
-.TH REMCTL_OUTPUT 3 "2016-10-11" "3.13" "remctl Library Reference"
+.TH REMCTL_OUTPUT 3 "2018-04-01" "3.14" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -171,7 +171,7 @@ where the type field will have one of the following values:
 .Ve
 .PP
 A command rejected by the remctl server will return a single output token
-of type \s-1REMCTL_OUT_ERROR.  A\s0 successful command will return zero or more
+of type \s-1REMCTL_OUT_ERROR.\s0  A successful command will return zero or more
 \&\s-1REMCTL_OUT_OUTPUT\s0 tokens representing the output of the command followed
 by a \s-1REMCTL_OUT_STATUS\s0 token giving the exit status of the command.
 Therefore, for each command issued, the caller should call
diff --git a/docs/api/remctl_set_ccache.3 b/docs/api/remctl_set_ccache.3
index cdafbbb..1d0ccf8 100644
--- a/docs/api/remctl_set_ccache.3
+++ b/docs/api/remctl_set_ccache.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_SET_CCACHE 3"
-.TH REMCTL_SET_CCACHE 3 "2016-10-11" "3.13" "remctl Library Reference"
+.TH REMCTL_SET_CCACHE 3 "2018-04-01" "3.14" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
diff --git a/docs/api/remctl_set_source_ip.3 b/docs/api/remctl_set_source_ip.3
index efcf176..cbb8997 100644
--- a/docs/api/remctl_set_source_ip.3
+++ b/docs/api/remctl_set_source_ip.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_SET_SOURCE_IP 3"
-.TH REMCTL_SET_SOURCE_IP 3 "2016-10-11" "3.13" "remctl Library Reference"
+.TH REMCTL_SET_SOURCE_IP 3 "2018-04-01" "3.14" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
diff --git a/docs/api/remctl_set_timeout.3 b/docs/api/remctl_set_timeout.3
index 2fa4920..3a54f5b 100644
--- a/docs/api/remctl_set_timeout.3
+++ b/docs/api/remctl_set_timeout.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL_SET_TIMEOUT 3"
-.TH REMCTL_SET_TIMEOUT 3 "2016-10-11" "3.13" "remctl Library Reference"
+.TH REMCTL_SET_TIMEOUT 3 "2018-04-01" "3.14" "remctl Library Reference"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
diff --git a/docs/protocol.html b/docs/protocol.html
index 8cb8150..8ba60f3 100644
--- a/docs/protocol.html
+++ b/docs/protocol.html
@@ -373,30 +373,30 @@
   /*]]>*/
   </style>
 
-  <link href="#rfc.toc" rel="Contents"/>
-<link href="#rfc.section.1" rel="Chapter" title="1 Basic Packet Format"/>
-<link href="#rfc.section.2" rel="Chapter" title="2 Network Protocol (version 3)"/>
-<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Session Sequence"/>
-<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Message Format"/>
-<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Protocol Version Negotiation"/>
-<link href="#rfc.section.2.4" rel="Chapter" title="2.4 MESSAGE_COMMAND"/>
-<link href="#rfc.section.2.5" rel="Chapter" title="2.5 MESSAGE_OUTPUT and MESSAGE_STATUS"/>
-<link href="#rfc.section.2.6" rel="Chapter" title="2.6 MESSAGE_ERROR"/>
-<link href="#rfc.section.2.7" rel="Chapter" title="2.7 MESSAGE_QUIT"/>
-<link href="#rfc.section.2.8" rel="Chapter" title="2.8 MESSAGE_NOOP"/>
-<link href="#rfc.section.3" rel="Chapter" title="3 Network Protocol (version 1)"/>
-<link href="#rfc.section.4" rel="Chapter" title="4 Security Considerations"/>
-<link href="#rfc.appendix.A" rel="Chapter" title="A Acknowledgements"/>
-<link href="#rfc.appendix.B" rel="Chapter" title="B Additional License"/>
-<link href="#rfc.authors" rel="Chapter"/>
+  <link href="#rfc.toc" rel="Contents">
+<link href="#rfc.section.1" rel="Chapter" title="1 Basic Packet Format">
+<link href="#rfc.section.2" rel="Chapter" title="2 Network Protocol (version 3)">
+<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Session Sequence">
+<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Message Format">
+<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Protocol Version Negotiation">
+<link href="#rfc.section.2.4" rel="Chapter" title="2.4 MESSAGE_COMMAND">
+<link href="#rfc.section.2.5" rel="Chapter" title="2.5 MESSAGE_OUTPUT and MESSAGE_STATUS">
+<link href="#rfc.section.2.6" rel="Chapter" title="2.6 MESSAGE_ERROR">
+<link href="#rfc.section.2.7" rel="Chapter" title="2.7 MESSAGE_QUIT">
+<link href="#rfc.section.2.8" rel="Chapter" title="2.8 MESSAGE_NOOP">
+<link href="#rfc.section.3" rel="Chapter" title="3 Network Protocol (version 1)">
+<link href="#rfc.section.4" rel="Chapter" title="4 Security Considerations">
+<link href="#rfc.appendix.A" rel="Chapter" title="A Acknowledgements">
+<link href="#rfc.appendix.B" rel="Chapter" title="B Additional License">
+<link href="#rfc.authors" rel="Chapter">
 
 
-  <meta name="generator" content="xml2rfc version 2.5.1 - http://tools.ietf.org/tools/xml2rfc" />
+  <meta name="generator" content="xml2rfc version 2.9.6 - https://tools.ietf.org/tools/xml2rfc" />
   <link rel="schema.dct" href="http://purl.org/dc/terms/" />
 
   <meta name="dct.creator" content="Allbery, R." />
   <meta name="dct.identifier" content="urn:ietf:id:draft-allbery-remctl-00" />
-  <meta name="dct.issued" scheme="ISO8601" content="2014-1" />
+  <meta name="dct.issued" scheme="ISO8601" content="2014-01-01" />
   <meta name="dct.abstract" content="This document specifies the remctl wire protocol, used to send commands and arguments to a remote system and receive the results of executing that command.  The protocol uses GSS-API and Kerberos v5 for authentication, confidentiality, and integrity protection.  Both the current (version 3) protocol and the older version 1 protocol are described.  The version 1 protocol should only be implemented for backward compatibility." />
   <meta name="description" content="This document specifies the remctl wire protocol, used to send commands and arguments to a remote system and receive the results of executing that command.  The protocol uses GSS-API and Kerberos v5 for authentication, confidentiality, and integrity protection.  Both the current (version 3) protocol and the older version 1 protocol are described.  The version 1 protocol should only be implemented for backward compatibility." />
 
@@ -408,16 +408,16 @@
     <tbody>
     
     	<tr>
-  <td class="left"></td>
-  <td class="right">R. Allbery</td>
+<td class="left"></td>
+<td class="right">R. Allbery</td>
 </tr>
 <tr>
-  <td class="left"></td>
-  <td class="right">Stanford University</td>
+<td class="left"></td>
+<td class="right">Stanford University</td>
 </tr>
 <tr>
-  <td class="left"></td>
-  <td class="right">January 2014</td>
+<td class="left"></td>
+<td class="right">January 1, 2014</td>
 </tr>
 
     	
@@ -427,11 +427,11 @@
   <p class="title">remctl: Remote Authenticated Command Service<br />
   <span class="filename">draft-allbery-remctl-00</span></p>
   
-  <h1 id="rfc.abstract">
-  <a href="#rfc.abstract">Abstract</a>
-</h1>
+  <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
 <p>This document specifies the remctl wire protocol, used to send commands and arguments to a remote system and receive the results of executing that command.  The protocol uses GSS-API and Kerberos v5 for authentication, confidentiality, and integrity protection.  Both the current (version 3) protocol and the older version 1 protocol are described.  The version 1 protocol should only be implemented for backward compatibility.</p>
-<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> <a href="#format" id="format">Basic Packet Format</a></h1>
+<h1 id="rfc.section.1">
+<a href="#rfc.section.1">1.</a> <a href="#format" id="format">Basic Packet Format</a>
+</h1>
 <p id="rfc.section.1.p.1">The remctl network protocol consists of data packets sent from a client to a server or a server to a client over a TCP connection.  The remctl protocol may be used over any port, but the IANA-registered port and the RECOMMENDED default for the protocol is 4373.  Each data packet has the following format:</p>
 <pre>
     1 octet     flags
@@ -452,21 +452,27 @@
 <p>Only TOKEN_CONTEXT, TOKEN_CONTEXT_NEXT, TOKEN_DATA, and TOKEN_PROTOCOL are used for packets for versions 2 and 3 of the protocol.  The other flags are used only with the legacy version 1 protocol.</p>
 <p id="rfc.section.1.p.3">The length field is a four-octet length in network byte order, specifying the number of octets in the following data payload.</p>
 <p id="rfc.section.1.p.4">The data payload is empty, the results of gss_accept_sec_context, the results of gss_init_sec_context, or a data payload protected with gss_wrap.  The length of the data passed to gss_wrap MUST NOT be larger than 65,536 octets (64KB), even if the underlying Kerberos implementation supports longer input buffers.</p>
-<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#proto3" id="proto3">Network Protocol (version 3)</a></h1>
-<h1 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1.</a> <a href="#packet" id="packet">Session Sequence</a></h1>
+<h1 id="rfc.section.2">
+<a href="#rfc.section.2">2.</a> <a href="#proto3" id="proto3">Network Protocol (version 3)</a>
+</h1>
+<h1 id="rfc.section.2.1">
+<a href="#rfc.section.2.1">2.1.</a> <a href="#packet" id="packet">Session Sequence</a>
+</h1>
 <p id="rfc.section.2.1.p.1">A remctl connection is always initiated by a client opening a TCP connection to a server.  The protocol then proceeds as follows: </p>
 
 <ol>
-  <li>Client sends message with an empty payload and flags TOKEN_NOOP, TOKEN_CONTEXT_NEXT, and TOKEN_PROTOCOL (0x51).  If the client doesn't include TOKEN_PROTOCOL, it is speaking the version 1 protocol, and the server MUST either drop the connection or fall back to the version 1 protocol.  This initial message is useless in a pure version 2 or 3 protocol world and is done only for backward compatibility with the version 1 protocol.</li>
-  <li>Client calls gss_init_sec_context and sends the results as the message body with flags TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  The client MUST pass GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG as requested flags to gss_init_sec_context and SHOULD pass GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG.</li>
-  <li>Server replies with the results of gss_accept_sec_context and flags TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  If the server doesn't include TOKEN_PROTOCOL in the flags, it is speaking the version 1 protocol, and the client MUST either drop the connection or fall back to the version 1 protocol.</li>
-  <li>Client passes data to gss_init_sec_context and replies with the results and TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  The client must pass GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG as requested flags and SHOULD pass GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG.</li>
-  <li>Server and client repeat, passing in the payload from the last packet from the other side, for as long as GSS-API indicates that continuation is required.  If either side drops TOKEN_PROTOCOL from the flags, it is an considered an error and the connect MUST be dropped.  (This could be a down-negotiation attack.)  After the establishment of the security context, both client and server MUST confirm that GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG are set in the resulting security context and MUST immediately close the connection if this is not the case.</li>
-  <li>After the security context has been established, the client and server exchange commands and responses as described below.  All commands are sent with flags TOKEN_DATA and TOKEN_PROTOCOL (0x44) and the data payload of all packets is protected with gss_wrap.  The conf_req_flag parameter of gss_wrap MUST be set to non-zero, requesting both confidentiality and integrity services.</li>
+<li>Client sends message with an empty payload and flags TOKEN_NOOP, TOKEN_CONTEXT_NEXT, and TOKEN_PROTOCOL (0x51).  If the client doesn't include TOKEN_PROTOCOL, it is speaking the version 1 protocol, and the server MUST either drop the connection or fall back to the version 1 protocol.  This initial message is useless in a pure version 2 or 3 protocol world and is done only for backward compatibility with the version 1 protocol.</li>
+<li>Client calls gss_init_sec_context and sends the results as the message body with flags TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  The client MUST pass GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG as requested flags to gss_init_sec_context and SHOULD pass GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG.</li>
+<li>Server replies with the results of gss_accept_sec_context and flags TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  If the server doesn't include TOKEN_PROTOCOL in the flags, it is speaking the version 1 protocol, and the client MUST either drop the connection or fall back to the version 1 protocol.</li>
+<li>Client passes data to gss_init_sec_context and replies with the results and TOKEN_CONTEXT and TOKEN_PROTOCOL (0x42).  The client must pass GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG as requested flags and SHOULD pass GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG.</li>
+<li>Server and client repeat, passing in the payload from the last packet from the other side, for as long as GSS-API indicates that continuation is required.  If either side drops TOKEN_PROTOCOL from the flags, it is an considered an error and the connect MUST be dropped.  (This could be a down-negotiation attack.)  After the establishment of the security context, both client and server MUST confirm that GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG are set in the resulting security context and MUST immediately close the connection if this is not the case.</li>
+<li>After the security context has been established, the client and server exchange commands and responses as described below.  All commands are sent with flags TOKEN_DATA and TOKEN_PROTOCOL (0x44) and the data payload of all packets is protected with gss_wrap.  The conf_req_flag parameter of gss_wrap MUST be set to non-zero, requesting both confidentiality and integrity services.</li>
 </ol>
 
 <p> </p>
-<h1 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2.</a> <a href="#messages" id="messages">Message Format</a></h1>
+<h1 id="rfc.section.2.2">
+<a href="#rfc.section.2.2">2.2.</a> <a href="#messages" id="messages">Message Format</a>
+</h1>
 <p id="rfc.section.2.2.p.1">All client and server messages will use the following format inside the data payload.  This is the format of the message before passing it to gss_wrap for confidentiality and integrity protection.</p>
 <pre>
     1 octet     protocol version
@@ -486,14 +492,18 @@
           </pre>
 <p id="rfc.section.2.2.p.3">The first two message types are client messages and MUST NOT be sent by the server.  The remaining message types except for MESSAGE_NOOP are server messages and MUST NOT by sent by the client.</p>
 <p id="rfc.section.2.2.p.4">All of these message types were introduced in protocol version 2 except for MESSAGE_NOOP, which is a protocol version 3 message.</p>
-<h1 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3.</a> <a href="#negotiation" id="negotiation">Protocol Version Negotiation</a></h1>
+<h1 id="rfc.section.2.3">
+<a href="#rfc.section.2.3">2.3.</a> <a href="#negotiation" id="negotiation">Protocol Version Negotiation</a>
+</h1>
 <p id="rfc.section.2.3.p.1">If the server ever receives a message from a client that claims a protocol version higher than the server supports, the server MUST otherwise ignore the contents of the message and SHOULD respond with a message type of MESSAGE_VERSION and the following message payload:</p>
 <pre>
     1 octet     highest supported version
           </pre>
 <p id="rfc.section.2.3.p.2">The client MUST then either send only messages supported at that protocol version or lower or send MESSAGE_QUIT and close the connection.</p>
 <p id="rfc.section.2.3.p.3">Currently, there are only two meaningful values for the highest supported version: 3, which indicates everything in this specification is supported, or 2, which indicates that everything except MESSAGE_NOOP is supported.</p>
-<h1 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4.</a> <a href="#command" id="command">MESSAGE_COMMAND</a></h1>
+<h1 id="rfc.section.2.4">
+<a href="#rfc.section.2.4">2.4.</a> <a href="#command" id="command">MESSAGE_COMMAND</a>
+</h1>
 <p id="rfc.section.2.4.p.1">Most client messages will be of type MESSAGE_COMMAND, which has the following format:</p>
 <pre>
     1 octet     keep-alive flag
@@ -511,7 +521,9 @@
 <p id="rfc.section.2.4.p.7">If a client sends an invalid sequence of MESSAGE_COMMAND messages that violate the continuation rules described above, the server SHOULD reply with a MESSAGE_ERROR message, generally with one of the ERROR_BAD_TOKEN, ERROR_UNKNOWN_MESSAGE, ERROR_BAD_COMMAND, or ERROR_UNEXPECTED_MESSAGE error codes.  It MUST discard the partial command without acting on it.  The client cannot correct an error in a continued MESSAGE_COMMAND stream by resending the previous part.  It MUST start again at the beginning with a MESSAGE_COMMAND with a continue status of 0 or 1.</p>
 <p id="rfc.section.2.4.p.8">Number of arguments is a four-octet number in network byte order that gives the total number of command arguments.  For each argument, there is then a length and argument data pair, where the length is a four-octet number in network byte order indicating the number of octets of data in the following argument.  Argument length may be 0.  Commands with no arguments are permitted by the protocol.</p>
 <p id="rfc.section.2.4.p.9">Servers may impose limits on the number of arguments and the size of argument data to limit resource usage.  If the client message exceeds one of those limits, the server MUST respond with MESSAGE_ERROR with an error code of ERROR_TOOMANY_ARGS or ERROR_TOOMUCH_DATA as appropriate.</p>
-<h1 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5.</a> <a href="#output" id="output">MESSAGE_OUTPUT and MESSAGE_STATUS</a></h1>
+<h1 id="rfc.section.2.5">
+<a href="#rfc.section.2.5">2.5.</a> <a href="#output" id="output">MESSAGE_OUTPUT and MESSAGE_STATUS</a>
+</h1>
 <p id="rfc.section.2.5.p.1">The server response to MESSAGE_COMMAND is zero or more MESSAGE_OUTPUT messages followed by either a MESSAGE_STATUS or a MESSAGE_ERROR response.  Each MESSAGE_OUTPUT message has the following format:</p>
 <pre>
     1 octet     output stream
@@ -525,7 +537,9 @@
           </pre>
 <p id="rfc.section.2.5.p.4">MESSAGE_STATUS indicates the command has finished and returns the final exit stauts of the command.  Exit status is 0 for success and non-zero for failure, where the meaning of non-zero exit statuses is left to the application to define.  (This is identical to a Unix command exit status.)</p>
 <p id="rfc.section.2.5.p.5">Unless the MESSAGE_COMMAND message from the client had the keep-alive flag set to 1, the server MUST close the network connection immediately after sending the MESSAGE_STATUS response message.</p>
-<h1 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6.</a> <a href="#error" id="error">MESSAGE_ERROR</a></h1>
+<h1 id="rfc.section.2.6">
+<a href="#rfc.section.2.6">2.6.</a> <a href="#error" id="error">MESSAGE_ERROR</a>
+</h1>
 <p id="rfc.section.2.6.p.1">At any point before sending MESSAGE_STATUS, the server may respond with MESSAGE_ERROR if some error occurred.  This can be the first response after a MESSAGE_COMMAND, or it may be sent after one or more MESSAGE_OUTPUT messages.  The format of MESSAGE_ERROR is as follows:</p>
 <pre>
     4 octets    error code
@@ -547,43 +561,53 @@
 <p id="rfc.section.2.6.p.3">Additional error codes may be added without changing the version of the remctl protocol, so clients MUST accept error codes other than the ones above.</p>
 <p id="rfc.section.2.6.p.4">The message length is a four-octet number in network byte order that specifies the length in octets of the following error message.  The error message is a free-form informational message intended for human consumption and MUST NOT be interpreted by an automated process.  Software should instead use the error code.</p>
 <p id="rfc.section.2.6.p.5">Unless the MESSAGE_COMMAND message from the client had the keep-alive flag set to 1, the server MUST close the network connection immediately after sending the MESSAGE_ERROR response message.  Otherwise, the server SHOULD still honor that flag, although the server MAY terminate the connection after an unreasonable number of errors.</p>
-<h1 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7.</a> <a href="#quit" id="quit">MESSAGE_QUIT</a></h1>
+<h1 id="rfc.section.2.7">
+<a href="#rfc.section.2.7">2.7.</a> <a href="#quit" id="quit">MESSAGE_QUIT</a>
+</h1>
 <p id="rfc.section.2.7.p.1">MESSAGE_QUIT is a way of terminating the connection cleanly if the client asked for keep-alive and then decided not to use it.  There is no message body.  Upon receiving this message, the server MUST immediately close the connection.</p>
-<h1 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8.</a> <a href="#noop" id="noop">MESSAGE_NOOP</a></h1>
+<h1 id="rfc.section.2.8">
+<a href="#rfc.section.2.8">2.8.</a> <a href="#noop" id="noop">MESSAGE_NOOP</a>
+</h1>
 <p id="rfc.section.2.8.p.1">MESSAGE_NOOP provides a way for a client to keep the connection open to a remctl server, including through firewall session timeouts and similar network constraints that require periodic activity, without sending new commands.  There is no body.  When the client sends a MESSAGE_NOOP message, the server replies with a MESSAGE_NOOP message.</p>
 <p id="rfc.section.2.8.p.2">Note that MESSAGE_NOOP was introduced in protocol version 3 and therefore should be marked accordingly.  Clients should be prepared for older servers to reply with MESSAGE_VERSION instead of MESSAGE_NOOP.</p>
-<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#proto1" id="proto1">Network Protocol (version 1)</a></h1>
+<h1 id="rfc.section.3">
+<a href="#rfc.section.3">3.</a> <a href="#proto1" id="proto1">Network Protocol (version 1)</a>
+</h1>
 <p id="rfc.section.3.p.1">The old network protocol supported only 64KB of data payload, only a single command and response, and had some additional unnecessary protocol components.  It SHOULD NOT be used by clients, but MAY be supported by servers for backward compatibility.  It is recognized by the server and client by the lack of TOKEN_PROTOCOL in the flags of the initial security context negotiation.</p>
 <p id="rfc.section.3.p.2">The old protocol always uses the following steps: </p>
 
 <ol>
-  <li>Client opens TCP connection to server.</li>
-  <li>Client sends message with flags TOKEN_NOOP and TOKEN_CONTEXT_NEXT and an empty payload.</li>
-  <li>Client calls gss_init_sec_context and sends message with the results and flags TOKEN_CONTEXT.  The client MUST pass GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG as requested flags and SHOULD pass GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG, although the version one protocol does not check the results of this negotiation.</li>
-  <li>Server replies with the results of gss_accept_sec_context and flags TOKEN_CONTEXT.</li>
-  <li>Client calls gss_init_sec_context again with the data from the server and replies with the results and flags TOKEN_CONTEXT, using the same requested flags as described above.</li>
-  <li>Server and client repeat, passing in the payload from the last packet from the other side, for as long as GSS-API indicates that continuation is required.  Each of these packets have only TOKEN_CONTEXT set in the flags.</li>
-  <li>Client sends command with flags TOKEN_DATA and TOKEN_SEND_MIC and the following payload format:  four-octet number of arguments, and then for each argument, a four-octet length and then the argument value.  All numbers are in network type order.  The payload MUST be protected with gss_wrap and the conf_req_flag parameter of gss_wrap MUST be set to non-zero, requesting both confidentiality and integrity services.</li>
-  <li>Server accepts and decrypts data, generates a MIC with gss_get_mic, and sends the MIC back to the client with flags TOKEN_MIC.  This is the only packet that isn't encrypted with gss_wrap.  Client receives and then SHOULD verify this MIC.</li>
-  <li>Server runs the command, collects the output, and sends the output back with flags TOKEN_DATA and the following payload format:  four-octet exit status, four-octet data length, data.  All numbers are in network byte order.  The exit status is 0 if there were no errors and non-zero otherwise, where the meaning of non-zero values are defined by the application.  The payload MUST be protected with gss_wrap with a conf_req_flag set to non-zero.</li>
-  <li>Server and client close connection.</li>
+<li>Client opens TCP connection to server.</li>
+<li>Client sends message with flags TOKEN_NOOP and TOKEN_CONTEXT_NEXT and an empty payload.</li>
+<li>Client calls gss_init_sec_context and sends message with the results and flags TOKEN_CONTEXT.  The client MUST pass GSS_C_MUTUAL_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG as requested flags and SHOULD pass GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG, although the version one protocol does not check the results of this negotiation.</li>
+<li>Server replies with the results of gss_accept_sec_context and flags TOKEN_CONTEXT.</li>
+<li>Client calls gss_init_sec_context again with the data from the server and replies with the results and flags TOKEN_CONTEXT, using the same requested flags as described above.</li>
+<li>Server and client repeat, passing in the payload from the last packet from the other side, for as long as GSS-API indicates that continuation is required.  Each of these packets have only TOKEN_CONTEXT set in the flags.</li>
+<li>Client sends command with flags TOKEN_DATA and TOKEN_SEND_MIC and the following payload format:  four-octet number of arguments, and then for each argument, a four-octet length and then the argument value.  All numbers are in network type order.  The payload MUST be protected with gss_wrap and the conf_req_flag parameter of gss_wrap MUST be set to non-zero, requesting both confidentiality and integrity services.</li>
+<li>Server accepts and decrypts data, generates a MIC with gss_get_mic, and sends the MIC back to the client with flags TOKEN_MIC.  This is the only packet that isn't encrypted with gss_wrap.  Client receives and then SHOULD verify this MIC.</li>
+<li>Server runs the command, collects the output, and sends the output back with flags TOKEN_DATA and the following payload format:  four-octet exit status, four-octet data length, data.  All numbers are in network byte order.  The exit status is 0 if there were no errors and non-zero otherwise, where the meaning of non-zero values are defined by the application.  The payload MUST be protected with gss_wrap with a conf_req_flag set to non-zero.</li>
+<li>Server and client close connection.</li>
 </ol>
 
 <p> </p>
-<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#security" id="security">Security Considerations</a></h1>
+<h1 id="rfc.section.4">
+<a href="#rfc.section.4">4.</a> <a href="#security" id="security">Security Considerations</a>
+</h1>
 <p id="rfc.section.4.p.1">It would be preferrable to insist on replay and sequence protection (GSS_C_REPLAY_FLAG and GSS_C_SEQUENCE_FLAG) for all contexts, but some older Kerberos GSS-API implementations don't support this and hence it is not mandatory in the protocol.  Clients SHOULD always request replay and sequence protection, however, and servers MAY require such protection be negotiated.</p>
 <p id="rfc.section.4.p.2">The old protocol doesn't provide integrity protection for the flags, but since it always follows the same fixed sequence of operations, this should pose no security concerns in practice.  The new protocol only uses the flag field outside of the encrypted section of the packet for initial negotiation and closes the connection if the flags aren't what was expected (avoiding a down-negotiation attack).</p>
 <p id="rfc.section.4.p.3">In the old protocol, the server calculated and sent a MIC back to the client, which then verified that the command as received by the server was correct.  Not only does GSS-API already provide integrity protection, but this verification also happens after the server has already started running the command.  It has been dropped in the new protocol.</p>
 <p id="rfc.section.4.p.4">The old protocol doesn't require the client and server check the results of the GSS-API flag negotiation, although all old protocol clients passed GSS_C_MUTUAL_FLAG.  However, the old protocol requires gss_wrap be used for all payload with conf_req_flag set to non-zero, so any context that didn't negotiate confidentiality and integrity services would fail later.</p>
-<h1 id="rfc.appendix.A"><a href="#rfc.appendix.A">Appendix A.</a> <a href="#credits" id="credits">Acknowledgements</a></h1>
+<h1 id="rfc.appendix.A">
+<a href="#rfc.appendix.A">Appendix A.</a> <a href="#credits" id="credits">Acknowledgements</a>
+</h1>
 <p id="rfc.section.A.p.1">The original remctl protocol design was done by Anton Ushakov, with input from Russ Allbery and Roland Schemers.  Thank you to David Hoffman and Mike Newton for their review of the version 2 remctl protocol.</p>
-<h1 id="rfc.appendix.B"><a href="#rfc.appendix.B">Appendix B.</a> <a href="#license" id="license">Additional License</a></h1>
+<h1 id="rfc.appendix.B">
+<a href="#rfc.appendix.B">Appendix B.</a> <a href="#license" id="license">Additional License</a>
+</h1>
 <p id="rfc.section.B.p.1">This section supplements the Copyright Notice section at the start of this document.  It states an additional copyright notice and grants a much less restrictive license than the default IETF Trust license.  You may copy and distribute this document, with or without modification, under your choice of the license specified in the Copyright Notice section or the license below.</p>
 <p id="rfc.section.B.p.2">Copyright 2006, 2007, 2008, 2009, 2011, 2013, 2014 The Board of Trustees of the Leland Stanford Junior University</p>
 <p id="rfc.section.B.p.3">Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved.  This file is offered as-is, without any warranty.</p>
-<h1 id="rfc.authors">
-  <a href="#rfc.authors">Author's Address</a>
-</h1>
+<h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
 <div class="avoidbreak">
   <address class="vcard">
 	<span class="vcardline">
@@ -614,21 +638,36 @@
   <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
   <ul class="toc">
 
-  	<li>1.   <a href="#rfc.section.1">Basic Packet Format</a></li>
-<li>2.   <a href="#rfc.section.2">Network Protocol (version 3)</a></li>
-<ul><li>2.1.   <a href="#rfc.section.2.1">Session Sequence</a></li>
-<li>2.2.   <a href="#rfc.section.2.2">Message Format</a></li>
-<li>2.3.   <a href="#rfc.section.2.3">Protocol Version Negotiation</a></li>
-<li>2.4.   <a href="#rfc.section.2.4">MESSAGE_COMMAND</a></li>
-<li>2.5.   <a href="#rfc.section.2.5">MESSAGE_OUTPUT and MESSAGE_STATUS</a></li>
-<li>2.6.   <a href="#rfc.section.2.6">MESSAGE_ERROR</a></li>
-<li>2.7.   <a href="#rfc.section.2.7">MESSAGE_QUIT</a></li>
-<li>2.8.   <a href="#rfc.section.2.8">MESSAGE_NOOP</a></li>
-</ul><li>3.   <a href="#rfc.section.3">Network Protocol (version 1)</a></li>
-<li>4.   <a href="#rfc.section.4">Security Considerations</a></li>
-<li>Appendix A.   <a href="#rfc.appendix.A">Acknowledgements</a></li>
-<li>Appendix B.   <a href="#rfc.appendix.B">Additional License</a></li>
-<li><a href="#rfc.authors">Author's Address</a></li>
+  	<li>1.   <a href="#rfc.section.1">Basic Packet Format</a>
+</li>
+<li>2.   <a href="#rfc.section.2">Network Protocol (version 3)</a>
+</li>
+<ul><li>2.1.   <a href="#rfc.section.2.1">Session Sequence</a>
+</li>
+<li>2.2.   <a href="#rfc.section.2.2">Message Format</a>
+</li>
+<li>2.3.   <a href="#rfc.section.2.3">Protocol Version Negotiation</a>
+</li>
+<li>2.4.   <a href="#rfc.section.2.4">MESSAGE_COMMAND</a>
+</li>
+<li>2.5.   <a href="#rfc.section.2.5">MESSAGE_OUTPUT and MESSAGE_STATUS</a>
+</li>
+<li>2.6.   <a href="#rfc.section.2.6">MESSAGE_ERROR</a>
+</li>
+<li>2.7.   <a href="#rfc.section.2.7">MESSAGE_QUIT</a>
+</li>
+<li>2.8.   <a href="#rfc.section.2.8">MESSAGE_NOOP</a>
+</li>
+</ul><li>3.   <a href="#rfc.section.3">Network Protocol (version 1)</a>
+</li>
+<li>4.   <a href="#rfc.section.4">Security Considerations</a>
+</li>
+<li>Appendix A.   <a href="#rfc.appendix.A">Acknowledgements</a>
+</li>
+<li>Appendix B.   <a href="#rfc.appendix.B">Additional License</a>
+</li>
+<li><a href="#rfc.authors">Author's Address</a>
+</li>
 
 
   </ul>
diff --git a/docs/protocol.txt b/docs/protocol.txt
index 71ed430..034b9e6 100644
--- a/docs/protocol.txt
+++ b/docs/protocol.txt
@@ -4,7 +4,7 @@
 
                                                               R. Allbery
                                                      Stanford University
-                                                            January 2014
+                                                         January 1, 2014
 
 
               remctl: Remote Authenticated Command Service
diff --git a/docs/remctl-shell.8.in b/docs/remctl-shell.8.in
index 46523f8..9bb1f73 100644
--- a/docs/remctl-shell.8.in
+++ b/docs/remctl-shell.8.in
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL-SHELL 8"
-.TH REMCTL-SHELL 8 "2016-10-11" "3.13" "remctl"
+.TH REMCTL-SHELL 8 "2018-04-01" "3.14" "remctl"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -210,7 +210,7 @@ Also be aware that the full command is passed via command line arguments,
 which means, when invoking \fBremctl-shell\fR as a shell, there is a tight
 limit on the length of the whole command plus arguments.  Expect to have
 problems if the total command length exceeds 1000 characters.  For the
-same reason, binary data including nul characters cannot be passed via
+same reason, binary data including null characters cannot be passed via
 \&\fBremctl-shell\fR.  Invoking it as a forced command may work around these
 limitations by putting the command into the environment instead, but there
 may still be restrictions on that.  (The regular remctl protocol supports
@@ -244,7 +244,7 @@ where the argument to \fBremctl-shell\fR is the identity matching the ssh key
 on that line.  A more complete example of a line in \fIauthorized_keys\fR:
 .PP
 .Vb 4
-\&    command=="@sbindir@/remctl\-shell example@EXAMPLE.ORG",\e
+\&    command="@sbindir@/remctl\-shell example@EXAMPLE.ORG",\e
 \&    no\-agent\-forwarding,no\-port\-forwarding,no\-pty,no\-user\-rc,\e
 \&    no\-X11\-forwarding ssh\-rsa AAAAB3NzaC1yc2EA... \e
 \&    example@some\-host.example.org
@@ -412,7 +412,7 @@ purposes.
 .IX Item "REMUSER"
 .PD
 [3.12] Set to the value of \s-1REMCTL_CLIENT\s0 as set in the environment of
-\&\fBremctl-shell\fR. This should be set security via \fIauthorized_keys\fR as
+\&\fBremctl-shell\fR. This should be set securely via \fIauthorized_keys\fR as
 discussed above.
 .PP
 Note that \s-1REMOTE_HOST\s0 is not set by \fBremctl-shell\fR, at least currently.
@@ -448,7 +448,7 @@ error instead of to syslog.  You can do that with:
 If you don't want to see the normal command logging, add the \fB\-q\fR option
 as well.  You can test an alternate configuration file by specifying it
 with the \fB\-f\fR option.  You will need to set \s-1SSH_CONNECTION\s0 and either
-\&\s-1REMCTL_USER \s0(if using \fB\-c\fR) or \s-1SSH_ORIGINAL_COMMAND \s0(if passing the user
+\&\s-1REMCTL_USER\s0 (if using \fB\-c\fR) or \s-1SSH_ORIGINAL_COMMAND\s0 (if passing the user
 on the command line).
 .SH "COMPATIBILITY"
 .IX Header "COMPATIBILITY"
diff --git a/docs/remctl-shell.pod b/docs/remctl-shell.pod
index 0454050..608a6fb 100644
--- a/docs/remctl-shell.pod
+++ b/docs/remctl-shell.pod
@@ -77,7 +77,7 @@ Also be aware that the full command is passed via command line arguments,
 which means, when invoking B<remctl-shell> as a shell, there is a tight
 limit on the length of the whole command plus arguments.  Expect to have
 problems if the total command length exceeds 1000 characters.  For the
-same reason, binary data including nul characters cannot be passed via
+same reason, binary data including null characters cannot be passed via
 B<remctl-shell>.  Invoking it as a forced command may work around these
 limitations by putting the command into the environment instead, but there
 may still be restrictions on that.  (The regular remctl protocol supports
@@ -107,7 +107,7 @@ C<command> option like the below:
 where the argument to B<remctl-shell> is the identity matching the ssh key
 on that line.  A more complete example of a line in F<authorized_keys>:
 
-    command=="@sbindir@/remctl-shell example@EXAMPLE.ORG",\
+    command="@sbindir@/remctl-shell example@EXAMPLE.ORG",\
     no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,\
     no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2EA... \
     example@some-host.example.org
@@ -290,7 +290,7 @@ purposes.
 =item REMUSER
 
 [3.12] Set to the value of REMCTL_CLIENT as set in the environment of
-B<remctl-shell>. This should be set security via F<authorized_keys> as
+B<remctl-shell>. This should be set securely via F<authorized_keys> as
 discussed above.
 
 =back
diff --git a/docs/remctl.1 b/docs/remctl.1
index bbf8b0b..29a82fc 100644
--- a/docs/remctl.1
+++ b/docs/remctl.1
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTL 1"
-.TH REMCTL 1 "2016-10-11" "3.13" "remctl"
+.TH REMCTL 1 "2018-04-01" "3.14" "remctl"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
diff --git a/docs/remctld.8.in b/docs/remctld.8.in
index 94c0c74..c8d27ef 100644
--- a/docs/remctld.8.in
+++ b/docs/remctld.8.in
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32)
+.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -129,7 +129,7 @@
 .\" ========================================================================
 .\"
 .IX Title "REMCTLD 8"
-.TH REMCTLD 8 "2016-10-11" "3.13" "remctl"
+.TH REMCTLD 8 "2018-04-01" "3.14" "remctl"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -252,7 +252,7 @@ with the \fB\-k\fR option).  This is normally the most desirable behavior.
 .IP "\fB\-Z\fR" 4
 .IX Item "-Z"
 [3.7] When \fBremctld\fR is running in stand-alone mode, after it has set up
-its network socket and is ready to answer requests, raise \s-1SIGSTOP. \s0 This
+its network socket and is ready to answer requests, raise \s-1SIGSTOP.\s0  This
 signals to upstart, when using \f(CW\*(C`expect stop\*(C'\fR, that the daemon is ready to
 accept connections, and upstart will raise \s-1SIGCONT\s0 to allow \fBremctld\fR to
 continue.  This option is probably only useful when using upstart as the
@@ -305,7 +305,7 @@ for specific commands first (if any) and then the \f(CW\*(C`ALL\*(C'\fR catch-al
 .Sp
 Note that while the subcommand is passed to the executable as a
 command-line option, the command is not.  The command is available to the
-executable in the environment variable \s-1REMCTL_COMMAND \s0(see \s-1ENVIRONMENT\s0
+executable in the environment variable \s-1REMCTL_COMMAND\s0 (see \s-1ENVIRONMENT\s0
 below).
 .Sp
 The command \f(CW\*(C`help\*(C'\fR is handled specially if no such command is defined in
@@ -424,7 +424,7 @@ of service discovery.  Also see the \f(CW\*(C`help\*(C'\fR option.
 .IP "user=(\fIusername\fR | \fIuid\fR)" 4
 .IX Item "user=(username | uid)"
 [3.1] Run this command as the specified user, which can be given as either
-a username or as a \s-1UID. \s0 Even if given as a \s-1UID,\s0 the user must be found in
+a username or as a \s-1UID.\s0  Even if given as a \s-1UID,\s0 the user must be found in
 the user database (searched via \fIgetpwuid\fR\|(3)).  \fBremctld\fR will run the
 command as the specified user, including that user's primary and
 supplemental groups.
@@ -442,7 +442,7 @@ If \fImethod\fR is omitted, \fIacl\fR must either begin with \f(CW\*(C`/\*(C'\fR
 contain \f(CW\*(C`=\*(C'\fR.  Otherwise, it will be parsed as an option instead.  If
 there is any ambiguity, prepend the \fImethod\fR.
 .Sp
-As a special exception for backward compatibility, the \s-1ACL \s0\f(CW\*(C`ANYUSER\*(C'\fR
+As a special exception for backward compatibility, the \s-1ACL\s0 \f(CW\*(C`ANYUSER\*(C'\fR
 (case-sensitive) is treated as equivalent to \f(CW\*(C`anyuser:auth\*(C'\fR.
 .Sp
 Each entry is checked in order, and access is granted as soon as an entry
@@ -469,7 +469,7 @@ anonymous service tickets are enabled for the local Kerberos realm.
 .RE
 .RS 4
 .Sp
-For backwards compatibility, the \s-1ACL \s0\f(CW\*(C`ANYUSER\*(C'\fR is treated as identical to
+For backwards compatibility, the \s-1ACL\s0 \f(CW\*(C`ANYUSER\*(C'\fR is treated as identical to
 \&\f(CW\*(C`anyuser:auth\*(C'\fR.  This was the only supported any-user \s-1ACL\s0 syntax prior to
 remctl 3.10.
 .RE
@@ -528,7 +528,7 @@ alone does not grant access to anyone, and using deny on itself as in
 \&\f(CW\*(C`deny:deny:foo\*(C'\fR neither denies nor grants access to anyone.
 .IP "gput" 4
 .IX Item "gput"
-[2.13] This method is used to grant access based on the \s-1CMU GPUT \s0(Global
+[2.13] This method is used to grant access based on the \s-1CMU GPUT\s0 (Global
 Privileged User Table \*(-- see \fIgput\fR\|(5)).  The data is either a \s-1GPUT\s0 role
 name or a string of the form \fIgroup\fR[\fIxform\fR], where \fIgroup\fR is a \s-1GPUT\s0
 role name and \fIxform\fR is a \s-1GPUT\s0 transform string.  Access is granted if