IETF Last Call Review of draft-ietf-sshm-ssh-agent-11
review-ietf-sshm-ssh-agent-11-secdir-lc-bonnell-2025-11-10-00

General:

1. I think the "byte[]" type needs to be more fully described, as it appears
that this document is the only one in the set of SSH specifications that use it
(RFC 4251 defines "byte[n]", where "n" is a fixed length, but not "byte[]"). I
believe it represents a sequence of bytes whose length is implicitly defined by
context as opposed to having an explicit length prefix (like the "string"
type), but this is not immediately clear. 2. Are messages that have a
"constraint[]" field (such as "SSH_AGENTC_ADD_ID_CONSTRAINED") containing 0
elements (i.e., empty constraints) valid? I assume not since there is a
different message number for unconstrained operations, but I think the doc
should be clear on this. 3. In section 3.2.7.3, a reference to section 6 of RFC
4251 (which explicitly defines when to use "@" in identifiers) is likely more
useful to the reader than a reference to section 4.2 of RFC 4251. 4.
Observation #3 above applies to section 3.8 as well. 5. In section 5.1,
"Clients MAY opportunistically attempt..." should be "SSH clients MAY
opportunistically attempt...". 6. Section 5.2 says: "As mentioned previously,
many deployed implementations only support the former, pre-standardisation
"auth-agent-req@openssh.com" request name. The latter "agent-req" name SHOULD
only be used if support was explicitly advertised as per Section 5.1.". But the
example says: ""agent-req" or "auth-agent-req@openssh.com"". Either the
"former" and "latter" need to be switched, or the example ordering switched. 7.
Likewise in section 5.3, "As above, the latter "agent-connect" open type
name..." should be changed to "As above, the former "agent-connect" open type
name...".

Security-specific:

1. Section 4 explicitly calls out the use of UNIX domain sockets and Windows
Named Pipes with a reference to Section 8. However, I did not see any specific
text regarding these in section 8. I expected some mention of using file
permissions (for UDS) and security descriptors (Windows Named Pipes) or other
mechanisms to control access. 2. Section 8 says: "SSH implementations SHOULD
NOT forward use of an agent by default and MAY implement additional controls
over key visibility and use for forwarded agent connections.". Strengthening
the MAY to a SHOULD seems like a good idea here. 3. Section 8 says: "...SHOULD
ensure that loaded token library code cannot gain access to other keys loaded
in the agent". How can this be ensured? If I'm understanding the previous
sentence correctly ("Loading a shared library on most platforms implies
automatic execution of code in that library in the address space of the process
that loads it."), it is common practice that the shared library for the token
"driver" is loaded directly into the agent process. At which point, the library
has unfettered access to the process's memory and can perform arbitrary
operations. If the implicit suggestion is to use a sandboxed sub-process to
load the library and interact with the token, then the text should be explicit
on this point. 4. Section 8 says: "Finally, with respect to the agent locking
functionality in Section 3.7, an agent SHOULD take countermeasures against
brute-force guessing attacks against the pass-phrase". It would be helpful to
the reader if an illustrative example of a countermeasure (such as lockouts,
etc.) were mentioned, perhaps with a reference to a document providing guidance
on how to implement such countermeasures.