Hi Heas,
thank you for reviving the topic!
On 23.11.2022 07:05, heasley wrote:
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.
thanks a lot for catching that. Yes, the server should return the key,
and the SSH server could optionally compare it to the client key, so I
thinkt the actual sequence should be:
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 keyfingerprint, or FAIL
5. SSH server verifies TAC+ server response (PASS/FAIL) and keyfingerprint
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
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?
I'd make key validation by the server optional, as hash collisions are
possible, but unlikely.
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.
I agree.
Are you suggesting the tacacs exchange of fingerprints be binary or encoded
to an ascii representation? I presume base64 encoded.
Good point. Binary would imply less code on the NAC side, so that would
be fine for the fingerprint, too. However, given that most of the
TACACS+ procotol is currently ASCII, I'd prefer that.
There are different encodings for MD5 (hexadecimal) and SHA256
(hexadecimal, base64) used in the field right now. A common standard for
the over-the-wire packets would be fine for me, too.
The <hashtype>:<hashvalue> is what's OpenSSH is currently using:
MD5:c1:f2:43:18:ea:bb:fa:cc:31:31:04:bf:4f:fb:53:27
SHA256: SHA256:kOkclqivcjludf/jdsfkyqpddffdk38U12+CkA8fBAC
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.
This would continue the SSH session.
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).
I don't think that's necessary. From the TAC+ server perspective, a PASS
means that the fingerprint did match. If the NAC detects a mismatch
between the public key the TAC+ server can reject the connection and log
the event. However, hash collisions are unlikely.
But that's of concern, an additional exchange could be implemented where
the NAS confirms to the TAC+ server that the keys do match:
NAC -> TAC+: Start packet with username and fingerprint
TAC+ -> NAC: Validates fingerprint, result in reply packet is FAIL or a
new "plewas confirm" status
NAC -> TAC+: Sends CONTINUE packet with confirmation flag for key match,
unset for no match
TAC+ -> NAC: Sends reply with PASS or FAIL
This might make sense to guard against hash collisions, however
unlikeley these are.
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.
I'd prefer a standard, too. Alas, I got the impression that RFC4717 only
covers DSA keys. At least, it doesn't specify key types.
OpenSSH isn't an IETF standard, but I'd like to avoid the need to create
a fingerprint-over-the-wire or public-key-over-the-wire standardization
that could take years ...
We'd like to see your code, if you can share it.
Sure, please have a look at the do_sshkeyhash() function in
https://github.com/MarcJHuber/event-driven-servers/blob/master/tac_plus-ng/authen.c
This is pretty similar to PAP, actually.
Thanks,
Marc
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
