Date: Tue, 28 Jul 2020 21:10:51 +0200
From: cinap_lenrek@felloff.net
To: 9front@9front.org
Subject: Re: [9front] The 9 Documentation Project
Reply-To: 9front@9front.org

i think alot of confusion comes from the auth= atribute in the
ip/ipnet= entry vs. auth= attribute on the authdom= entry.

the auth= attribute from ip/ipnet is actually only used by terminals
that netboot! it is an attribute that the dhcp server will put in
a special option to ship it to the client so the client can dial
the authentication server to authenticate against the (root)
fileserver before having access to ndb.

but once you'r booted, factotum will actually look for authdom=
attribute in ndb to resolve the authentication server for a particular
domain presented in the p9any handshake, and IGNORE the auth=
attribute on a host or ipnet completely.

the protocol (omiting nonce and dh/dp9ik steps) works like this:

0) client connects to server
1) server presetns a list of domains, host identities and protocols
2) client picks a protocol and uses the domain and find the authentication
server for the domain and does a ticket request
3) decrypts client part of the ticket with its own password and extracts shared secret
4) forwards the server part of the ticket to the server
5) server decrypts the ticket with his own password and extracts shared secret
6) client and server verify that they each other known the shared secret
7) success. optinally use shared secret to establish encrypted channel (tlssrtv)

the step that bugs most people is 2), as in the protocol, only
the authentication DOMAIN is send over the wire. finding the AS
is the job of the CLIENT.

theres also a trick: if you use a dns domain name as the authdom,
then you can register an A/AAAA record for p9auth.$authdom and factotum;
if it can't find authdom= attribute in ndb; will attempt to contact
p9auth.$authdom instead as the auth server. then the client doesnt
need to add a authdom= entry in its ndb!

kerberos solves this with SRV records.

the error that happens is that people miss the authdom= attribute, and
assume the authentication server is per network. no. it is not. it is
just a bootstrap mechanism! and the real mechanism is apparently not
well known to many people.

the issue with dns is that newbies dont have dns under their control.
so p9auth is out. srv records is out. the only thing left what we can
do is find ways to avoid this hack and deprecate the auth= attribute.
maybe have dhcpd automatically determine authdom by dialing the root
fileserver and doing the resolution of authserver on behalf of the
client.

or we could ship all the authdoms= from ndb in a dhcp option.

maybe factotum itself could provide a hint over p9any protocol?
like we have the service factotum look into ndb and provide a list of
hints of the external addresses of the authservers for each key?

in any case, i think we could avoid alot of confusion by improving
the way of this bootstrap mechanism works.

--
cinap