On Sept 08, 2022, at 12:47 p.m., Douglas Gash wrote:
The alternative approach is to utilise the authentication packet data field.
This field is used for all exchange of authentication materials in the current
T+ protocol for applications such as CHAP based authentication flows.
The exchange of artefacts required for the SSH authentication can similarly be
embedded within the data field: the elements of the exchange would be wrapped
in an existing av-pair format.
Our definition of the SSH authentication flow would then require us to cover
the needed av-pairs, and the behaviour/error conditions etc, required for the
SSH authentication flow. The formatting of the artefacts in the data field
would be left to the existing encoding format that is selected.
Looking at key validation options in popular routers I typically see
public key hash verifications.
Iterating from that, the most trivial way to check a SSH key via TACACS+
might be to just put the plain hash (preferably in ssh-keygen format:
<hash-type>:<hash>) into the data field, and the server can easily
respond with PASS or FAIL. If the NAD sends an unknown hash type the
server could be free to compute the hash on the fly (if the public key
is available) or to just reject it. Are there conditions that would
require more than <hash-type>:<hash> to be embedded into the data field?
(I've implemented just that scheme last weekend as a PoC.)
Cheers,
Marc
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
