Hi Douglas et al.,
I'd suggest to reduce your proposed model to:
- The TACACS+ authentication is extended to allow the TACACS+
client to request the SSH client's public key from the TACACS+ server,
based on the client's public key fingerprint, for verification.
This results in a simple one-time request-response exchange for each key
the client presents:
1. SSH client connects to SSH server (once)
2. SSH server calculates public key fingerprint/hash
3. SSH server queries TAC+ server for user/fingerprint
4. TAC+ server replies with PASS and fingerprint, or FAIL
5. SSH server verifies fingerprint
1. if match: continue with next step
2. if not match: continue with next client key (step 2)
6. SSH server accepts connection based on fingerprint match
This is even compatible with OpenSSH's "AuthorizedKeysCommand" model. It
can't get easier than that, and it just works.
On the TAC+ side:
* #define TAC_PLUS_AUTHEN_TYPE_SSHKEY or whatever (my PoC code uses
"8", but YMMV)
* let the TAC+ client start an authC request with that code, with
username set and the data field set to the key hash
* let the TAC+ server return an approriate return code, with the
public key in the data field, preferably in OpenSSH format
Please support this approach. I've even managed to released PoC code for
that, which virtually proves that all this is trivial to implement, both
on the client and server side.
Thanks,
Marc
On 03.11.2022 18:58, Marc Huber wrote:
Hi,
apologies ... I've still some trouble to understand what kind of
advantage the "allow the TACACS+ client to request the public keys
from the TACACS+ server" option could give. On the implementation
side, I have absolutely no trouble about the "T+ sends public-key to
router" approach, that's easy enough.
However, I can't see the reasoning behind that. Why should the T+
server be excluded from determining whether a SSH key is legit or not?
And why should the T+ server send a list of valid public keys to the
router, at all?
I propose a minimal change to the T+ protocol: Have a new
authentication method, have the T+ server check the fingerprint hash
(or even multiple hashes, both MD5 and SHA256) and you're done.
Please share your insights about those issues.
Cheers,
Marc
On 01.11.2022 15:58, Douglas Gash (dcmgash) wrote:
Dear OPSAWG
Following is an outline of the Client/Server interaction promised
earlier, to support SSH authentication with TACACS+…
The key decision for the solution is: where should the SSH
authentication proceed. The authors believe that it makes sense to
continue to exploit the scale of crypto processing at the TACACS+
client level, rather than shifting this up to the TACACS+ server.
Note that this model contrasts with the approach to proxy the SSH
authentication up to the server, which the authors believe would not
scale so well, but also encounters the fact that the authentication
does not have extensible arguments that would be needed to fully
communicate the required context to determine which keys should be
selected.
Therefore, the solution that will be presented has the following model:
- The SSH client and the TACACS+ client (acting here as the SSH
server) continue with the SSH processing roles they have now.
- The TACACS+ authentication is extended to allow the TACACS+ client
to request the public keys from the TACACS+ server, to ease ssh-key
management
- The TACACS+ authentication is extended to communicate the results
of the TACACS+ client authentication processing to the TACACS+
Server, for the TACACS+ Server to log centrally and grant the final
result for the TACACS+ client to enact.
All other aspects will continue to use the TACACS+ protocol for
processing of SSH requests as they do now.
This approach will utilise the data field paradigm discussed earlier
in the thread. We will follow with a document that describes the
complete solution in detail.
*From: *Douglas Gash (dcmgash) <[email protected]>
*Date: *Thursday, 8 September 2022 at 16:47
*To: *Alan DeKok <[email protected]>
*Cc: *[email protected] <[email protected]>, Andrej Ota
<[email protected]>, Thorsten Dahm <[email protected]>, John
Heasly <[email protected]>
*Subject: *Re: [OPSAWG] TACACS+ SSH Enhancements Document
Thanks Alan,
We will follow up shorty with the client/server interaction which
should help make more sense of “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.”
Regards.
*From: *Alan DeKok <[email protected]>
*Date: *Thursday, 8 September 2022 at 14:56
*To: *Douglas Gash (dcmgash) <[email protected]>
*Cc: *[email protected] <[email protected]>, Andrej Ota
<[email protected]>, Thorsten Dahm <[email protected]>, John
Heasly <[email protected]>
*Subject: *Re: [OPSAWG] TACACS+ SSH Enhancements Document
On Sep 8, 2022, at 6:47 AM, Douglas Gash (dcmgash)
<[email protected]> 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.
That seems like a reasonable compromise.
> 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.
I'm not clear what that means, but OK.
The TACACS data fields are binary safe. So TACACS should be little
more than an encapsulation layer for the SSH data. Ideally, the
TACACS documents should specify how that data is encapsulated (named
av-pairs, exchanges, etc). But the SSH data itself should be defined
by a reference to an existing SSH document.
> The potential advantage, from implementation perspective, is that
the T+ stack can remain largely as-is. The changes are limited to a
couple of new enum values for already existing enum ranges that and a
bump is needed for the version.
> Currently devices and servers will have business logic for each
authentication type that they support, which use the data field
(CHAP, MS-CHAP etc). The SSH may become plugged into this same level
in the stack, which we can consider, is the appropriate place for it.
>
> We believe this option will enable an effective encapsulated
upgrade approach for implementors, and welcome feedback.
I think it's a good approach.
Alan DeKok.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
