Skip to main content

Extension Negotiation in the Secure Shell (SSH) Protocol
RFC 8308

Revision differences

Document history

Date Rev. By Action
2018-03-22
15 (System) IANA registries were updated to include RFC8308
2018-03-19
15 (System)
Received changes through RFC Editor sync (created alias RFC 8308, changed title to 'Extension Negotiation in the Secure Shell (SSH) Protocol', changed abstract to …
Received changes through RFC Editor sync (created alias RFC 8308, changed title to 'Extension Negotiation in the Secure Shell (SSH) Protocol', changed abstract to '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.', changed pages to 14, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-03-19, changed IESG state to RFC Published, created updates relation between draft-ietf-curdle-ssh-ext-info and RFC 4251, created updates relation between draft-ietf-curdle-ssh-ext-info and RFC 4252, created updates relation between draft-ietf-curdle-ssh-ext-info and RFC 4253, created updates relation between draft-ietf-curdle-ssh-ext-info and RFC 4254)
2018-03-19
15 (System) RFC published
2018-02-22
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-12-21
15 (System) RFC Editor state changed to AUTH48 from EDIT
2017-11-20
15 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2017-11-19
15 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2017-11-19
15 (System) IANA Action state changed to In Progress from Waiting on Authors
2017-11-14
15 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-11-13
15 (System) RFC Editor state changed to EDIT
2017-11-13
15 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-11-13
15 (System) Announcement was received by RFC Editor
2017-11-12
15 (System) IANA Action state changed to In Progress
2017-11-12
15 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-11-12
15 Cindy Morgan IESG has approved the document
2017-11-12
15 Cindy Morgan Closed "Approve" ballot
2017-09-25
15 Cindy Morgan Ballot approval text was generated
2017-09-23
15 denis bider New version available: draft-ietf-curdle-ssh-ext-info-15.txt
2017-09-23
15 (System) New version approved
2017-09-23
15 (System) Request for posting confirmation emailed to previous authors: denis bider
2017-09-23
15 denis bider Uploaded new revision
2017-09-23
14 Eric Rescorla IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2017-09-23
14 Eric Rescorla IESG state changed to IESG Evaluation::AD Followup from Approved-announcement to be sent
2017-09-23
14 Eric Rescorla IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2017-09-23
14 Eric Rescorla Ballot writeup was changed
2017-09-14
14 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2017-09-14
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-09-14
14 denis bider New version available: draft-ietf-curdle-ssh-ext-info-14.txt
2017-09-14
14 (System) New version approved
2017-09-14
14 (System) Request for posting confirmation emailed to previous authors: denis bider
2017-09-14
14 denis bider Uploaded new revision
2017-09-14
13 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2017-09-14
13 Michelle Cotton IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2017-09-14
13 Alexey Melnikov [Ballot comment]
Thank you for addressing my DISCUSS and comments.
2017-09-14
13 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss
2017-09-14
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-09-14
13 denis bider New version available: draft-ietf-curdle-ssh-ext-info-13.txt
2017-09-14
13 (System) New version approved
2017-09-14
13 (System) Request for posting confirmation emailed to previous authors: denis bider
2017-09-14
13 denis bider Uploaded new revision
2017-09-13
12 Ben Campbell
[Ballot comment]
Thanks for addressing my DISCUSS point. I've cleared, with the assumption the discussed change will make it into the final document.

(I leave …
[Ballot comment]
Thanks for addressing my DISCUSS point. I've cleared, with the assumption the discussed change will make it into the final document.

(I leave the non-blocking comments below for reference, although most of them have been addressed in the email discussion.)

Substantive:

-2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, without delay."
That seems to be contradicted in section 2.4, which talks about two other potential times.

-2.4, last paragraph (asterisk note): "The message MUST be sent at this point for the following reasons:"
That's a confusing use of MUST. Do you mean that the message MUST NOT be sent unless the reasons are true? Or that if the reasons are true, the message MUST be sent? Or is this just a statement of fact, in which case the 2119 keyword is not appropriate?

-2.5, 2nd paragraph: "or it MAY be sufficient that only one party includes it"
That seems like a statement of fact rather than a grant of permission. If so, the 2119 MAY is not appropriate.

Editorial:

-2.1, first paragraph: "Applications implementing this mechanism MUST add to the field
  "kex_algorithms", in their KEXINIT packet sent for the first key
  exchange, one of the following indicator names:"

That's hard to parse.  Suggestion:
"Applications implementing this mechanism MUST add one of the
following indicator names to the "kex_algorithms" field for the first
key exchange:"

-2.5, 2nd to last paragraph: "... applications MUST
  tolerate any sequence of bytes; including null bytes at any position;
  in an unknown extension’s extension-value."

Redundant to similar normative statement in 2.3.
2017-09-13
12 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to Yes from Discuss
2017-09-13
12 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2017-09-13
12 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-09-13
12 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2017-09-13
12 Kathleen Moriarty
[Ballot comment]
I agree with the SecDir reviewer that it would be helpful to state that the extension negotiation between the client and server is …
[Ballot comment]
I agree with the SecDir reviewer that it would be helpful to state that the extension negotiation between the client and server is performed after key exchange with confidentiality in the security considerations section.
2017-09-13
12 Kathleen Moriarty [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty
2017-09-13
12 Ben Campbell
[Ballot discuss]
I plan to ballot "yes", but I want to discuss one point first. Alexey mentioned this in his comments, but I think it's …
[Ballot discuss]
I plan to ballot "yes", but I want to discuss one point first. Alexey mentioned this in his comments, but I think it's discuss worthy. Hopefully it's an easy fix, and it may well be because I've missed something obvious. If people think it really, really needs to be this way, I will clear--but I want to discuss it first:

- 2.5: The relative order in which extensions appear in an
  EXT_INFO message MUST be ignored by default; but an extension MAY
  specify that the order matters for that extension, in a specific way.

I don't think allowing specific extensions to add ordering requirement works. It opens up the possibility of incompatible ordering requirements across extensions. As far as I can tell, the only control over this is the "IETF Consensus" requirement for adding new extensions. I'm open to arguments that this is good enough, but my knee-jerk response is that it puts an undue burden on the consensus process for little return.
2017-09-13
12 Ben Campbell
[Ballot comment]
Substantive:

-2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, without delay."
That seems to be contradicted in section 2.4, which talks about two …
[Ballot comment]
Substantive:

-2.3: "This message is sent immediately after SSH_MSG_NEWKEYS, without delay."
That seems to be contradicted in section 2.4, which talks about two other potential times.

-2.4, last paragraph (asterisk note): "The message MUST be sent at this point for the following reasons:"
That's a confusing use of MUST. Do you mean that the message MUST NOT be sent unless the reasons are true? Or that if the reasons are true, the message MUST be sent? Or is this just a statement of fact, in which case the 2119 keyword is not appropriate?

-2.5, 2nd paragraph: "or it MAY be sufficient that only one party includes it"
That seems like a statement of fact rather than a grant of permission. If so, the 2119 MAY is not appropriate.

Editorial:

-2.1, first paragraph: "Applications implementing this mechanism MUST add to the field
  "kex_algorithms", in their KEXINIT packet sent for the first key
  exchange, one of the following indicator names:"

That's hard to parse.  Suggestion:
"Applications implementing this mechanism MUST add one of the
following indicator names to the "kex_algorithms" field for the first
key exchange:"

-2.5, 2nd to last paragraph: "... applications MUST
  tolerate any sequence of bytes; including null bytes at any position;
  in an unknown extension’s extension-value."

Redundant to similar normative statement in 2.3.
2017-09-13
12 Ben Campbell [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell
2017-09-13
12 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2017-09-13
12 Alexey Melnikov
[Ballot discuss]
This is generally a good and useful document. I have some minor comments I would like to discuss:

3.2.  "delay-compression"

  This extension …
[Ballot discuss]
This is generally a good and useful document. I have some minor comments I would like to discuss:

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

It is not clear for me from the formatting whether the first name-list is sent by the client and the second by the server, or both lists are always included in the value. I suspect it is the former, but can you please clarify?
2017-09-13
12 Alexey Melnikov
[Ballot comment]
1) Sentences like:
  Use of  Receivers MUST tolerate any sequence of bytes; including null bytes  at any position; in an unknown extension's …
[Ballot comment]
1) Sentences like:
  Use of  Receivers MUST tolerate any sequence of bytes; including null bytes  at any position; in an unknown extension's extension-value.
or
In particular, applications MUST  tolerate any sequence of bytes; including null bytes at any position;  in an unknown extension's extension-value.

Use of punctuation is not my strongest point, but I am reasonably certain that use of ";" is not correct here. I think you should use (). Otherwise these sentences are reading as a list of 3 things, yet in both cases the 3rd is a continuation of the 1st.

2) In Section 2.5:

The relative order in which extensions appear in an
  EXT_INFO message MUST be ignored by default; but an extension MAY
  specify that the order matters for that extension, in a specific way.

Can you provide an example of why depending on order would be useful? This potentially makes it harder to implement.

In several places you use EXT_INFO instead of SSH_MSG_EXT_INFO. It would be less confusing if you used the latter consistently everywhere.

3) In 3.1:

  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.

Why would the client disconnect when seeing this extension? Does it mean it is broken?

Also, as the client can always disconnect at any point, why mentioning this here?

  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.

Can you elaborate on what do you mean by "authentication penalties" in this context?
2017-09-13
12 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov
2017-09-12
12 Adam Roach
[Ballot discuss]
I am concerned that the syntax of "delay-compression" is not specified with enough detail to ensure compatible interoperation. I may have missed something …
[Ballot discuss]
I am concerned that the syntax of "delay-compression" is not specified with enough detail to ensure compatible interoperation. I may have missed something in the protocols this document relies upon; but if I haven't, I think this needs additional specification.

The current definition for "delay-compression" is:

    string        "delay-compression"
    string:
      name-list    compression_algorithms_client_to_server
      name-list    compression_algorithms_server_to_client

In reading through this document (and skimming RFC4251), I don't see anything that indicates the on-the-wire encoding for "string containing multiple name-lists." I suspect that the intention is something like [string-length][list-length]value[list-length]value; however, that requires making a number of unstated assumptions, and I doubt that all implementors will make the same assumptions.

To be clear, what I mean by my formulation above would result in the value field of
client_to_server="foo,bar" and server_to_client="bar,baz" being encoded as:

00 00 00 16 00 00 00 07 66 6f 6f 2c 62 61 72 00 00 00 07 62 61 72 2c 62 61 7a

If this is the intention, please be explicit (and, ideally, provide an example).
2017-09-12
12 Adam Roach Ballot discuss text updated for Adam Roach
2017-09-12
12 Adam Roach
[Ballot discuss]
I am concerned that the specification of "delay-compression" is not specified with enough detail to ensure compatible interoperation. I may have missed something …
[Ballot discuss]
I am concerned that the specification of "delay-compression" is not specified with enough detail to ensure compatible interoperation. I may have missed something in the protocols this document relies upon; but if I haven't, I think this needs additional specification.

The current definition for "delay-compression" is:

    string        "delay-compression"
    string:
      name-list    compression_algorithms_client_to_server
      name-list    compression_algorithms_server_to_client

In reading through this document (and skimming RFC4251), I don't see anything that indicates the on-the-wire encoding for "string containing multiple name-lists." I suspect that the intention is something like [string-length][list-length]value[list-length]value; however, that requires making a number of unstated assumptions, and I doubt that all implementors will make the same assumptions.

To be clear, what I mean by my formulation above would result in the value field of
client_to_server="foo,bar" and server_to_client="bar,baz" being encoded as:

00 00 00 16 00 00 00 07 66 6f 6f 2c 62 61 72 00 00 00 07 62 61 72 2c 62 61 7a

If this is the intention, please be explicit (and, ideally, provide an example).
2017-09-12
12 Adam Roach
[Ballot comment]
Section 2.4:

  (*) The message MUST be sent at this point for the following reasons:

It's not clear how this normative requirement …
[Ballot comment]
Section 2.4:

  (*) The message MUST be sent at this point for the following reasons:

It's not clear how this normative requirement interacts with this MAY:

  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.

One seems to merely allow it, while the other seems to demand it. Could you add some text that clarifies this apparent contradiction?
2017-09-12
12 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2017-09-12
12 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-09-12
12 Alia Atlas
[Ballot comment]
The IESG write-up is for the wrong draft - but it was easy enough to read the detailed shepherd's report.
Thanks for a …
[Ballot comment]
The IESG write-up is for the wrong draft - but it was easy enough to read the detailed shepherd's report.
Thanks for a clear and well-written draft.
2017-09-12
12 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2017-09-12
12 Spencer Dawkins
[Ballot comment]
Thanks for a readable document. It was a pleasure to review.

I have a few comments, but "Spencer doesn't know much about SSH" …
[Ballot comment]
Thanks for a readable document. It was a pleasure to review.

I have a few comments, but "Spencer doesn't know much about SSH" might be a fine response for most of them ;-)

In this text,

  Implementations MUST NOT send an incorrect indicator name for their
  role. Implementations MAY disconnect if the counter-party 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.
 
why would a party that doen't support this extention disconnect?

I ask, because this looks like a MUST requirement that might apply to an implementation that doesn't support this extension. If that's normal SSH behavior, that's all I need to know :-)

In this text,

  If this extension takes effect, the renegotiated compression algorithm
  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 client, the trigger message is SSH_MSG_NEWCOMPRESS.

  If this extension takes effect, the client MUST send the following
  message shortly after receiving SSH_MSG_USERAUTH_SUCCESS:

    byte      SSH_MSG_NEWCOMPRESS (value 8)

  The purpose of 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 USERAUTH_SUCCESS.
 
I THINK the point is that the client's SSH_MSG_NEWCOMPRESS is sent after SSH_MSG_USERAUTH_SUCCESS, before the client sends its first SSH message that's compressed using the newly negotiated compression algorithm, but "MUST send ... shortly after receiving SSH_MSG_USERAUTH_SUCCESS" doesn't help me figure that out - I'm mostly guessing, based on "the renegotiated compression algorithm is activated for the very next SSH message after the trigger message". But (1) if I got that wrong, it's at least unclear for TSV ADs, and (2) if I got that right, I'm not understanding what "shortly after receiving" the trigger message is saying - for example, I wondered if there's a timer involved, so that if a client doesn't have messages to send, it should still send SSH_MSG_NEWCOMPRESS, or the server will think something's wrong.

In this text,

  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.

  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
  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 
 
I would find this easier to understand, if the paragraph defining the terms was the first paragraph in the section, and then the description of the extension (which uses the term "elevation") followed. It's not bad, the way it is, but the reader has to read past the description to find out what the definition means.

The security considerations are brief and refer to overarching security considerations, which I understand because this is an extension, but

  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.
 
doesn't say anything about new security considerations to think about, when you add support for elevation, which seems like it would be a new attack surface, but I could imagine that adding elevation is the first step toward fewer SSH server implementations that always run with administrative rights just in case they ever need to use them, so the attack surface is getting smaller?

... And now I see that Mirja also asked about elevation, and your answer to her was pretty much what I had guessed.  Maybe it's worth summarizing your answer in section 3.4.
2017-09-12
12 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2017-09-11
12 Warren Kumari
[Ballot comment]
I have only a very minor nit:

Section 2.3.  SSH_MSG_EXT_INFO Message
"Receivers MUST tolerate any sequence of bytes; including null bytes
  at …
[Ballot comment]
I have only a very minor nit:

Section 2.3.  SSH_MSG_EXT_INFO Message
"Receivers MUST tolerate any sequence of bytes; including null bytes
  at any position; in an unknown extension’s extension-value."
The semi-colons confused me (I'm easily confused:-)), and I think that this would read much better as a parenthetical.

Hey, I did say it was a nit :-)
W
2017-09-11
12 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2017-09-11
12 Matthew Miller Request for Telechat review by GENART Completed: Ready. Reviewer: Matthew Miller. Sent review to list.
2017-09-05
12 Mehmet Ersue Request for Telechat review by OPSDIR Completed: Has Nits. Reviewer: Mehmet Ersue. Sent review to list.
2017-09-04
12 Mirja Kühlewind
[Ballot comment]
1) What happens if the server received more than one (different) EXT_INFO messages or the client receives more than two?

2) One question …
[Ballot comment]
1) What happens if the server received more than one (different) EXT_INFO messages or the client receives more than two?

2) One question regarding flow control: I understood that some implementation simply set the max value for the initial window, however, if you don't even have a max window how do you ensure that the receiver is not over loaded and what do you do if you receive more data that you can handle?

3) I'm by far not an expert but I would have expected that there are additional security considerations for elevation and maybe even flow control... no?

4) Thanks for quickly addressing the genart review!
2017-09-04
12 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2017-09-04
12 Mirja Kühlewind
[Ballot comment]
1) What happens if the server received more than one (different) EXT_INFO messages or the client receives more than two?

2) One question …
[Ballot comment]
1) What happens if the server received more than one (different) EXT_INFO messages or the client receives more than two?

2) One question regarding flow control: I understood that some implementation simply set the max value for the initial window, however, if you don't even have a max window how do you ensure that the receiver is not over loaded and what do you do if you receive more data that you can handle?

3) I'm by far not an expert but I would have expected that there are additional security consideration for elevation and maybe even flow control... no?

4) Thanks for quickly addressing the genart review!
2017-09-04
12 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2017-09-04
12 Mirja Kühlewind
[Ballot comment]
1) What happens if the server received more than one (different) EXT_INFO messages or the client receives more than two?

2) One question …
[Ballot comment]
1) What happens if the server received more than one (different) EXT_INFO messages or the client receives more than two?

2) One question regarding flow control: I understood that some implementation simply set the max value for the initial window, however, if you don't even have a max window how do you ensure that the receiver is not over loaded and what do you do if you receive more data that you can handle?

3) I'm by far not an expert but I would have expected that there are additional security consideration for elevation and mybe even flow control... no?

4) Thanks for quickly addressing the genart review!
2017-09-04
12 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2017-08-31
12 Jean Mahoney Request for Telechat review by GENART is assigned to Matthew Miller
2017-08-31
12 Jean Mahoney Request for Telechat review by GENART is assigned to Matthew Miller
2017-08-29
12 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2017-08-29
12 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Mehmet Ersue
2017-08-29
12 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Mehmet Ersue
2017-08-28
12 Eric Rescorla Placed on agenda for telechat - 2017-09-14
2017-08-28
12 Eric Rescorla IESG state changed to IESG Evaluation from Waiting for Writeup
2017-08-28
12 Eric Rescorla Ballot has been issued
2017-08-28
12 Eric Rescorla [Ballot Position Update] New position, Yes, has been recorded for Eric Rescorla
2017-08-28
12 Eric Rescorla Created "Approve" ballot
2017-08-28
12 Eric Rescorla Ballot writeup was changed
2017-08-24
12 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery.
2017-08-22
12 denis bider New version available: draft-ietf-curdle-ssh-ext-info-12.txt
2017-08-22
12 (System) New version approved
2017-08-22
12 (System) Request for posting confirmation emailed to previous authors: denis bider
2017-08-22
12 denis bider Uploaded new revision
2017-08-01
11 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Mehmet Ersue.
2017-07-30
11 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-07-27
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-07-27
11 denis bider New version available: draft-ietf-curdle-ssh-ext-info-11.txt
2017-07-27
11 (System) New version approved
2017-07-27
11 (System) Request for posting confirmation emailed to previous authors: denis bider
2017-07-27
11 denis bider Uploaded new revision
2017-07-26
10 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2017-07-26
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-curdle-ssh-ext-info-10. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-curdle-ssh-ext-info-10. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Message Numbers registry on the Secure Shell (SSH) Protocol Parameters registry page located at:

https://www.iana.org/assignments/ssh-parameters/

two new registrations are to be made as follows:

Value: [ TBD-at-registration ]
Message ID: SSH_MSG_EXT_INFO
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Message ID: SSH_MSG_NEWCOMPRESS
Reference: [ RFC-to-be ]

We note that the authors suggest the values 7 and 8 for these registrations.

Second, in the Key Exchange Method Names regsitry also on the Secure Shell (SSH) Protocol Parameters registry page located at:

https://www.iana.org/assignments/ssh-parameters/

two new registrations are to be made as follows:

Method Name: ext-info-s
Reference: [ RFC-to-be ]
Note: Section 2.2

Method Name: ext-info-c
Reference: [ RFC-to-be ]
Note: Section 2.2

Third, a new registry is to be created called the Extension Names registry. The new registry will be located on the Secure Shell (SSH) Protocol Parameters registry page located at:

https://www.iana.org/assignments/ssh-parameters/

The new registry will have a note that indicates that " Names in the Extension Names table MUST follow the Conventions for Names defined in [RFC4250], Section 4.6.1."

New registrations in the registry will be done though IETF Consensus as defined by RFC 5226.

There are initial registrations in the new registry as follows:

Extension Name Reference Note
--------------------+------------------+------------
server-sig-algs [ RFC-to-be ] Section 3.1
delay-compression [ RFC-to-be ] Section 3.2
no-flow-control [ RFC-to-be ] Section 3.3
elevation [ RFC-to-be ] Section 3.4

The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2017-07-24
10 Matthew Miller Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Matthew Miller. Sent review to list.
2017-07-20
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2017-07-20
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2017-07-20
10 Jean Mahoney Request for Last Call review by GENART is assigned to Matthew Miller
2017-07-20
10 Jean Mahoney Request for Last Call review by GENART is assigned to Matthew Miller
2017-07-17
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mehmet Ersue
2017-07-17
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mehmet Ersue
2017-07-16
10 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-07-16
10 Cindy Morgan
The following Last Call announcement was sent out (ends 2017-07-30):

From: The IESG
To: IETF-Announce
CC: ekr@rtfm.com, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, …
The following Last Call announcement was sent out (ends 2017-07-30):

From: The IESG
To: IETF-Announce
CC: ekr@rtfm.com, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com, draft-ietf-curdle-ssh-ext-info@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Extension Negotiation in Secure Shell (SSH)) to Proposed Standard


The IESG has received a request from the CURves, Deprecating and a Little
more Encryption WG (curdle) to consider the following document: - 'Extension
Negotiation in Secure Shell (SSH)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-07-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a
  mechanism for SSH clients and servers to exchange information about
  supported protocol extensions confidentially after SSH key exchange.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ballot/


No IPR declarations have been submitted directly on this I-D.




2017-07-16
10 Cindy Morgan IESG state changed to In Last Call from Last Call Requested::AD Followup
2017-07-16
10 Eric Rescorla Last call was requested
2017-07-16
10 Eric Rescorla Last call announcement was generated
2017-07-16
10 Eric Rescorla Ballot approval text was generated
2017-07-16
10 Eric Rescorla Ballot writeup was generated
2017-07-16
10 Eric Rescorla IESG state changed to Last Call Requested::AD Followup from Publication Requested::AD Followup
2017-06-19
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-06-19
10 denis bider New version available: draft-ietf-curdle-ssh-ext-info-10.txt
2017-06-19
10 (System) New version approved
2017-06-19
10 (System) Request for posting confirmation emailed to previous authors: denis bider
2017-06-19
10 denis bider Uploaded new revision
2017-06-17
09 Eric Rescorla IESG state changed to Publication Requested::Revised I-D Needed from AD Evaluation
2017-06-17
09 Eric Rescorla IESG state changed to AD Evaluation from Publication Requested
2017-06-12
09 denis bider New version available: draft-ietf-curdle-ssh-ext-info-09.txt
2017-06-12
09 (System) New version approved
2017-06-12
09 (System) Request for posting confirmation emailed to previous authors: denis bider
2017-06-12
09 denis bider Uploaded new revision
2017-06-02
08 Daniel Migault
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The intended status is Standards Track . This is the appropriated status as
the current document defines new protocol extensions.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a
mechanism for SSH clients and servers to exchange information about
supported protocol extensions confidentially after SSH key exchange.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, s there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The only discussion of this draft concerned some incompatibilities with the current implementations of OpenSSH 7.3/7.4 and  the "server-sig-algs" extension described in the document. The issue is that 7.3 and 7.4 does not provide the full list of supported algorithms, so client that assume the full list is provided in order to narrow down the identities/keys (adaptive public key algorithm selection) to use for the authentication may not be able to find the appropriated identity. The consensus was that work around should be found when adaptive public key algorithm selection is needed and when interacting with these two implementations.  Romen announced "21 May 2017 : Version x509-10.2" [1] that PKIX-SSH implemented such work around. He is the only one that raised this issue. 

Further explanation can be found in "work with broken "server-sig-algs" extension" [1] as well as Denis email [2]. I am copying the text from [2], as I believe it provides a complete description of the issue:

*Server-side situation:*

OpenSSH versions before 7.5 (such as 7.3) send the "server-sig-algs"
extension, but they only use it to indicate support for "rsa-sha2-512" and
"rsa-sha2-256". They do not include other public key algorithms that the
server supports, even though the server will accept those algorithms if
they are attempted.

It is intended that the server should send a complete set of accepted
public key algorithms. My understanding is that OpenSSH versions 7.5 and
later do this. Bitvise SSH Server has always sent a complete list.

*Client-side situation:*

There exist clients which have problems with OpenSSH 7.3 behavior, and
clients that don't.

*Clients with explicit public key configuration.* Bitvise SSH Client does
not have a problem with this behavior, because it does not use public keys
opportunistically. Our SSH Client will use a public key to authenticate
only if the key is explicitly configured by the user. It will use only the
requested key, and not other keys that it may find in various places of
storage.

As a result, our SSH Client has no use for a hint from the server about
which key types are OK to use. It already knows the key it's going to use.
The question is what signature algorithm (now renamed "public key
algorithm") to use with that key. For this purpose, the information sent by
OpenSSH is sufficient, regardless of version. For RSA keys, the
"server-sig-algs" extension provides the info. For non-RSA keys, there's
only one algorithm possible anyway, so we use it.

*Clients with opportunistic key search.* Other SSH clients, including
OpenSSH and PKIXSSH (Roumen's work) do not require a public key to be
explicitly configured in order to be used. Such clients perform an
opportunistic search, and try to use any and all keys that might work that
can be found in various places of storage. This includes the user's .ssh
directory, keys available via the SSH agent protocol, and keys specified on
the command line.

These types of clients have a problem, because:

- In OpenSSH versions 7.5 and higher, the client can use the list of
algorithms sent in the server's "server-sig-algs" extension to narrow down
the public keys it's going to try. If the server doesn't list ECDSA or DSA,
for example, the client can take that as authoritative, and can exclude
those keys from authentication. This is nice because it may involve trying
fewer keys.

- In OpenSSH version 7.3, the server will only send "rsa-sha2-256" and
"rsa-sha2-512", even if the server also accepts ECDSA and other algorithms.
This means the client needs to have explicit treatment to detect the
OpenSSH protocol version. If the OpenSSH version is older than 7.5,
"server-sig-algs" can still be used to enable the use of "rsa-sha2-XXXX"
instead of "ssh-rsa", but it cannot be used to exclude non-RSA keys in
authentication.

*Options:*

*(A) Rename extension.* Roumen has requested that we rename the
"server-sig-algs" extension and make it clear that the server must send all
algorithms it will accept.

I think this is not the best thing to do for the following reasons:

- There are multiple implementations of this extension which are not
impacted by the OpenSSH 7.3 issue. These implementations would suffer from
the rename.

- Implementations that are impacted by the OpenSSH 7.3 issue may still have
a requirement to interoperate with OpenSSH 7.5, as well as other servers
that currently send "server-sig-algs" with a complete list of algorithms.
For such implementations, renaming the extension is again not a fix, but a
further complication.

*(B) Workaround by clients that need it.* My suggestion is that clients
that use opportunistic key search, and wish to interoperate with OpenSSH
7.3, should implement a compatibility workaround for the way
"server-sig-algs" is sent by that version.

I think this is the better solution for the following reasons:

- There are multiple implementations which are already not affected by the
issue, whether communicating with OpenSSH or between themselves. In this
case, those implementations do not need to change anything.

- The work required for clients with opportunistic key search is similar to
the work required in above option A), *assuming *those clients want to
interoperate with OpenSSH 7.5+ and other existing servers that send
"server-sig-algs" with a complete list of algorithms.

On May 21 Romen has implemented the work around [1]:

work with broken "server-sig-algs" extension Server extension "server-sig-algs" was not implemented properly in OpenSSH 7.3 and 7.4. New version detect broken servers and replaces incorrect algorithm announcement with correct list.
For instance OpenSSH 7.3 list only algorithms rsa-sha2-256 and rsa-sha2-512. As result PKIX-SSH functionality for "adaptive public key algorithm selection" in connection to OpenSSH 7.3 skips all other identities except those with RSA key.


[1] http://roumenpetrov.info/secsh/index.html
[2] https://mailarchive.ietf.org/arch/msg/curdle/wszcCnXGAcUlMMj86zzDVKcdKZ8

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?


From the non up-to-date SSH implementation comparison [1], as well from the author/implementer of the draft that the following SSH implementations implement the draft:
- Bitvise SSH Server and Client
- OpenSSH
- AsyncSSH
- SmartFTP

In addition, Romen the implementer of PKIX-SSH provided significant
clarification of the document and the release note
of "21 May 2017 : Version x509-10.2" suggests PKIX-SSH supports the
current draft.  This may be updated regarding the necessity of "adaptive public key
algorithm selection"

[1] http://ssh-comparison.quendi.de/comparison/hostkey.html
[2] http://roumenpetrov.info/secsh/index.html

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Daniel Migault is the Document Shepherd and Eric Rescola is the Responsible Area.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I reviewed the document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No needed here.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Denis confirmed he is not aware of any IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

I believe the consensus is large and benefits from multiple implementations.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.



The nits has one comment regarding the copyright section and a comments regarding the mention of an RFC in the abstract.

Regarding mention of the RFC in the abstract.
-- The draft header indicates that this document updates RFC4254, but the
    abstract doesn't seem to directly say this.  It does mention RFC4254
    though, so this could be OK.

The current abstract mentions RFC4254, so the comment does not apply.

This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a
  mechanism for SSH clients and servers to exchange information about
  supported protocol extensions confidentially after SSH key exchange.

The copyright section mentions:
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)

This section is necessary as the current draft provides clarifying material from
RFC 4253 published in January 2006. In case we have to remove this would not
cause an issue.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The document updates  RFC4252, RFC4253, RFC4254. It is mentioned
in the header, the abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section is clear. It is consistent with the current draft and
references have been clearly identified.

The IANA section details how to update the Message Numbers [1] as well as
Key Exchange Method Names [2] as well as a new table "Extension Names".
Registration requires the IETF consensus. There is no expert review.

[1] https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-1
[2] https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

2017-06-02
08 Daniel Migault Responsible AD changed to Eric Rescorla
2017-06-02
08 Daniel Migault IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2017-06-02
08 Daniel Migault IESG state changed to Publication Requested
2017-06-02
08 Daniel Migault IESG process started in state Publication Requested
2017-06-02
08 Daniel Migault Changed consensus to Yes from Unknown
2017-06-02
08 Daniel Migault Intended Status changed to Proposed Standard from None
2017-06-01
08 Daniel Migault Changed document writeup
2017-05-30
08 denis bider New version available: draft-ietf-curdle-ssh-ext-info-08.txt
2017-05-30
08 (System) New version approved
2017-05-30
08 (System) Request for posting confirmation emailed to previous authors: curdle-chairs@ietf.org, denis bider
2017-05-30
08 denis bider Uploaded new revision
2017-05-26
07 Daniel Migault Changed document writeup
2017-05-26
07 Daniel Migault Notification list changed to Daniel Migault <daniel.migault@ericsson.com>
2017-05-26
07 Daniel Migault Document shepherd changed to Daniel Migault
2017-05-07
07 denis bider New version available: draft-ietf-curdle-ssh-ext-info-07.txt
2017-05-07
07 (System) New version approved
2017-05-07
07 (System) Request for posting confirmation emailed to previous authors: curdle-chairs@ietf.org, denis bider
2017-05-07
07 denis bider Uploaded new revision
2017-05-03
06 denis bider New version available: draft-ietf-curdle-ssh-ext-info-06.txt
2017-05-03
06 (System) New version approved
2017-05-03
06 (System) Request for posting confirmation emailed to previous authors: curdle-chairs@ietf.org, denis bider
2017-05-03
06 denis bider Uploaded new revision
2017-04-24
05 denis bider New version available: draft-ietf-curdle-ssh-ext-info-05.txt
2017-04-24
05 (System) New version approved
2017-04-24
05 (System) Request for posting confirmation emailed to previous authors: curdle-chairs@ietf.org, denis bider
2017-04-24
05 denis bider Uploaded new revision
2017-04-08
04 denis bider New version available: draft-ietf-curdle-ssh-ext-info-04.txt
2017-04-08
04 (System) New version approved
2017-04-08
04 (System) Request for posting confirmation emailed to previous authors: curdle-chairs@ietf.org, denis bider
2017-04-08
04 denis bider Uploaded new revision
2017-03-29
03 denis bider New version available: draft-ietf-curdle-ssh-ext-info-03.txt
2017-03-29
03 (System) New version approved
2017-03-29
03 (System) Request for posting confirmation emailed to previous authors: curdle-chairs@ietf.org, denis bider
2017-03-29
03 denis bider Uploaded new revision
2017-03-27
02 Daniel Migault IETF WG state changed to In WG Last Call from WG Document
2017-02-27
02 denis bider New version available: draft-ietf-curdle-ssh-ext-info-02.txt
2017-02-27
02 (System) New version approved
2017-02-27
02 (System) Request for posting confirmation emailed to previous authors: curdle-chairs@ietf.org, denis bider
2017-02-27
02 denis bider Uploaded new revision
2016-09-05
01 denis bider New version available: draft-ietf-curdle-ssh-ext-info-01.txt
2016-03-10
00 Rich Salz This document now replaces draft-ssh-ext-info instead of None
2016-03-10
00 denis bider New version available: draft-ietf-curdle-ssh-ext-info-00.txt