SSH Agent Protocol
draft-ietf-sshm-ssh-agent-16

# Andy Newton, ART AD, comments for draft-ietf-sshm-ssh-agent-14
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-sshm-ssh-agent-14.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Thanks for putting this specification together to document a protocol that is in very wide use.

Thanks to Martin Thomson for the ARTART review.

I have no objections with this draft.

Thanks for your patience while waiting for my updated ballot.

Thanks also for addressing the DISCUSS issues of my previous ballot [1] and the points raised by Duane Wessels in his int-dir review [2].

Regards,

-éric

[1] https://mailarchive.ietf.org/arch/msg/ssh/xDfWibdzDfgfHKWm4Nl3sjrs-FY/
[2] https://datatracker.ietf.org/doc/review-ietf-sshm-ssh-agent-12-intdir-telechat-wessels-2025-11-20/

Thanks for the work is described in this document. I do not see any transport-related concerns for this document.

Thanks to the authors and the WG for their work on this document.

Just some minor comments/nits:

s/RFC5226/RFC8126
s/EXPERT REVIEW/Expert Review

Section 3.2.7, paragraph 4
>    To fully parse a constraint, it is necessary to know its structure
>    beforehand and it is not possible to safely recover when an
>    unrecognised constraint is encountered.  Given this, if an agent does
>    not recognise or support a requested constraint it MUST abort
>    parsing, refuse the request and return an SSH_AGENT_FAILURE message
>    to the client.

As suggested by Erik, this document could do with an operational considerations section not only for the above concern, but also identify and emphasize some of the areas below. 

That section could include considerations such as:

- Ensuring that the protocol is designed so that the private key material MUST NOT be transmitted or exported from the agent.
- That an agent can be killed when the user logs out or is finished with SSH, thus removing the decrypted private key from memory.
- This might be challenging to add, but keys added to the agent can optionally should have a lifetime constraint. Operationally, having a short timeout for keys is a best practice to limit the window of exposure.

The Agent Forwarding case, while convenient opens up the largest operational security risk in my mind. An operational practice that SHOULD NOT use agent forwarding on servers that are not fully trusted, which include build servers, test servers etc.

The IANA review of this document seems to not have concluded yet.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Duplicate informative references to:
https://www.iana.org/assignments/ssh-parameters/.

Reference [RFC5226] to RFC5226, which was obsoleted by RFC8126 (this may be on
purpose).

Section 2.1, paragraph 2
> y referred to as an "SSH client". Similarly "SSH server" will be used to refe
>                                   ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Similarly".

Section 3.1, paragraph 5
>  type name, for example "ssh-rsa" for a RSA key as defined by [RFC4253]. "ke
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.1, paragraph 5
> ry by key type, as specified in sub-sections 3.2.1 through 3.2.4 for commonl
>                                 ^^^^^^^^^^^^
This word is normally spelled as one.

Section 3.2, paragraph 3
> NTC_ADD_IDENTITY message over sending a SSH_AGENTC_ADD_ID_CONSTRAINED with an
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2, paragraph 5
> o add a key, then it MUST respond with a SSH_AGENT_FAILURE reply. 3.2.1. DSA 
>                                        ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.4, paragraph 3
>  is left solely up to the agent. Typically only the public components of any
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Typically".

Section 3.2.7, paragraph 5
> al or private-use constraints through a extension constraint that supports na
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.7.1, paragraph 1
> intend (i.e. the agent will fail in a safe way). 3.3. Public key encoding Ke
>                                  ^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "safely" to avoid wordiness.

Section 3.4, paragraph 10
> illing to generate the signature (e.g. because it doesn't have the specified 
>                                       ^^
It seems like there are too many consecutive spaces here.

Section 3.7, paragraph 3
> sion failure SHOULD be signaled using a SSH_AGENT_EXTENSION_FAILURE message:
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 4, paragraph 2
> st, typically it will arrange to make a endpoint (e.g. a listening socket) av
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 7.4, paragraph 3
> dows, access to a named pipe may controlled by attaching a security descript
>                                  ^^^^^^^^^^
Did you mean "be controlled"?

Section 7.5, paragraph 3
> nces in timing, power use or by side-effects in the memory subsystems (e.g. 
>                                 ^^^^^^^^^^^^
Did you mean "side effects" (=adverse effect, unintended consequence)? Open
compounds are not hyphenated.

Section 8, paragraph 5
> ent and server implementation for Unix- like systems. It has supported the ag
>                                   ^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

# Review of draft-ietf-sshm-ssh-agent-14

CC @MikeBishop

## Comments

### Section 3.2.5, paragraph 2

A reference to the IANA registry that controls these code-points, both
by name and URL, would be appreciated.

### Section 3.7, paragraph 0
```
     The agent protocol supports requesting that an agent temporarily lock
     itself with a pass-phrase.  When locked, an agent MUST suspend
```
There's a conflict here between "requesting" and "MUST". If it's a request, then
compliance is merely recommended (SHOULD); if it's mandatory behavior, it's more
than a request.

### Section 4, paragraph 1
```
     Microsoft Windows, it is usual to use a Windows Named Pipe.  Access
     to these endpoints should be controlled as discussed in Section 8.
```
SHOULD?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.2, paragraph 2
```
-    The generic format for the key SSH_AGENTC_ADD_IDENTITY message is:
-                              ----
```

"key" can be removed here.

#### Section 3.2, paragraph 3
```
-    public and private components of the key and vary by key type, as
-                                                    ^
+    public and private components of the key and varies by key type, as
+                                                    ^^^
```

#### Section 3.2, paragraph 4
```
-    The SSH_AGENTC_ADD_ID_CONSTRAINED is similar, but adds an extra
+    The SSH_AGENTC_ADD_ID_CONSTRAINED message is similar, but adds an extra
+                                      ++++++++
```

Hi, 

The new version [1] addresses the main DISCUSS points in my previous ballot [2]. 

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-sshm-ssh-agent-14&url2=draft-ietf-sshm-ssh-agent-15&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/ssh/ZSfUlhQ_1lkbsC9arRzTZuwMp60/

Thank you to Meral Shirazipour for the GENART review.

# Orie Steele, ART AD, comments for draft-ietf-sshm-ssh-agent-14 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-sshm-ssh-agent-14.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### UTF-8 extensions & SMTP

I wonder if there is an expectation around deliverability to these extensions?
Is there anything in https://datatracker.ietf.org/doc/html/rfc6531 that is relevant here?

## Nits

### caese -> cause

```
497	   NOT caese the keys be deleted from the token itself.
```