Sounds like your expert came up with a pet solution first, then made up the
requirements to fit. Even then, TLS Telnet does not fit. I can't find an
IETF STD for it.
Is tunnelling other protocols is an issue, is HTTP also not allowed?
GNU httptunnel tunnels other protocols including SSH through HTTP.
http://www.nocrew.org/software/httptunnel.html
There is also an smtp tunnel for which I can't find a link at the moment.
If HTTP and SMTP are allowed, consider all other protocols allowed.
I don't see a confidentiality issue with key distribution. Only the public
key needs to be distributed. Anyway, how secret will the public key be on
an LDAP server?
If LDAP public key support is needed, an OpenSSH patch exists. Since SecSH
is still in the draft stage, LDAP key support can be added to the standard.
Information on joining the working group is at
http://www.ietf.org/html.charters/secsh-charter.html
I see LDAP and remote key revocation as a risk on the server side. The
only way I would add, modify, or remove client keys on the server is to
SSH to the server first or, for the truly paranoid, log in locally. I
don't want a third party telling my server what client keys to trust or
revoke. The third party is a single point of failure. Break that and
all my servers are at risk.
I'm not up to date on TLS Telnet, but I know it's not an IETF standard.
I don't know if it does key management the way your expert wants. It
might or might not. I suggest that there is an unwritten reason [s]he
wants TLS Telnet and not SSH, and it may or may not have anything to do
with security or standards. The list of requirements are just paper
justification for personal preference.
My $0.02
