acw/hushd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

well, tests pass now

Browse Source
This commit is contained in:
Adam Wick
2024-10-14 17:33:24 -07:00
parent 795c528754
commit a813b65535
81 changed files with 15233 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1795
specifications/rfc4253.txt Normal file
View File

File diff suppressed because it is too large Load Diff

283
specifications/rfc6668.txt Normal file
View File

@@ -0,0 +1,283 @@
Internet Engineering Task Force (IETF) D. Bider
Request for Comments: 6668 Bitvise Limited
Updates: 4253 M. Baushke
Category: Standards Track Juniper Networks, Inc.
ISSN: 2070-1721 July 2012
SHA-2 Data Integrity Verification for
the Secure Shell (SSH) Transport Layer Protocol
Abstract
This memo defines algorithm names and parameters for use in some of
the SHA-2 family of secure hash algorithms for data integrity
verification in the Secure Shell (SSH) protocol. It also updates RFC
4253 by specifying a new RECOMMENDED data integrity algorithm.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6668.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bider & Baushke Standards Track [Page 1]
RFC 6668 Sha2-Transport Layer Protocol July 2012
1. Overview and Rationale
The Secure Shell (SSH) [RFC4251] is a very common protocol for secure
remote login on the Internet. Currently, SSH defines data integrity
verification using SHA-1 and MD5 algorithms [RFC4253]. Due to recent
security concerns with these two algorithms ([RFC6194] and [RFC6151],
respectively), implementors and users request support for data
integrity verification using some of the SHA-2 family of secure hash
algorithms.
1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Data Integrity Algorithms
This memo adopts the style and conventions of [RFC4253] in specifying
how the use of new data integrity algorithms are indicated in SSH.
The following new data integrity algorithms are defined:
hmac-sha2-256 RECOMMENDED HMAC-SHA2-256
(digest length = 32 bytes,
key length = 32 bytes)
hmac-sha2-512 OPTIONAL HMAC-SHA2-512
(digest length = 64 bytes,
key length = 64 bytes)
Figure 1
The Hashed Message Authentication Code (HMAC) mechanism was
originally defined in [RFC2104] and has been updated in [RFC6151].
The SHA-2 family of secure hash algorithms is defined in
[FIPS-180-3].
Sample code for the SHA-based HMAC algorithms are available in
[RFC6234]. The variants, HMAC-SHA2-224 and HMAC-SHA2-384 algorithms,
were considered but not added to this list as they have the same
computational requirements of HMAC-SHA2-256 and HMAC-SHA2-512,
respectively, and do not seem to be much used in practice.
Bider & Baushke Standards Track [Page 2]
RFC 6668 Sha2-Transport Layer Protocol July 2012
Test vectors for use of HMAC with SHA-2 are provided in [RFC4231].
Users, implementors, and administrators may choose to put these new
MACs into the proposal ahead of the REQUIRED hmac-sha1 algorithm
defined in [RFC4253] so that they are negotiated first.
3. IANA Considerations
This document augments the MAC Algorithm Names in [RFC4253] and
[RFC4250].
IANA has updated the "Secure Shell (SSH) Protocol Parameters"
registry with the following entries:
MAC Algorithm Name Reference Note
hmac-sha2-256 RFC 6668 Section 2
hmac-sha2-512 RFC 6668 Section 2
Figure 2
4. Security Considerations
The security considerations of RFC 4253 [RFC4253] apply to this
document.
The National Institute of Standards and Technology (NIST)
publications: NIST Special Publication (SP) 800-107 [800-107] and
NIST SP 800-131A [800-131A] suggest that HMAC-SHA1 and HMAC-SHA2-256
have a security strength of 128 bits and 256 bits, respectively,
which are considered acceptable key lengths.
Many users seem to be interested in the perceived safety of using the
SHA2-based algorithms for hashing.
5. References
5.1. Normative References
[FIPS-180-3]
National Institute of Standards and Technology (NIST),
United States of America, "Secure Hash Standard (SHS)",
FIPS PUB 180-3, October 2008, <http://csrc.nist.gov/
publications/fips/fips180-3/fips180-3_final.pdf>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
Bider & Baushke Standards Track [Page 3]
RFC 6668 Sha2-Transport Layer Protocol July 2012
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-
SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, December 2005.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.
5.2. Informative References
[800-107] National Institute of Standards and Technology (NIST),
"Recommendation for Applications Using Approved Hash
Algorithms", NIST Special Publication 800-107, February
2009, <http://csrc.nist.gov/publications/
nistpubs/800-107/NIST-SP-800-107.pdf>.
[800-131A] National Institute of Standards and Technology (NIST),
"Transitions: Recommendation for the Transitioning of the
Use of Cryptographic Algorithms and Key Lengths", DRAFT
NIST Special Publication 800-131A, January 2011,
<http://csrc.nist.gov/publications/nistpubs/800-131A/
sp800-131A.pdf>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, March 2011.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, March 2011.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
Bider & Baushke Standards Track [Page 4]
RFC 6668 Sha2-Transport Layer Protocol July 2012
Authors' Addresses
Denis Bider
Bitvise Limited
Suites 41/42, Victoria House
26 Main Street
GI
Phone: +1 869 762 1410
EMail: ietf-ssh2@denisbider.com
URI: http://www.bitvise.com/
Mark D. Baushke
Juniper Networks, Inc.
1194 N Mathilda Av
Sunnyvale, CA 94089-1206
US
Phone: +1 408 745 2952
EMail: mdb@juniper.net
URI: http://www.juniper.net/
Bider & Baushke Standards Track [Page 5]

787
specifications/rfc8308.txt Normal file
View File

@@ -0,0 +1,787 @@
Internet Engineering Task Force (IETF) D. Bider
Request for Comments: 8308 Bitvise Limited
Updates: 4251, 4252, 4253, 4254 March 2018
Category: Standards Track
ISSN: 2070-1721
Extension Negotiation in the Secure Shell (SSH) Protocol
Abstract
This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a
mechanism for Secure Shell (SSH) clients and servers to exchange
information about supported protocol extensions confidentially after
SSH key exchange.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8308.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bider Standards Track [Page 1]
RFC 8308 Extension Negotiation in SSH March 2018
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 ..............................................5
2.5. Interpretation of Extension Names and Values ...............6
3. Initially Defined Extensions ....................................6
3.1. "server-sig-algs" ..........................................6
3.2. "delay-compression" ........................................7
3.2.1. Awkwardly Timed Key Re-Exchange .....................9
3.2.2. Subsequent Re-Exchange ..............................9
3.2.3. Compatibility Note: OpenSSH up to Version 7.5 .......9
3.3. "no-flow-control" .........................................10
3.3.1. Prior "No Flow Control" Practice ...................10
3.4. "elevation" ...............................................11
4. IANA Considerations ............................................12
4.1. Additions to Existing Registries ..........................12
4.2. New Registry: Extension Names .............................12
4.2.1. Future Assignments to Extension Names Registry .....12
5. Security Considerations ........................................12
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................13
Acknowledgments ...................................................14
Author's Address ..................................................14
Bider Standards Track [Page 2]
RFC 8308 Extension Negotiation in SSH March 2018
1. Overview and Rationale
Secure Shell (SSH) is a common protocol for secure communication on
the Internet. The original design of the SSH transport layer
[RFC4253] lacks proper extension negotiation. Meanwhile, diverse
implementations take steps to ensure that known message types contain
no unrecognized information. This makes it difficult for
implementations to signal capabilities and negotiate extensions
without risking disconnection. This obstacle has been recognized in
the process of updating SSH to support RSA signatures using SHA-256
and SHA-512 [RFC8332]. To avoid trial and error as well as
authentication penalties, a client must be able to discover public
key algorithms a server accepts. This extension mechanism permits
this discovery.
This memo updates RFCs 4251, 4252, 4253, and 4254.
1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Wire Encoding Terminology
The wire encoding types in this document -- "byte", "uint32",
"string", "boolean", "name-list" -- have meanings as described in
[RFC4251].
2. Extension Negotiation Mechanism
2.1. Signaling of Extension Negotiation in SSH_MSG_KEXINIT
Applications implementing this mechanism MUST add one of the
following indicator names to the field kex_algorithms in the
SSH_MSG_KEXINIT message sent by the application in the first key
exchange:
o When acting as server: "ext-info-s"
o When acting as client: "ext-info-c"
The indicator name is added without quotes and MAY be added at any
position in the name-list, subject to proper separation from other
names as per name-list conventions.
Bider Standards Track [Page 3]
RFC 8308 Extension Negotiation in SSH March 2018
The names are added to the kex_algorithms field because this is one
of two name-list fields in SSH_MSG_KEXINIT that do not have a
separate copy for each data direction.
The indicator names inserted by the client and server are different
to ensure these names will not produce a match and therefore not
affect the algorithm chosen in key exchange algorithm negotiation.
The inclusion of textual indicator names is intended to provide a
clue for implementers to discover this mechanism.
2.2. Enabling Criteria
If a client or server offers "ext-info-c" or "ext-info-s"
respectively, it MUST be prepared to accept an SSH_MSG_EXT_INFO
message from the peer.
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
"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
"ext-info-s", it MAY send an SSH_MSG_EXT_INFO message but is not
required to do so.
Neither party needs to wait for the other's SSH_MSG_KEXINIT in order
to decide whether to send the appropriate indicator in its own
SSH_MSG_KEXINIT.
Implementations MUST NOT send an incorrect indicator name for their
role. Implementations MAY disconnect if the counterparty sends an
incorrect indicator. If "ext-info-c" or "ext-info-s" ends up being
negotiated as a key exchange method, the parties MUST disconnect.
2.3. SSH_MSG_EXT_INFO Message
A party that received the "ext-info-c" or "ext-info-s" indicator MAY
send the following message:
byte SSH_MSG_EXT_INFO (value 7)
uint32 nr-extensions
repeat the following 2 fields "nr-extensions" times:
string extension-name
string extension-value (binary)
Bider Standards Track [Page 4]
RFC 8308 Extension Negotiation in SSH March 2018
Implementers should pay careful attention to Section 2.5, in
particular to the requirement to tolerate any sequence of bytes
(including null bytes at any position) in an unknown extension's
extension-value.
2.4. Message Order
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 a server sends SSH_MSG_EXT_INFO, it MAY send it at zero, one, or
both of the following opportunities:
o As the next packet following the server's first SSH_MSG_NEWKEYS.
Where clients need information in the server's SSH_MSG_EXT_INFO to
authenticate, it is helpful if the server sends its
SSH_MSG_EXT_INFO not only as the next packet after
SSH_MSG_NEWKEYS, but without delay.
Clients cannot rely on this because the server is not required to
send the message at this time; 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.
o 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.
Bider Standards Track [Page 5]
RFC 8308 Extension Negotiation in SSH March 2018
2.5. Interpretation of Extension Names and Values
Each extension is identified by its extension-name and defines the
conditions under which the extension is considered to be in effect.
Applications MUST ignore unrecognized extension-names.
When it is specified, an extension MAY dictate that, in order to take
effect, both parties must include it in their SSH_MSG_EXT_INFO or
that it is sufficient for only one party to include it. However,
other rules MAY be specified. The relative order in which extensions
appear in an SSH_MSG_EXT_INFO message MUST be ignored.
Extension-value fields are interpreted as defined by their respective
extension. This field MAY be empty if permitted by the extension.
Applications that do not implement or recognize an extension MUST
ignore its extension-value, regardless of its size or content.
Applications MUST tolerate any sequence of bytes -- including null
bytes at any position -- in an unknown extension's extension-value.
The cumulative size of an SSH_MSG_EXT_INFO message is limited only by
the maximum packet length that an implementation may apply in
accordance with [RFC4253]. Implementations MUST accept well-formed
SSH_MSG_EXT_INFO messages up to the maximum packet length they
accept.
3. Initially Defined Extensions
3.1. "server-sig-algs"
This extension is sent with the following extension name and value:
string "server-sig-algs"
name-list public-key-algorithms-accepted
The name-list type is a strict subset of the string type and is thus
permissible as an extension-value. See [RFC4251] for more
information.
This extension is sent by the server and contains a list of public
key algorithms that the server is able to process as part of a
"publickey" authentication request. If a client sends this
extension, the server MAY ignore it and MAY disconnect.
In this extension, a server MUST enumerate all public key algorithms
it might accept during user authentication. However, early server
implementations that do not enumerate all accepted algorithms do
Bider Standards Track [Page 6]
RFC 8308 Extension Negotiation in SSH March 2018
exist. For this reason, a client MAY send a user authentication
request using a public key algorithm not included in "server-sig-
algs".
A client that wishes to proceed with public key authentication MAY
wait for the server's SSH_MSG_EXT_INFO so it can send a "publickey"
authentication request with an appropriate public key algorithm,
rather than resorting to trial and error.
Servers that implement public key authentication SHOULD implement
this extension.
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
proceed with authentication requests using trial and error. Note
that implementations are known to exist that apply authentication
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 they may trigger email alerts or auditing.
3.2. "delay-compression"
This extension MAY be sent by both parties as follows:
string "delay-compression"
string:
name-list compression_algorithms_client_to_server
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 algorithm support without having to conduct a key
re-exchange, which puts new algorithms into effect immediately upon
successful authentication.
Bider Standards Track [Page 7]
RFC 8308 Extension Negotiation in SSH March 2018
This extension takes effect only if both parties send it. Name-lists
MAY include any compression algorithm that could have been negotiated
in SSH_MSG_KEXINIT, except algorithms that define their own delayed
compression semantics. This means "zlib,none" is a valid algorithm
list in this context, but "zlib@openssh.com" is not.
If both parties send this extension, but the name-lists do not
contain a common algorithm in either direction, the parties MUST
disconnect in the same way as if negotiation failed as part of
SSH_MSG_KEXINIT.
If this extension takes effect, the renegotiated compression
algorithm is activated for the very next SSH message after the
trigger message:
o Sent by the server, the trigger message is
SSH_MSG_USERAUTH_SUCCESS.
o Sent by the client, the trigger message is SSH_MSG_NEWCOMPRESS.
If this extension takes effect, the client MUST send the following
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)
The purpose of SSH_MSG_NEWCOMPRESS is to avoid a race condition where
the server cannot reliably know whether a message sent by 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 is the case for all extensions unless otherwise noted, the server
MAY delay including this extension until its secondary
SSH_MSG_EXT_INFO, sent before SSH_MSG_USERAUTH_SUCCESS. This allows
the server to avoid advertising compression until the client has
authenticated.
If the parties renegotiate compression using this extension in a
session where compression is already enabled and the renegotiated
algorithm is the same in one or both directions, then the internal
compression state MUST be reset for each direction at the time the
renegotiated algorithm takes effect.
Bider Standards Track [Page 8]
RFC 8308 Extension Negotiation in SSH March 2018
3.2.1. Awkwardly Timed Key Re-Exchange
A party that has signaled, or intends to signal, support for this
extension in an SSH session MUST NOT initiate key re-exchange in that
session until either of the following occurs:
o This extension was negotiated, and the party that's about to start
key re-exchange already sent its trigger message for compression.
o The party has sent (if server) or received (if client) the message
SSH_MSG_USERAUTH_SUCCESS, and this extension was not negotiated.
If a party violates this rule, the other party MAY disconnect.
In general, parties SHOULD NOT start key re-exchange before
successful user authentication but MAY tolerate it if not using this
extension.
3.2.2. Subsequent Re-Exchange
In subsequent key re-exchanges that unambiguously begin after the
compression trigger messages, the compression algorithms negotiated
in re-exchange override the algorithms negotiated with this
extension.
3.2.3. Compatibility Note: OpenSSH up to Version 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.
Bider Standards Track [Page 9]
RFC 8308 Extension Negotiation in SSH March 2018
3.3. "no-flow-control"
This extension is sent with the following extension name and value:
string "no-flow-control"
string choice of: "p" for preferred | "s" for supported
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
the extension if the other party supports it. Parties MAY disconnect
if they receive a different extension value.
For this extension to take effect, the following must occur:
o This extension MUST be sent by both parties.
o At least one party MUST have sent the value "p" (preferred).
If this extension takes effect, the "initial window size" fields in
SSH_MSG_CHANNEL_OPEN and SSH_MSG_CHANNEL_OPEN_CONFIRMATION, as
defined in [RFC4254], become meaningless. The values of these fields
MUST be ignored, and a channel behaves as if all window sizes are
infinite. Neither side is required to send any
SSH_MSG_CHANNEL_WINDOW_ADJUST messages, and if received, such
messages MUST be ignored.
This extension is intended for, but not limited to, use by file
transfer 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.
Implementations MUST refuse to open more than one simultaneous
channel when this extension is in effect. Nevertheless, server
implementations SHOULD support clients opening more than one
non-simultaneous channel.
3.3.1. Prior "No Flow Control" Practice
Before this extension, some applications would simply not implement
SSH flow control, sending an initial channel window size of 2^32 - 1.
Applications SHOULD NOT do this for the following reasons:
o It is plausible to transfer more than 2^32 bytes over a channel.
Such a channel will hang if the other party implements SSH flow
control according to [RFC4254].
Bider Standards Track [Page 10]
RFC 8308 Extension Negotiation in SSH March 2018
o Implementations that cannot handle large channel window sizes
exist, and they can exhibit non-graceful behaviors, including
disconnect.
3.4. "elevation"
The terms "elevation" and "elevated" refer to an operating system
mechanism where an administrator'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 [WINADMIN] and [WINTOKEN].
This extension MAY be sent by the client as follows:
string "elevation"
string choice of: "y" | "n" | "d"
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 default behavior. The server MAY disconnect if it receives a
different extension value. If a client does not send the "elevation"
extension, the server SHOULD act as if "d" was sent.
If a client has included this extension, then after authentication, a
server that supports this extension SHOULD indicate to the client
whether elevation was done by sending the following global request:
byte SSH_MSG_GLOBAL_REQUEST
string "elevation"
boolean want reply = false
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.
Bider Standards Track [Page 11]
RFC 8308 Extension Negotiation in SSH March 2018
4. IANA Considerations
4.1. Additions to Existing Registries
IANA has added the following entries to the "Message Numbers"
registry [IANA-M] under the "Secure Shell (SSH) Protocol Parameters"
registry [RFC4250]:
Value Message ID Reference
-----------------------------------------
7 SSH_MSG_EXT_INFO RFC 8308
8 SSH_MSG_NEWCOMPRESS RFC 8308
IANA has also added the following entries to the "Key Exchange Method
Names" registry [IANA-KE]:
Method Name Reference Note
------------------------------------------
ext-info-s RFC 8308 Section 2
ext-info-c RFC 8308 Section 2
4.2. New Registry: Extension Names
Also under the "Secure Shell (SSH) Protocol Parameters" registry,
IANA has created a new "Extension Names" registry, with the following
initial content:
Extension Name Reference Note
------------------------------------------------
server-sig-algs RFC 8308 Section 3.1
delay-compression RFC 8308 Section 3.2
no-flow-control RFC 8308 Section 3.3
elevation RFC 8308 Section 3.4
4.2.1. Future Assignments to Extension Names Registry
Names in the "Extension Names" registry MUST follow the conventions
for names defined in [RFC4250], Section 4.6.1.
Requests for assignments of new non-local names in the "Extension
Names" registry (i.e., names not including the '@' character) MUST be
done using the IETF Review policy, as described in [RFC8126].
5. Security Considerations
Security considerations are discussed throughout this document. This
document updates the SSH protocol as defined in [RFC4251] and related
documents. The security considerations of [RFC4251] apply.
Bider Standards Track [Page 12]
RFC 8308 Extension Negotiation in SSH March 2018
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006,
<https://www.rfc-editor.org/info/rfc4250>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
January 2006, <https://www.rfc-editor.org/info/rfc4254>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[IANA-KE] IANA, "Key Exchange Method Names",
<https://www.iana.org/assignments/ssh-parameters/>.
[IANA-M] IANA, "Message Numbers",
<https://www.iana.org/assignments/ssh-parameters/>.
Bider Standards Track [Page 13]
RFC 8308 Extension Negotiation in SSH March 2018
[RFC8332] Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in
the Secure Shell (SSH) Protocol", RFC 8332,
DOI 10.17487/RFC8332, March 2018,
<https://www.rfc-editor.org/info/rfc8332>.
[WINADMIN] Microsoft, "How to launch a process as a Full
Administrator when UAC is enabled?", March 2013,
<https://blogs.msdn.microsoft.com/winsdk/2013/03/22/
how-to-launch-a-process-as-a-full-administrator-when-
uac-is-enabled/>.
[WINTOKEN] Microsoft, "TOKEN_ELEVATION_TYPE enumeration",
<https://msdn.microsoft.com/en-us/library/windows/desktop/
bb530718.aspx>.
Acknowledgments
Thanks to Markus Friedl and Damien Miller for comments and initial
implementation. Thanks to Peter Gutmann, Roumen Petrov, Mark D.
Baushke, Daniel Migault, Eric Rescorla, Matthew A. Miller, Mirja
Kuehlewind, Adam Roach, Spencer Dawkins, Alexey Melnikov, and Ben
Campbell for reviews and feedback.
Author's Address
Denis Bider
Bitvise Limited
4105 Lombardy Court
Colleyville, TX 76034
United States of America
Email: ietf-ssh3@denisbider.com
URI: https://www.bitvise.com/
Bider Standards Track [Page 14]

507
specifications/rfc8332.txt Normal file
View File

@@ -0,0 +1,507 @@
Internet Engineering Task Force (IETF) D. Bider
Request for Comments: 8332 Bitvise Limited
Updates: 4252, 4253 March 2018
Category: Standards Track
ISSN: 2070-1721
Use of RSA Keys with SHA-256 and SHA-512
in the Secure Shell (SSH) Protocol
Abstract
This memo updates RFCs 4252 and 4253 to define new public key
algorithms for use of RSA keys with SHA-256 and SHA-512 for server
and client authentication in SSH connections.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8332.
Bider Standards Track [Page 1]
RFC 8332 Use of RSA Keys with SHA-256 and SHA-512 March 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
1.2. Wire Encoding Terminology . . . . . . . . . . . . . . . . 3
2. Public Key Format vs. Public Key Algorithm . . . . . . . . . 3
3. New RSA Public Key Algorithms . . . . . . . . . . . . . . . . 4
3.1. Use for Server Authentication . . . . . . . . . . . . . . 5
3.2. Use for Client Authentication . . . . . . . . . . . . . . 5
3.3. Discovery of Public Key Algorithms Supported by Servers . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5.1. Key Size and Signature Hash . . . . . . . . . . . . . . . 7
5.2. Transition . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. PKCS #1 v1.5 Padding and Signature Verification . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
Bider Standards Track [Page 2]
RFC 8332 Use of RSA Keys with SHA-256 and SHA-512 March 2018
1. Overview and Rationale
Secure Shell (SSH) is a common protocol for secure communication on
the Internet. In [RFC4253], SSH originally defined the public key
algorithms "ssh-rsa" for server and client authentication using RSA
with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. These
algorithms are now considered deficient. For US government use, NIST
has disallowed 1024-bit RSA and DSA, and use of SHA-1 for signing
[NIST.800-131A].
This memo updates RFCs 4252 and 4253 to define new public key
algorithms allowing for interoperable use of existing and new RSA
keys with SHA-256 and SHA-512.
1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Wire Encoding Terminology
The wire encoding types in this document -- "boolean", "byte",
"string", "mpint" -- have meanings as described in [RFC4251].
2. Public Key Format vs. Public Key Algorithm
In [RFC4252], the concept "public key algorithm" is used to establish
a relationship between one algorithm name, and:
A. procedures used to generate and validate a private/public
keypair;
B. a format used to encode a public key; and
C. procedures used to calculate, encode, and verify a signature.
This document uses the term "public key format" to identify only A
and B in isolation. The term "public key algorithm" continues to
identify all three aspects -- A, B, and C.
Bider Standards Track [Page 3]
RFC 8332 Use of RSA Keys with SHA-256 and SHA-512 March 2018
3. New RSA Public Key Algorithms
This memo adopts the style and conventions of [RFC4253] in specifying
how use of a public key algorithm is indicated in SSH.
The following new public key algorithms are defined:
rsa-sha2-256 RECOMMENDED sign Raw RSA key
rsa-sha2-512 OPTIONAL sign Raw RSA key
These algorithms are suitable for use both in the SSH transport layer
[RFC4253] for server authentication and in the authentication layer
[RFC4252] for client authentication.
Since RSA keys are not dependent on the choice of hash function, the
new public key algorithms reuse the "ssh-rsa" public key format as
defined in [RFC4253]:
string "ssh-rsa"
mpint e
mpint n
All aspects of the "ssh-rsa" format are kept, including the encoded
string "ssh-rsa". This allows existing RSA keys to be used with the
new public key algorithms, without requiring re-encoding or affecting
already trusted key fingerprints.
Signing and verifying using these algorithms is performed according
to the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as
hash.
For the algorithm "rsa-sha2-256", the hash used is SHA-256.
For the algorithm "rsa-sha2-512", the hash used is SHA-512.
The resulting signature is encoded as follows:
string "rsa-sha2-256" / "rsa-sha2-512"
string rsa_signature_blob
The value for 'rsa_signature_blob' is encoded as a string that
contains an octet string S (which is the output of RSASSA-PKCS1-v1_5)
and that has the same length (in octets) as the RSA modulus. When S
contains leading zeros, there exist signers that will send a shorter
encoding of S that omits them. A verifier MAY accept shorter
encodings of S with one or more leading zeros omitted.
Bider Standards Track [Page 4]
RFC 8332 Use of RSA Keys with SHA-256 and SHA-512 March 2018
3.1. Use for Server Authentication
To express support and preference for one or both of these algorithms
for server authentication, the SSH client or server includes one or
both algorithm names, "rsa-sha2-256" and/or "rsa-sha2-512", in the
name-list field "server_host_key_algorithms" in the SSH_MSG_KEXINIT
packet [RFC4253]. If one of the two host key algorithms is
negotiated, the server sends an "ssh-rsa" public key as part of the
negotiated key exchange method (e.g., in SSH_MSG_KEXDH_REPLY) and
encodes a signature with the appropriate signature algorithm name --
either "rsa-sha2-256" or "rsa-sha2-512".
3.2. Use for Client Authentication
To use this algorithm for client authentication, the SSH client sends
an SSH_MSG_USERAUTH_REQUEST message [RFC4252] encoding the
"publickey" method and encoding the string field "public key
algorithm name" with the value "rsa-sha2-256" or "rsa-sha2-512". The
"public key blob" field encodes the RSA public key using the
"ssh-rsa" public key format.
For example, as defined in [RFC4252] and [RFC4253], an SSH
"publickey" authentication request using an "rsa-sha2-512" signature
would be properly encoded as follows:
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string "rsa-sha2-512"
string public key blob:
string "ssh-rsa"
mpint e
mpint n
string signature:
string "rsa-sha2-512"
string rsa_signature_blob
If the client includes the signature field, the client MUST encode
the same algorithm name in the signature as in
SSH_MSG_USERAUTH_REQUEST -- either "rsa-sha2-256" or "rsa-sha2-512".
If a server receives a mismatching request, it MAY apply arbitrary
authentication penalties, including but not limited to authentication
failure or disconnect.
Bider Standards Track [Page 5]
RFC 8332 Use of RSA Keys with SHA-256 and SHA-512 March 2018
OpenSSH 7.2 (but not 7.2p2) incorrectly encodes the algorithm in the
signature as "ssh-rsa" when the algorithm in SSH_MSG_USERAUTH_REQUEST
is "rsa-sha2-256" or "rsa-sha2-512". In this case, the signature
does actually use either SHA-256 or SHA-512. A server MAY, but is
not required to, accept this variant or another variant that
corresponds to a good-faith implementation and is considered safe to
accept.
3.3. Discovery of Public Key Algorithms Supported by Servers
Implementation experience has shown that there are servers that apply
authentication penalties to clients attempting public key algorithms
that the SSH server does not support.
Servers that accept rsa-sha2-* signatures for client authentication
SHOULD implement the extension negotiation mechanism defined in
[RFC8308], including especially the "server-sig-algs" extension.
When authenticating with an RSA key against a server that does not
implement the "server-sig-algs" extension, clients MAY default to an
"ssh-rsa" signature to avoid authentication penalties. When the new
rsa-sha2-* algorithms have been sufficiently widely adopted to
warrant disabling "ssh-rsa", clients MAY default to one of the new
algorithms.
4. IANA Considerations
IANA has updated the "Secure Shell (SSH) Protocol Parameters"
registry, established with [RFC4250], to extend the table "Public Key
Algorithm Names" [IANA-PKA] as follows.
- To the immediate right of the column "Public Key Algorithm Name",
a new column has been added, titled "Public Key Format". For
existing entries, the column "Public Key Format" has been assigned
the same value as under "Public Key Algorithm Name".
- Immediately following the existing entry for "ssh-rsa", two
sibling entries have been added:
P. K. Alg. Name P. K. Format Reference Note
rsa-sha2-256 ssh-rsa RFC 8332 Section 3
rsa-sha2-512 ssh-rsa RFC 8332 Section 3
Bider Standards Track [Page 6]
RFC 8332 Use of RSA Keys with SHA-256 and SHA-512 March 2018
5. Security Considerations
The security considerations of [RFC4251] apply to this document.
5.1. Key Size and Signature Hash
The National Institute of Standards and Technology (NIST) Special
Publication 800-131A, Revision 1 [NIST.800-131A] disallows RSA and
DSA keys shorter than 2048 bits for US government use. The same
document disallows the SHA-1 hash function for digital signature
generation, except under NIST's protocol-specific guidance.
It is prudent to follow this advice also outside of US government
use.
5.2. Transition
This document is based on the premise that RSA is used in
environments where a gradual, compatible transition to improved
algorithms will be better received than one that is abrupt and
incompatible. It advises that SSH implementations add support for
new RSA public key algorithms along with SSH_MSG_EXT_INFO and the
"server-sig-algs" extension to allow coexistence of new deployments
with older versions that support only "ssh-rsa". Nevertheless,
implementations SHOULD start to disable "ssh-rsa" in their default
configurations as soon as the implementers believe that new RSA
signature algorithms have been widely adopted.
5.3. PKCS #1 v1.5 Padding and Signature Verification
This document prescribes RSASSA-PKCS1-v1_5 signature padding because:
(1) RSASSA-PSS is not universally available to all implementations;
(2) PKCS #1 v1.5 is widely supported in existing SSH
implementations;
(3) PKCS #1 v1.5 is not known to be insecure for use in this scheme.
Implementers are advised that a signature with RSASSA-PKCS1-v1_5
padding MUST NOT be verified by applying the RSA key to the
signature, and then parsing the output to extract the hash. This may
give an attacker opportunities to exploit flaws in the parsing and
vary the encoding. Verifiers MUST instead apply RSASSA-PKCS1-v1_5
padding to the expected hash, then compare the encoded bytes with the
output of the RSA operation.
Bider Standards Track [Page 7]
RFC 8332 Use of RSA Keys with SHA-256 and SHA-512 March 2018
6. References
6.1. Normative References
[SHS] NIST, "Secure Hash Standard (SHS)", FIPS Publication
180-4, August 2015,
<http://dx.doi.org/10.6028/NIST.FIPS.180-4>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell
(SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
2018, <https://www.rfc-editor.org/info/rfc8308>.
6.2. Informative References
[NIST.800-131A]
NIST, "Transitions: Recommendation for Transitioning the
Use of Cryptographic Algorithms and Key Lengths", NIST
Special Publication 800-131A, Revision 1,
DOI 10.6028/NIST.SP.800-131Ar1, November 2015,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-131Ar1.pdf>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006,
<https://www.rfc-editor.org/info/rfc4250>.
Bider Standards Track [Page 8]
RFC 8332 Use of RSA Keys with SHA-256 and SHA-512 March 2018
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[IANA-PKA]
IANA, "Secure Shell (SSH) Protocol Parameters",
<https://www.iana.org/assignments/ssh-parameters/>.
Acknowledgments
Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D.
Baushke, Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien
Miller, Mat Berchtold, Roumen Petrov, Daniel Migault, Eric Rescorla,
Russ Housley, Alissa Cooper, Adam Roach, and Ben Campbell for
reviews, comments, and suggestions.
Author's Address
Denis Bider
Bitvise Limited
4105 Lombardy Court
Colleyville, Texas 76034
United States of America
Email: ietf-ssh3@denisbider.com
URI: https://www.bitvise.com/
Bider Standards Track [Page 9]

317
specifications/rfc8709.txt Normal file
View File

@@ -0,0 +1,317 @@
Internet Engineering Task Force (IETF) B. Harris
Request for Comments: 8709
Updates: 4253 L. Velvindron
Category: Standards Track cyberstorm.mu
ISSN: 2070-1721 February 2020
Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH)
Protocol
Abstract
This document describes the use of the Ed25519 and Ed448 digital
signature algorithms in the Secure Shell (SSH) protocol.
Accordingly, this RFC updates RFC 4253.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8709.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
2. Conventions Used in This Document
2.1. Requirements Language
3. Public Key Algorithm
4. Public Key Format
5. Signature Algorithm
6. Signature Format
7. Verification Algorithm
8. SSHFP DNS Resource Records
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses
1. Introduction
Secure Shell (SSH) [RFC4251] is a secure remote-login protocol. It
provides for an extensible variety of public key algorithms for
identifying servers and users to one another. Ed25519 [RFC8032] is a
digital signature system. OpenSSH 6.5 [OpenSSH-6.5] introduced
support for using Ed25519 for server and user authentication and was
then followed by other SSH implementations.
This document describes the method implemented by OpenSSH and others
and formalizes the use of the name "ssh-ed25519". Additionally, this
document describes the use of Ed448 and formalizes the use of the
name "ssh-ed448".
2. Conventions Used in This Document
The descriptions of key and signature formats use the notation
introduced in [RFC4251], Section 3 and the string data type from
[RFC4251], Section 5.
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Public Key Algorithm
This document describes a public key algorithm for use with SSH, as
per [RFC4253], Section 6.6. The name of the algorithm is "ssh-
ed25519". This algorithm only supports signing and not encryption.
Additionally, this document describes another public key algorithm.
The name of the algorithm is "ssh-ed448". This algorithm only
supports signing and not encryption.
Standard implementations of SSH SHOULD implement these signature
algorithms.
4. Public Key Format
The "ssh-ed25519" key format has the following encoding:
string "ssh-ed25519"
string key
Here, 'key' is the 32-octet public key described in [RFC8032],
Section 5.1.5.
The "ssh-ed448" key format has the following encoding:
string "ssh-ed448"
string key
Here, 'key' is the 57-octet public key described in [RFC8032],
Section 5.2.5.
5. Signature Algorithm
Signatures are generated according to the procedure in Sections 5.1.6
and 5.2.6 of [RFC8032].
6. Signature Format
The "ssh-ed25519" key format has the following encoding:
string "ssh-ed25519"
string signature
Here, 'signature' is the 64-octet signature produced in accordance
with [RFC8032], Section 5.1.6.
The "ssh-ed448" key format has the following encoding:
string "ssh-ed448"
string signature
Here, 'signature' is the 114-octet signature produced in accordance
with [RFC8032], Section 5.2.6.
7. Verification Algorithm
Ed25519 signatures are verified according to the procedure in
[RFC8032], Section 5.1.7.
Ed448 signatures are verified according to the procedure in
[RFC8032], Section 5.2.7.
8. SSHFP DNS Resource Records
Usage and generation of the SSHFP DNS resource record is described in
[RFC4255]. The generation of SSHFP resource records for "ssh-
ed25519" keys is described in [RFC7479]. This section illustrates
the generation of SSHFP resource records for "ssh-ed448" keys, and
this document also specifies the corresponding Ed448 code point to
"SSHFP RR Types for public key algorithms" in the "DNS SSHFP Resource
Record Parameters" IANA registry [IANA-SSHFP].
The generation of SSHFP resource records for "ssh-ed448" keys is
described as follows.
The encoding of Ed448 public keys is described in [ED448]. In brief,
an Ed448 public key is a 57-octet value representing a 455-bit
y-coordinate of an elliptic curve point, and a sign bit indicating
the corresponding x-coordinate.
The SSHFP Resource Record for the Ed448 public key with SHA-256
fingerprint would, for example, be:
example.com. IN SSHFP 6 2 ( a87f1b687ac0e57d2a081a2f2826723
34d90ed316d2b818ca9580ea384d924
01 )
The '2' here indicates SHA-256 [RFC6594].
9. IANA Considerations
This document augments the Public Key Algorithm Names in [RFC4250],
Section 4.11.3.
IANA has added the following entry to "Public Key Algorithm Names" in
the "Secure Shell (SSH) Protocol Parameters" registry [IANA-SSH]:
+---------------------------+-----------+
| Public Key Algorithm Name | Reference |
+===========================+===========+
| ssh-ed25519 | RFC 8709 |
+---------------------------+-----------+
| ssh-ed448 | RFC 8709 |
+---------------------------+-----------+
Table 1
IANA has added the following entry to "SSHFP RR Types for public key
algorithms" in the "DNS SSHFP Resource Record Parameters" registry
[IANA-SSHFP]:
+-------+-------------+-----------+
| Value | Description | Reference |
+=======+=============+===========+
| 6 | Ed448 | RFC 8709 |
+-------+-------------+-----------+
Table 2
10. Security Considerations
The security considerations in [RFC4251], Section 9 apply to all SSH
implementations, including those using Ed25519 and Ed448.
The security considerations in [RFC8032], Section 8 and [RFC7479],
Section 3 apply to all uses of Ed25519 and Ed448, including those in
SSH.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006,
<https://www.rfc-editor.org/info/rfc4250>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
DOI 10.17487/RFC4255, January 2006,
<https://www.rfc-editor.org/info/rfc4255>.
[RFC6594] Sury, O., "Use of the SHA-256 Algorithm with RSA, Digital
Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA)
in SSHFP Resource Records", RFC 6594,
DOI 10.17487/RFC6594, April 2012,
<https://www.rfc-editor.org/info/rfc6594>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
[ED448] Hamburg, M., "Ed448-Goldilocks, a new elliptic curve",
January 2015, <https://eprint.iacr.org/2015/625.pdf>.
[IANA-SSH] IANA, "Secure Shell (SSH) Protocol Parameters",
<https://www.iana.org/assignments/ssh-parameters>.
[IANA-SSHFP]
IANA, "DNS SSHFP Resource Record Parameters",
<https://www.iana.org/assignments/dns-sshfp-rr-
parameters>.
[OpenSSH-6.5]
Friedl, M., Provos, N., de Raadt, T., Steves, K., Miller,
D., Tucker, D., McIntyre, J., Rice, T., and B. Lindstrom,
"OpenSSH 6.5 release notes", January 2014,
<http://www.openssh.com/txt/release-6.5>.
[RFC7479] Moonesamy, S., "Using Ed25519 in SSHFP Resource Records",
RFC 7479, DOI 10.17487/RFC7479, March 2015,
<https://www.rfc-editor.org/info/rfc7479>.
Acknowledgements
The OpenSSH implementation of Ed25519 in SSH was written by Markus
Friedl. We are also grateful to Mark Baushke, Benjamin Kaduk, and
Daniel Migault for their comments.
Authors' Addresses
Ben Harris
2A Eachard Road
Cambridge
CB3 0HY
United Kingdom
Email: bjh21@bjh21.me.uk
Loganaden Velvindron
cyberstorm.mu
88, Avenue De Plevitz
Roches Brunes
Mauritius
Email: logan@cyberstorm.mu

196
specifications/rfc8758.txt Normal file
View File

@@ -0,0 +1,196 @@
Internet Engineering Task Force (IETF) L. Velvindron
Request for Comments: 8758 cyberstorm.mu
BCP: 227 April 2020
Updates: 4253
Category: Best Current Practice
ISSN: 2070-1721
Deprecating RC4 in Secure Shell (SSH)
Abstract
This document deprecates RC4 in Secure Shell (SSH). Therefore, this
document formally moves RFC 4345 to Historic status.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8758.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
1.1. Requirements Language
2. Updates to RFC 4253
3. IANA Considerations
4. Security Considerations
5. References
5.1. Normative References
5.2. Informative References
Acknowledgements
Author's Address
1. Introduction
The usage of RC4 suites (also designated as "arcfour") for SSH is
specified in [RFC4253] and [RFC4345]. [RFC4253] specifies the
allocation of the "arcfour" cipher for SSH. [RFC4345] specifies and
allocates the "arcfour128" and "arcfour256" ciphers for SSH. RC4
encryption has known weaknesses [RFC7465] [RFC8429]; therefore, this
document starts the deprecation process for their use in Secure Shell
(SSH) [RFC4253]. Accordingly, [RFC4253] is updated to note the
deprecation of the RC4 ciphers, and [RFC4345] is moved to Historic
status, as all ciphers it specifies MUST NOT be used.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Updates to RFC 4253
[RFC4253] is updated to prohibit arcfour's use in SSH. [RFC4253],
Section 6.3 allocates the "arcfour" cipher by defining a list of
defined ciphers in which the "arcfour" cipher appears as optional, as
shown in Table 1.
+---------+----------+----------------------------------------------+
| arcfour | OPTIONAL | the ARCFOUR stream cipher |
| | | with a 128-bit key |
+---------+----------+----------------------------------------------+
Table 1
This document updates the status of the "arcfour" ciphers in the list
found in [RFC4253], Section 6.3 by moving it from OPTIONAL to MUST
NOT.
+---------+----------+----------------------------------------------+
| arcfour | MUST NOT | the ARCFOUR stream cipher |
| | | with a 128-bit key |
+---------+----------+----------------------------------------------+
Table 2
[RFC4253] defines the "arcfour" ciphers with the following text:
| The "arcfour" cipher is the Arcfour stream cipher with 128-bit
| keys. The Arcfour cipher is believed to be compatible with the
| RC4 cipher [SCHNEIER]. Arcfour (and RC4) has problems with weak
| keys, and should be used with caution.
This document updates [RFC4253], Section 6.3 by replacing the text
above with the following text:
| The "arcfour" cipher is the Arcfour stream cipher with 128-bit
| keys. The Arcfour cipher is compatible with the RC4 cipher
| [SCHNEIER]. Arcfour (and RC4) has known weaknesses [RFC7465]
| [RFC8429] and MUST NOT be used.
3. IANA Considerations
The IANA has updated the "Encryption Algorithm Names" subregistry in
the "Secure Shell (SSH) Protocol Parameters" registry [IANA]. The
registration procedure is IETF review, which is achieved by this
document. The registry has been updated as follows:
+---------------------------+-----------+----------+
| Encryption Algorithm Name | Reference | Note |
+===========================+===========+==========+
| arcfour | RFC 8758 | HISTORIC |
+---------------------------+-----------+----------+
| arcfour128 | RFC 8758 | HISTORIC |
+---------------------------+-----------+----------+
| arcfour256 | RFC 8758 | HISTORIC |
+---------------------------+-----------+----------+
Table 3
4. Security Considerations
This document only prohibits the use of RC4 in SSH; it introduces no
new security considerations.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
5.2. Informative References
[IANA] "Secure Shell (SSH) Protocol Parameters",
<https://www.iana.org/assignments/ssh-parameters>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4345] Harris, B., "Improved Arcfour Modes for the Secure Shell
(SSH) Transport Layer Protocol", RFC 4345,
DOI 10.17487/RFC4345, January 2006,
<https://www.rfc-editor.org/info/rfc4345>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
DOI 10.17487/RFC7465, February 2015,
<https://www.rfc-editor.org/info/rfc7465>.
[RFC8429] Kaduk, B. and M. Short, "Deprecate Triple-DES (3DES) and
RC4 in Kerberos", BCP 218, RFC 8429, DOI 10.17487/RFC8429,
October 2018, <https://www.rfc-editor.org/info/rfc8429>.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
Protocols, Algorithms, and Source in Code in C", John
Wiley and Sons New York, NY, 1996.
Acknowledgements
The author would like to thank Eric Rescorla, Daniel Migault, and
Rich Salz.
Author's Address
Loganaden Velvindron
cyberstorm.mu
Mauritius
Email: logan@cyberstorm.mu

1028
specifications/rfc9142.txt Normal file
View File

File diff suppressed because it is too large Load Diff

272
specifications/rfc9519.txt Normal file
View File

@@ -0,0 +1,272 @@
Internet Engineering Task Force (IETF) P. Yee
Request for Comments: 9519 AKAYLA
Updates: 4250, 4716, 4819, 8308 January 2024
Category: Standards Track
ISSN: 2070-1721
Update to the IANA SSH Protocol Parameters Registry Requirements
Abstract
This specification updates the registration policies for adding new
entries to registries within the IANA "Secure Shell (SSH) Protocol
Parameters" group of registries. Previously, the registration policy
was generally IETF Review, as defined in RFC 8126, although a few
registries require Standards Action. This specification changes it
from IETF Review to Expert Review. This document updates RFCs 4250,
4716, 4819, and 8308.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9519.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
1.1. Requirements Language
2. SSH Protocol Parameters Affected
3. Designated Expert Pool
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Author's Address
1. Introduction
The IANA "Secure Shell (SSH) Protocol Parameters" registry was
populated by several RFCs including [RFC4250], [RFC4716], [RFC4819],
and [RFC8308]. Outside of some narrow value ranges that require
Standards Action in order to add new values or that are marked for
Private Use, the registration policy for other portions of the
registry was IETF Review [RFC8126]. This specification changes the
policy from IETF Review to Expert Review. This change is in line
with similar changes undertaken for certain IPsec and TLS registries.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. SSH Protocol Parameters Affected
The following table lists the "Secure Shell (SSH) Protocol
Parameters" registries whose registration policy has changed from
IETF Review to Expert Review. Where this change applied to a
specific range of values within the particular parameter, that range
is given in the notes column. Affected registries now list this
document as a reference.
+===============================+===========+=======================+
| Parameter Name | RFC | Notes |
+===============================+===========+=======================+
| Authentication Method | [RFC4250] | |
| Names | | |
+-------------------------------+-----------+-----------------------+
| Channel Connection | [RFC4250] | 0x00000001-0xFDFFFFFF |
| Failure Reason Codes | | (inclusive) |
| and Descriptions | | |
+-------------------------------+-----------+-----------------------+
| Compression Algorithm | [RFC4250] | |
| Names | | |
+-------------------------------+-----------+-----------------------+
| Connection Protocol | [RFC4250] | |
| Channel Request Names | | |
+-------------------------------+-----------+-----------------------+
| Connection Protocol | [RFC4250] | |
| Channel Types | | |
+-------------------------------+-----------+-----------------------+
| Connection Protocol | [RFC4250] | |
| Global Request Names | | |
+-------------------------------+-----------+-----------------------+
| Connection Protocol | [RFC4250] | |
| Subsystem Names | | |
+-------------------------------+-----------+-----------------------+
| Disconnection Messages | [RFC4250] | 0x00000001-0xFDFFFFFF |
| Reason Codes and | | (inclusive) |
| Descriptions | | |
+-------------------------------+-----------+-----------------------+
| Encryption Algorithm | [RFC4250] | |
| Names | | |
+-------------------------------+-----------+-----------------------+
| Extended Channel Data | [RFC4250] | 0x00000001-0xFDFFFFFF |
| Transfer data_type_code | | (inclusive) |
| and Data | | |
+-------------------------------+-----------+-----------------------+
| Extension Names | [RFC8308] | |
+-------------------------------+-----------+-----------------------+
| Key Exchange Method | [RFC4250] | |
| Names | | |
+-------------------------------+-----------+-----------------------+
| MAC Algorithm Names | [RFC4250] | |
+-------------------------------+-----------+-----------------------+
| Pseudo-Terminal Encoded | [RFC4250] | |
| Terminal Modes | | |
+-------------------------------+-----------+-----------------------+
| Public Key Algorithm | [RFC4250] | |
| Names | | |
+-------------------------------+-----------+-----------------------+
| Publickey Subsystem | [RFC4819] | |
| Attributes | | |
+-------------------------------+-----------+-----------------------+
| Publickey Subsystem | [RFC4819] | |
| Request Names | | |
+-------------------------------+-----------+-----------------------+
| Publickey Subsystem | [RFC4819] | |
| Response Names | | |
+-------------------------------+-----------+-----------------------+
| Service Names | [RFC4250] | |
+-------------------------------+-----------+-----------------------+
| Signal Names | [RFC4250] | |
+-------------------------------+-----------+-----------------------+
| SSH Public-Key File | [RFC4716] | Excluding header-tags |
| Header Tags | | beginning with x- |
+-------------------------------+-----------+-----------------------+
Table 1: Secure Shell (SSH) Protocol Parameters Affected
The only IANA SSH protocol parameter registries not affected are
"Message Numbers" and "Publickey Subsystem Status Codes", as these
remain Standards Action due to their limited resources as one-byte
registry values.
3. Designated Expert Pool
Expert Review [RFC8126] registry requests are registered after a
three-week review period on the <ssh-reg-review@ietf.org> mailing
list, and on the advice of one or more designated experts. However,
to allow for the allocation of values prior to publication, the
designated experts may approve registration once they are satisfied
that such a specification will be published.
Registration requests sent to the mailing list for review SHOULD use
an appropriate subject (e.g., "Request to register value in SSH
protocol parameters <specific parameter> registry").
Within the review period, the designated experts will either approve
or deny the registration request, communicating this decision to the
review list and IANA. Denials MUST include an explanation and, if
applicable, suggestions as to how to make the request successful.
Registration requests that are undetermined for a period longer than
21 days can be brought to the IESG's attention (using the
<iesg@ietf.org> mailing list) for resolution.
Criteria that SHOULD be applied by the designated experts includes
determining whether the proposed registration duplicates existing
functionality (which is not permitted), whether it is likely to be of
general applicability or useful only for a single application, and
whether the registration description is clear.
IANA MUST only accept registry updates from the designated experts
and the IESG. It SHOULD direct all requests for registration from
other sources to the review mailing list.
It is suggested that multiple designated experts be appointed who are
able to represent the perspectives of different applications using
this specification, in order to enable broadly informed review of
registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular
expert, that expert SHOULD defer to the judgment of the other
experts.
4. IANA Considerations
This memo is entirely about updating the IANA "Secure Shell (SSH)
Protocol Parameters" registry.
5. Security Considerations
This memo does not change the Security Considerations for any of the
updated RFCs.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006,
<https://www.rfc-editor.org/info/rfc4250>.
[RFC4819] Galbraith, J., Van Dyke, J., and J. Bright, "Secure Shell
Public Key Subsystem", RFC 4819, DOI 10.17487/RFC4819,
March 2007, <https://www.rfc-editor.org/info/rfc4819>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell
(SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
2018, <https://www.rfc-editor.org/info/rfc8308>.
6.2. Informative References
[CURDLE-MA]
Turner, S., "Subject: [Curdle] Time to Review IANA SSH
Registries Policies?", message to the Curdle mailing list,
February 2021,
<https://mailarchive.ietf.org/arch/msg/curdle/
gdiOlZr9bnrZv8umVyguGG3woIM/>.
[RFC4716] Galbraith, J. and R. Thayer, "The Secure Shell (SSH)
Public Key File Format", RFC 4716, DOI 10.17487/RFC4716,
November 2006, <https://www.rfc-editor.org/info/rfc4716>.
Acknowledgements
The impetus for this specification was a February 2021 discussion on
the CURDLE mailing list [CURDLE-MA].
Author's Address
Peter E. Yee
AKAYLA
Mountain View, CA 94043
United States of America
Email: peter@akayla.com