> 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
Hey Marc,
Thanks for your suggestion. It is a great idea. We would like to ask
or present a few clarifying questions or comments, as follows.
Does the Tacacs Server return the matching key to the Tacacs Client or
the fingerprint? In step 4, you wrote fingerprint, but wrote key below.
We believe returning the key is not strictly necessary, but might be
necessary to fit into the openssh AuthorizedKeysCommand behavior, and is
not a burden.
We think that you are suggesting that both the Tacacs Server *and* the
Tacacs Client/SSH Server validate the key, rather than the SSH server
blindly accepting the Tacacs PASS/FAIL. Is that correct?
We think that the hash type for the fingerprint must be included in the
packets between the Tacacs speakers. The hash type has changed before and
we should expect it will change again.
Are you suggesting the tacacs exchange of fingerprints be binary or encoded
to an ascii representation? I presume base64 encoded.
Does step 5.2 imply a Tacacs session per-key offered by the SSH client,
or a continuation of the existing session? Suspect you are omitting the
detail here, but a continuation is our expectation.
It seems like there must be a step 7, where the Tacacs Client informs the
Tacacs Server of the result of Step 2 (eg: no more keys to offer) or 6 (eg:
fingerprint match result).
> 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
^^^^^^^^^^
We, or I, do not understand the argument for the openssh format. The
ietf has the rfc4716 format. Why wouldn't we use that? I realize that
might be a whole lot of opinion, which is ok.
> 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.
We'd like to see your code, if you can share it.
> Thanks,
>
> Marc
Thanks again, Marc.
Prost
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
