< draft-ietf-curdle-ssh-ext-info-12.txt   draft-ietf-curdle-ssh-ext-info-15.txt >
Internet-Draft D. Bider Internet-Draft D. Bider
Updates: 4252, 4253, 4254 (if approved) Bitvise Limited Updates: 4252, 4253, 4254 (if approved) Bitvise Limited
Intended status: Standards Track August 22, 2017 Intended status: Standards Track September 23, 2017
Expires: February 22, 2018 Expires: March 23, 2018
Extension Negotiation in Secure Shell (SSH) Extension Negotiation in Secure Shell (SSH)
draft-ietf-curdle-ssh-ext-info-12.txt draft-ietf-curdle-ssh-ext-info-15.txt
Abstract Abstract
This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a
mechanism for SSH clients and servers to exchange information about mechanism for SSH clients and servers to exchange information about
supported protocol extensions confidentially after SSH key exchange. supported protocol extensions confidentially after SSH key exchange.
Status Status
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 5 skipping to change at page 2, line 5
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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents
1. Overview and Rationale ...........................................3
1.1. Requirements Terminology ...................................3
1.2. Wire Encoding Terminology ..................................3
2. Extension Negotiation Mechanism ..................................3
2.1. Signaling of Extension Negotiation in SSH_MSG_KEXINIT .......3
2.2. Enabling Criteria ...........................................4
2.3. SSH_MSG_EXT_INFO Message ....................................4
2.4. Message Order ...............................................4
2.5. Interpretation of Extension Names and Values ................5
3. Initially Defined Extensions .....................................6
3.1. "server-sig-algs" ...........................................6
3.2. "delay-compression" .........................................7
3.2.1. Awkwardly Timed Key Re-Exchange ......................8
3.2.2. Subsequent Re-Exchange ...............................8
3.2.3. Compatibility Note: OpenSSH up to 7.5 ................8
3.3. "no-flow-control" ...........................................9
3.3.1. Prior "No Flow Control" Practice .....................9
3.4. "elevation" ................................................10
4. IANA Considerations .............................................11
4.1. Additions to existing tables ...............................11
4.2. New table: Extension Names .................................11
4.2.1. Future Assignments to Extension Names ...............11
5. Security Considerations .........................................11
6. References ......................................................12
6.1. Normative References .......................................12
6.2. Informative References .....................................12
Author's Address ...................................................13
Acknowledgments ....................................................13
1. Overview and Rationale 1. Overview and Rationale
Secure Shell (SSH) is a common protocol for secure communication on Secure Shell (SSH) is a common protocol for secure communication on
the Internet. The original design of the SSH transport layer [RFC4253] the Internet. The original design of the SSH transport layer [RFC4253]
lacks proper extension negotiation. Meanwhile, diverse implementations lacks proper extension negotiation. Meanwhile, diverse implementations
take steps to ensure that known message types contain no unrecognized take steps to ensure that known message types contain no unrecognized
information. This makes it difficult for implementations to signal information. This makes it difficult for implementations to signal
capabilities and negotiate extensions without risking disconnection. capabilities and negotiate extensions without risking disconnection.
This obstacle has been recognized in relationship with [SSH-RSA-SHA2], This obstacle has been recognized in relationship with [SSH-RSA-SHA2],
where the need arises for a client to discover public key algorithms a where the need arises for a client to discover public key algorithms a
skipping to change at page 2, line 32 skipping to change at page 3, line 32
"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. Wire Encoding Terminology 1.2. Wire Encoding Terminology
The wire encoding types in this document - "byte", "uint32", "string", The wire encoding types in this document - "byte", "uint32", "string",
"boolean", "name-list" - have meanings as described in [RFC4251]. "boolean", "name-list" - have meanings as described in [RFC4251].
2. Extension Negotiation Mechanism 2. Extension Negotiation Mechanism
2.1. Signaling of Extension Negotiation in KEXINIT 2.1. Signaling of Extension Negotiation in SSH_MSG_KEXINIT
Applications implementing this mechanism MUST add to the field Applications implementing this mechanism MUST add one of the following
"kex_algorithms", in their KEXINIT packet sent for the first key indicator names to the field "kex_algorithms" in the SSH_MSG_KEXINIT
exchange, one of the following indicator names: message sent by the application in the first key exchange:
- When acting as server: "ext-info-s" - When acting as server: "ext-info-s"
- When acting as client: "ext-info-c" - When acting as client: "ext-info-c"
The indicator name is added without quotes, and MAY be added at any The indicator name is added without quotes, and MAY be added at any
position in the name-list, subject to proper separation from other position in the name-list, subject to proper separation from other
names as per name-list conventions. names as per name-list conventions.
The names are added to the "kex_algorithms" field because this is one The names are added to the "kex_algorithms" field because this is one
of two name-list fields in KEXINIT that do not have a separate copy of two name-list fields in SSH_MSG_KEXINIT that do not have a separate
for each data direction. copy for each data direction.
The indicator names inserted by the client and server are different to The indicator names inserted by the client and server are different to
ensure these names will not produce a match, and therefore not affect ensure these names will not produce a match, and therefore not affect
the algorithm chosen in key exchange algorithm negotiation. the algorithm chosen in key exchange algorithm negotiation.
The inclusion of textual indicator names is intended to provide a clue The inclusion of textual indicator names is intended to provide a clue
for implementers to discover this mechanism. for implementers to discover this mechanism.
2.2. Enabling Criteria 2.2. Enabling Criteria
skipping to change at page 3, line 19 skipping to change at page 4, line 19
message from the peer. message from the peer.
A server only needs to send "ext-info-s" if it intends to process A server only needs to send "ext-info-s" if it intends to process
SSH_MSG_EXT_INFO from the client. A client only needs to send SSH_MSG_EXT_INFO from the client. A client only needs to send
"ext-info-c" if it plans to process SSH_MSG_EXT_INFO from the server. "ext-info-c" if it plans to process SSH_MSG_EXT_INFO from the server.
If a server receives an "ext-info-c", or a client receives an If a server receives an "ext-info-c", or a client receives an
"ext-info-s", it MAY send an SSH_MSG_EXT_INFO message, but is not "ext-info-s", it MAY send an SSH_MSG_EXT_INFO message, but is not
required to do so. required to do so.
Neither party needs to wait for the other's KEXINIT in order to decide Neither party needs to wait for the other's SSH_MSG_KEXINIT in order
whether to send the appropriate indicator in its own KEXINIT. to decide whether to send the appropriate indicator in its own
SSH_MSG_KEXINIT.
Implementations MUST NOT send an incorrect indicator name for their Implementations MUST NOT send an incorrect indicator name for their
role. Implementations MAY disconnect if the counter-party sends an role. Implementations MAY disconnect if the counter-party sends an
incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being
negotiated as a key exchange method, the parties MUST disconnect. negotiated as a key exchange method, the parties MUST disconnect.
2.3. SSH_MSG_EXT_INFO Message 2.3. SSH_MSG_EXT_INFO Message
A party that received the "ext-info-c" or "ext-info-s" indicator A party that received the "ext-info-c" or "ext-info-s" indicator
MAY send the following message: MAY send the following message:
byte SSH_MSG_EXT_INFO (value 7) byte SSH_MSG_EXT_INFO (value 7)
uint32 nr-extensions uint32 nr-extensions
repeat the following 2 fields "nr-extensions" times: repeat the following 2 fields "nr-extensions" times:
string extension-name string extension-name
string extension-value (binary) string extension-value (binary)
This message is sent immediately after SSH_MSG_NEWKEYS, without delay. Implementers' attention is called to Section 2.5., in particular the
This allows a client to pipeline an authentication request after its requirement to tolerate any sequence of bytes - including null bytes
SSH_MSG_SERVICE_REQUEST, even when this needs extension information. at any position - in an unknown extension's extension-value.
Receivers MUST tolerate any sequence of bytes; including null bytes 2.4. Message Order
at any position; in an unknown extension's extension-value.
2.4. Server's Secondary SSH_MSG_EXT_INFO If a client sends SSH_MSG_EXT_INFO, it MUST send it as the next packet
following the client's first SSH_MSG_NEWKEYS message to the server.
If the client sent "ext-info-c", the server MAY send zero, one, or two If a server sends SSH_MSG_EXT_INFO, it MAY send it at zero, one, or
EXT_INFO messages. The first opportunity for the server's EXT_INFO is both of the following opportunities:
after the server's NEWKEYS, as above. The second opportunity is just
before (*) SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]. The
server MAY send EXT_INFO at the second opportunity, whether or not it
sent it at the first. A client that sent "ext-info-c" MUST accept a
server's EXT_INFO at both opportunities, but MUST NOT require it.
This allows a server to reveal support for additional extensions that - As the next packet following the server's first SSH_MSG_NEWKEYS.
it was unwilling to reveal to an unauthenticated client. If a server
sends a subsequent SSH_MSG_EXT_INFO, this replaces any initial one,
and both the client and the server re-evaluate extensions in effect.
The server's last EXT_INFO is matched against the client's original.
(*) The message MUST be sent at this point for the following reasons: Where clients need information in the server's SSH_MSG_EXT_INFO to
if it was sent earlier, it would not allow the server to withhold authenticate, it is helpful if the server sends its SSH_MSG_EXT_INFO
information until the client has authenticated; if it was sent later, not only as next packet after SSH_MSG_NEWKEYS, but without delay.
a client that needs information from the second EXT_INFO immediately
after successful authentication would have no way of reliably knowing Clients cannot rely on this because the server is not required to
whether there will be a second EXT_INFO or not. send the message at this time; and if sent, it may be delayed by
the network. However, if a timely SSH_MSG_EXT_INFO is received,
a client can pipeline an authentication request after its
SSH_MSG_SERVICE_REQUEST, even when it needs extension information.
- Immediately preceding the server's SSH_MSG_USERAUTH_SUCCESS, as
defined in [RFC4252].
The server MAY send SSH_MSG_EXT_INFO at this second opportunity,
whether or not it sent it at the first. A client that sent
"ext-info-c" MUST accept a server's SSH_MSG_EXT_INFO at both
opportunities, but MUST NOT require it.
This allows a server to reveal support for additional extensions
that it was unwilling to reveal to an unauthenticated client. If a
server sends a second SSH_MSG_EXT_INFO, this replaces any initial
one, and both the client and the server re-evaluate extensions in
effect. The server's second SSH_MSG_EXT_INFO is matched against the
client's original.
The timing of the second opportunity is chosen for the following
reasons. If the message was sent earlier, it would not allow the
server to withhold information until the client has authenticated.
If it was sent later, a client that needs information from the
second SSH_MSG_EXT_INFO immediately after it authenticates would
have no way to reliably know whether to expect the message.
2.5. Interpretation of Extension Names and Values 2.5. Interpretation of Extension Names and Values
Each extension is identified by its extension-name, and defines the Each extension is identified by its extension-name, and defines the
conditions under which the extension is considered to be in effect. conditions under which the extension is considered to be in effect.
Applications MUST ignore unrecognized extension-names. Applications MUST ignore unrecognized extension-names.
An extension MAY dictate, where it is specified, that in order to take An extension MAY dictate, where it is specified, that in order to take
effect, both parties must include it in their EXT_INFO; or it MAY be effect, both parties must include it in their SSH_MSG_EXT_INFO; or it
sufficient that only one party includes it; or other rules MAY be can be sufficient that only one party includes it; or other rules MAY
specified. The relative order in which extensions appear in an be specified. The relative order in which extensions appear in an
EXT_INFO message MUST be ignored by default; but an extension MAY SSH_MSG_EXT_INFO message MUST be ignored.
specify that the order matters for that extension, in a specific way.
Extension-value fields are interpreted as defined by their respective Extension-value fields are interpreted as defined by their respective
extension. An extension-value field MAY be empty if so permitted by extension. This field MAY be empty if permitted by the extension.
the extension. Applications that do not implement or recognize a Applications that do not implement or recognize an extension MUST
particular extension MUST ignore the associated extension-value field, ignore its extension-value, regardless of its size or content.
regardless of its size or content. In particular, applications MUST Applications MUST tolerate any sequence of bytes - including null
tolerate any sequence of bytes; including null bytes at any position; bytes at any position - in an unknown extension's extension-value.
in an unknown extension's extension-value.
The cumulative size of an SSH_MSG_EXT_INFO message is limited only by The cumulative size of an SSH_MSG_EXT_INFO message is limited only by
the maximum packet length that an implementation may apply in the maximum packet length that an implementation may apply in
accordance with [RFC4253]. Implementations MUST accept well-formed accordance with [RFC4253]. Implementations MUST accept well-formed
SSH_MSG_EXT_INFO messages up to the maximum packet length they accept. SSH_MSG_EXT_INFO messages up to the maximum packet length they accept.
3. Initially Defined Extensions 3. Initially Defined Extensions
3.1. "server-sig-algs" 3.1. "server-sig-algs"
skipping to change at page 5, line 27 skipping to change at page 6, line 39
wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey" wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey"
authentication request with an appropriate public key algorithm, authentication request with an appropriate public key algorithm,
rather than resorting to trial and error. rather than resorting to trial and error.
Servers that implement public key authentication SHOULD implement this Servers that implement public key authentication SHOULD implement this
extension. extension.
If a server does not send this extension, a client MUST NOT make any If a server does not send this extension, a client MUST NOT make any
assumptions about the server's public key algorithm support, and MAY assumptions about the server's public key algorithm support, and MAY
proceed with authentication requests using trial and error. Note that proceed with authentication requests using trial and error. Note that
implementations are known to exist that apply authentication penalties implementations are known to exist that apply authentication
if the client attempts to use an unexpected public key algorithm. penalties (*) if the client attempts to use an unexpected public key
algorithm.
(*) Authentication penalties are applied by servers to deter brute
force password guessing, username enumeration, and other types of
behavior deemed suspicious by server administrators or implementers.
Penalties may include automatic IP address throttling or blocking,
and may trigger email alerts or auditing.
3.2. "delay-compression" 3.2. "delay-compression"
This extension MAY be sent by both parties as follows: This extension MAY be sent by both parties as follows:
string "delay-compression" string "delay-compression"
string: string:
name-list compression_algorithms_client_to_server name-list compression_algorithms_client_to_server
name-list compression_algorithms_server_to_client name-list compression_algorithms_server_to_client
The extension-value is a string that encodes two name-lists. The
name-lists themselves have the encoding of strings. For example: to
indicate a preference for algorithms "foo,bar" in the client-to-server
direction, and "bar,baz" in the server-to-client direction, a sender
encodes the extension-value as follows (including its length):
00000016 00000007 666f6f2c626172 00000007 6261722c62617a
This same encoding could be sent by either party - client or server.
This extension allows the server and client to renegotiate compression This extension allows the server and client to renegotiate compression
algorithm support without having to conduct a key re-exchange, putting algorithm support without having to conduct a key re-exchange, putting
new algorithms into effect immediately upon successful authentication. new algorithms into effect immediately upon successful authentication.
This extension takes effect only if both parties send it. Name-lists This extension takes effect only if both parties send it. Name-lists
MAY include any compression algorithm that could have been negotiated MAY include any compression algorithm that could have been negotiated
in SSH_MSG_KEXINIT, except algorithms that define their own delayed in SSH_MSG_KEXINIT, except algorithms that define their own delayed
compression semantics. This means "zlib,none" is a valid algorithm compression semantics. This means "zlib,none" is a valid algorithm
list in this context; but "zlib@openssh.com" is not. list in this context; but "zlib@openssh.com" is not.
skipping to change at page 6, line 12 skipping to change at page 7, line 45
a common algorithm in either direction, the parties MUST disconnect in a common algorithm in either direction, the parties MUST disconnect in
the same way as if negotiation failed as part of SSH_MSG_KEXINIT. the same way as if negotiation failed as part of SSH_MSG_KEXINIT.
If this extension takes effect, the renegotiated compression algorithm If this extension takes effect, the renegotiated compression algorithm
is activated for the very next SSH message after the trigger message: is activated for the very next SSH message after the trigger message:
- Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS. - Sent by the server, the trigger message is SSH_MSG_USERAUTH_SUCCESS.
- Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS. - Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS.
If this extension takes effect, the client MUST send the following If this extension takes effect, the client MUST send the following
message shortly after receiving SSH_MSG_USERAUTH_SUCCESS: message within a reasonable number of outgoing SSH messages after
receiving SSH_MSG_USERAUTH_SUCCESS - but not necessarily as the first
such outgoing message:
byte SSH_MSG_NEWCOMPRESS (value 8) byte SSH_MSG_NEWCOMPRESS (value 8)
The purpose of NEWCOMPRESS is to avoid a race condition where the The purpose of SSH_MSG_NEWCOMPRESS is to avoid a race condition
server cannot reliably know whether a message sent by the client was where the server cannot reliably know whether a message sent by
sent before or after receiving the server's USERAUTH_SUCCESS. the client was sent before or after receiving the server's
SSH_MSG_USERAUTH_SUCCESS. For example, clients may send keep-alive
messages during logon processing.
As with all extensions, the server MAY delay including this extension As is the case for all extensions unless otherwise noted, the server
until its secondary SSH_MSG_EXT_INFO, sent before USERAUTH_SUCCESS. MAY delay including this extension until its secondary
This allows the server to avoid advertising compression support until SSH_MSG_EXT_INFO, sent before SSH_MSG_USERAUTH_SUCCESS. This allows
the client has been authenticated. the server to avoid advertising compression until the client has
authenticated.
If the parties re-negotiate compression using this extension in a If the parties re-negotiate compression using this extension in a
session where compression is already enabled; and the re-negotiated session where compression is already enabled; and the re-negotiated
algorithm is the same in one or both directions; then the internal algorithm is the same in one or both directions; then the internal
compression state MUST be reset for each direction at the time the compression state MUST be reset for each direction at the time the
re-negotiated algorithm takes effect. re-negotiated algorithm takes effect.
3.2.1. Awkwardly Timed Key Re-Exchange 3.2.1. Awkwardly Timed Key Re-Exchange
A party that has signaled, or intends to signal, support for this A party that has signaled, or intends to signal, support for this
skipping to change at page 7, line 5 skipping to change at page 8, line 40
In general, parties SHOULD NOT start key re-exchange before successful In general, parties SHOULD NOT start key re-exchange before successful
user authentication, but MAY tolerate it if not using this extension. user authentication, but MAY tolerate it if not using this extension.
3.2.2. Subsequent Re-Exchange 3.2.2. Subsequent Re-Exchange
In subsequent key re-exchanges that unambiguously begin after the In subsequent key re-exchanges that unambiguously begin after the
compression trigger messages, the compression algorithms negotiated in compression trigger messages, the compression algorithms negotiated in
re-exchange override the algorithms negotiated with this extension. re-exchange override the algorithms negotiated with this extension.
3.2.3. Compatibility Note: OpenSSH up to 7.5
This extension uses a binary extension-value encoding. OpenSSH clients
up to and including version 7.5 advertise support to receive
SSH_MSG_EXT_INFO, but disconnect on receipt of an extension-value
containing null bytes. This is an error fixed in OpenSSH version 7.6.
Implementations that wish to interoperate with OpenSSH 7.5 and earlier
are advised to check the remote party's SSH version string, and omit
this extension if an affected version is detected. Affected versions
do not implement this extension, so there is no harm in omitting it.
The extension SHOULD NOT be omitted if the detected OpenSSH version is
7.6 or higher. This would make it harder for the OpenSSH project to
implement this extension in a higher version.
3.3. "no-flow-control" 3.3. "no-flow-control"
This extension is sent with the following extension name and value: This extension is sent with the following extension name and value:
string "no-flow-control" string "no-flow-control"
string choice of: "p" for preferred | "s" for supported string choice of: "p" for preferred | "s" for supported
A party SHOULD send "s" if it supports "no-flow-control", but does not A party SHOULD send "s" if it supports "no-flow-control", but does not
prefer to enable it. A party SHOULD send "p" if it prefers to enable prefer to enable it. A party SHOULD send "p" if it prefers to enable
the extension if the other party supports it. Parties MAY disconnect the extension if the other party supports it. Parties MAY disconnect
skipping to change at page 7, line 37 skipping to change at page 9, line 37
messages, and if received, such messages MUST be ignored. messages, and if received, such messages MUST be ignored.
This extension is intended, but not limited to, use by file transfer This extension is intended, but not limited to, use by file transfer
applications that are only going to use one channel, and for which the applications that are only going to use one channel, and for which the
flow control provided by SSH is an impediment, rather than a feature. flow control provided by SSH is an impediment, rather than a feature.
Implementations MUST refuse to open more than one simultaneous channel Implementations MUST refuse to open more than one simultaneous channel
when this extension is in effect. Nevertheless, server implementations when this extension is in effect. Nevertheless, server implementations
SHOULD support clients opening more than one non-simultaneous channel. SHOULD support clients opening more than one non-simultaneous channel.
3.3.1. Implementation Note: Prior "No Flow Control" Practice 3.3.1. Prior "No Flow Control" Practice
Before this extension, some applications would simply not implement Before this extension, some applications would simply not implement
SSH flow control, sending an initial channel window size of 2^32 - 1. SSH flow control, sending an initial channel window size of 2^32 - 1.
Applications SHOULD NOT do this for the following reasons: Applications SHOULD NOT do this for the following reasons:
- It is entirely within the realm of possibility to transfer more than - It is plausible to transfer more than 2^32 bytes over a channel.
2^32 bytes over a channel. The channel will then hang if the other Such a channel will hang if the other party implements SSH flow
party implements SSH flow control according to [RFC4254]. control according to [RFC4254].
- There exist implementations which cannot handle such large channel - There exist implementations which cannot handle large channel window
window sizes, and will exhibit non-graceful behaviors, including sizes, and can exhibit non-graceful behaviors, including disconnect.
disconnection.
3.4. "elevation" 3.4. "elevation"
The terms "elevation" and "elevated" refer to an operating system
mechanism where an administrator user's logon session is associated
with two security contexts: one limited, and one with administrative
rights. To "elevate" such a session is to activate the security
context with full administrative rights. For more information about
this mechanism on Windows, see also [WINADMIN] and [WINTOKEN].
This extension MAY be sent by the client as follows: This extension MAY be sent by the client as follows:
string "elevation" string "elevation"
string choice of: "y" | "n" | "d" string choice of: "y" | "n" | "d"
A client sends "y" to indicate its preference that the session should A client sends "y" to indicate its preference that the session should
be elevated; "n" to not be elevated; and "d" for the server to use its be elevated; "n" to not be elevated; and "d" for the server to use its
default behavior. The server MAY disconnect if it receives a different default behavior. The server MAY disconnect if it receives a different
extension value. If a client does not send the "elevation" extension, extension value. If a client does not send the "elevation" extension,
the server SHOULD act as if "d" was sent. the server SHOULD act as if "d" was sent.
The terms "elevation" and "elevated" refer to an operating system
mechanism where an administrator user's logon session is associated
with two security contexts: one limited, and one with administrative
rights. To "elevate" such a session is to activate the security
context with full administrative rights. For more information about
this mechanism on Windows, see also [WINADMIN] and [WINTOKEN].
If a client has included this extension, then after authentication, a If a client has included this extension, then after authentication, a
server that supports this extension SHOULD indicate to the client server that supports this extension SHOULD indicate to the client
whether elevation was done by sending the following global request: whether elevation was done by sending the following global request:
byte SSH_MSG_GLOBAL_REQUEST byte SSH_MSG_GLOBAL_REQUEST
string "elevation" string "elevation"
boolean want reply = false boolean want reply = false
boolean elevation performed boolean elevation performed
Clients that implement this extension help reduce attack surface for
Windows servers that handle administrative logins. Where clients do
not support this extension, servers must elevate sessions to allow
full access by administrative users always. Where clients support this
extension, sessions can be created without elevation unless requested.
4. IANA Considerations 4. IANA Considerations
4.1. Additions to existing tables 4.1. Additions to existing tables
IANA is requested to insert the following entries into the table IANA is requested to insert the following entries into the table
Message Numbers [IANA-M] under Secure Shell (SSH) Protocol Parameters Message Numbers [IANA-M] under Secure Shell (SSH) Protocol Parameters
[RFC4250]: [RFC4250]:
Value Message ID Reference Value Message ID Reference
7 SSH_MSG_EXT_INFO [this document] 7 SSH_MSG_EXT_INFO [this document]
skipping to change at page 11, line 20 skipping to change at page 13, line 20
Colleyville, Texas 76034 Colleyville, Texas 76034
United States of America United States of America
EMail: ietf-ssh3@denisbider.com EMail: ietf-ssh3@denisbider.com
URI: https://www.bitvise.com/ URI: https://www.bitvise.com/
Acknowledgments Acknowledgments
Thanks to Markus Friedl and Damien Miller for comments and initial Thanks to Markus Friedl and Damien Miller for comments and initial
implementation. Thanks to Peter Gutmann, Roumen Petrov, Mark D. implementation. Thanks to Peter Gutmann, Roumen Petrov, Mark D.
Baushke, Daniel Migault, Eric Rescorla, and Matthew A. Miller for Baushke, Daniel Migault, Eric Rescorla, Matthew A. Miller, Mirja
review and feedback. Kuehlewind, Adam Roach, Spencer Dawkins, Alexey Melnikov, and Ben
Campbell for reviews and feedback.
 End of changes. 29 change blocks. 
70 lines changed or deleted 159 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/