[9fans] Authenticated SMTPD or factotum's p9cr

[9fans] Authenticated SMTPD or factotum's p9cr

[lucio]

The objective is to configure an authenticating SMTP server, so if
somebody has a formula for that, I'm game.

As I failed to figure it all out for myself (but thanks to those who
contributed to the wiki page on how to do authenticated outgoing
SMTP), let me explain where I'm stumped.

The diagnostic is a very stubborn dhcpd server returning:

	535 5.7.1 Authentication failed: auth server protocol botch

I've added the '%r' error message in a modified version of smtpd.c, I
strongly recommend this change.

I traced the cause for the failure to the call to auth_userpasswd()
and subsequently to auth_challenge().  The former seems OK on the
surface, despite the following comment:

 * This process was derived empirically.
 * this was copied from inet's guard.

But the call:
	ch = auth_challenge("user=%q proto=p9cr role=server", user)
isn't very helpful: it always fails (in my situation) with an ugly:

RPC start (user=proxima proto=p9cr role=server) failed: auth server protocol botch

a message I have added to a copy of the library module
libauth/auth_challenge.c.

The documentation for auth_challenge() is very thin and the code is a
bit obscure too.  For my part, I can embarrassingly admit that I have
no idea where the "auth server" belongs in this discussion, never mind
what the real purpose of the "p9cr" protocol is.

However, in my test modules, changing "proto=p9cr" to "proto=p9sk1"
moves the probelm to the next action in auth_challenge(), that is,
instead of failing on auth_rpc(..."start"...), it now complains about
the lack of synchronisation on the following auth_rpc(..."read"...)
which seems logical enough.

So there are a few things that need explaining, at least to me: (1) Am
I right in believing that "tcp25" must run as a trusted process and
therefore occur in /rc/bin/service.auth if it is to employ TLS?  (2)
What factotum or auth server entry is required to make "user=proxima
proto=p9cr role=server" succeed as a factotum RPC?  (3) The Factotum
man page covers the various verbs used in the RPCs, but goes into no
detail whatsoever about the actual arguments to them.  Maybe a few
examples will make a big difference.

Oh, the auth_challenge() man page incorrectly mentions
auth_userpassword() which I presume is meant to be auth_userpasswd().

Anyway, back to authenticated incoming SMTP, how do I make it tick?
Who needs to be identified?  I presume each possible user must have an
entry somewhere on the auth server, but what kind of entry?

And is there not a problem I cannot identify in
libauth/auth_challenge() or the factotum module for "proto=p9cr"?

Thanks.

++L

Re: [9fans] Authenticated SMTPD or factotum's p9cr

[geoff]

I can't answer all your questions immediately, but as long as smtpd
can read the certificate it needs for TLS (typically
/sys/lib/ssl/smtpd-cert.pem), tcp25 can reside in /rc/bin/service.
There needs to be a corresponding key in your cpu server(s)'s bootes's
factotum.  We load ours automatically from bootes's secstore factotum
file.  It and our ssh server key look like this:

key proto=rsa service=tls owner=* size=1024 ek=10001 n=[many hex digits] !dk? !p? !q? !kp? !kq? !c2?
key proto=rsa service=sshserve owner=* size=1024 ek=91 n=[many hex digits] !dk? !p? !q? !kp? !kq? !c2?

Our tcp25 for the outside world ends with this invocation of smtpd:

exec upas/smtpd -n $3 -gD -m /mail/lib/vfsend.alt -c /sys/lib/ssl/smtpd-cert.pem

Re: [9fans] Authenticated SMTPD or factotum's p9cr

[lucio]

> I can't answer all your questions immediately, but as long as smtpd
> can read the certificate it needs for TLS (typically
> /sys/lib/ssl/smtpd-cert.pem), tcp25 can reside in /rc/bin/service.

Hm, /rc/bin/service/tcp25 runs as "none" and where as it can read the certificate *that's easy), but I could have sworn it could not access the "eve" factotum (I use "proxima" as a replacement for "bootes", I have a feeling there are namespace issues that Bell Labs ought to take into consideration - but that's just a shot in the dark).  I fixed it initially by running factotum within tcp25 and adding the essential keys to it, which improved things, but left me with the "protocol botch".  My problem is that I cannot identify the casue of the botch (factotum's diagnostics - here's me looking a gift horse in the mouth - are no adequate) and that is where everything sticks.  I don't want to mess with the factotum code unless it becomes essential, but I guess it's one route to identify the problem.

> There needs to be a corresponding key in your cpu server(s)'s bootes's
> factotum.  We load ours automatically from bootes's secstore factotum
> file.  It and our ssh server key look like this:
> 
> key proto=rsa service=tls owner=* size=1024 ek=10001 n=[many hex digits] !dk? !p? !q? !kp? !kq? !c2?
> key proto=rsa service=sshserve owner=* size=1024 ek=91 n=[many hex digits] !dk? !p? !q? !kp? !kq? !c2?
> 
The alternative here is:

key proto=rsa service=tls owner=* role=client size=1024 ek=1 n=[...] !dk? !p? !q? !kp? !kq? !c2?
key proto=rsa service=sshserve size=1024 ek=17 n=[...] !dk? !p? !q? !kp? !kq? !c2?
key proto=rsa service=tls role=client size=1024 ek=10001 n=[...] !dk? !p? !q? !kp? !kq? !c2?

Is it possible that the "owner=*" instance is messing up things?  It
is a different entry.  I note, incidentally:

	term% ssh -l proxima huddle
	server huddle not on keyring.
	add key to keyfile (a), continue without adding key (c), or exit (e) [e]c
	ssh: client authentication failed
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

and especially

	term% telnet huddle
	connected to tcp!huddle!telnet on /net/tcp/1
	user: proxima
	authentication failure:auth server protocol botch
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

whereas

	term% cpu -h huddle -u proxima
	huddle# cat 


> Our tcp25 for the outside world ends with this invocation of smtpd:
> 
> exec upas/smtpd -n $3 -gD -m /mail/lib/vfsend.alt -c /sys/lib/ssl/smtpd-cert.pem

I have:

	exec upas/smtpd -d -a -c /sys/lib/tls/virtual.pem -n $3 >[2] /sys/log/smtpd

or, by shuffling the options:

	exec upas/smtpd -n $3 -d -a -c /sys/lib/tls/virtual.pem >[2] /sys/log/smtpd

now I have to understand all the differences, I do presume that "-c"
implies "-a" or that lack of "-a" makes authentication optional.  I
was going to put -gD in later and of course "-d" is temporary (and not
terribly useful, for some reason I need to understand better).

Oh, "-m" is undocumented.  I see it selects a mailer with default
"send" and, yes, "-a" makes authentication mandatory, which is as I
want it.

Thank you for all your help.

++L

Re: [9fans] Authenticated SMTPD or factotum's p9cr

[erik quanstrom]

> Hm, /rc/bin/service/tcp25 runs as "none" and where as it can read the certificate *that's easy), but I could have sworn it could not access the "eve" factotum (I use "proxima" as a replacement for "bootes", I have a feeling there are namespace issues that Bell Labs ought to take into consideration - but that's just a shot in the dark).  I fixed it initially by running factotum within tcp25 and adding the essential keys to it, which improved things, but left me with the "protocol botch".  My problem is that I cannot identify the casue of the botch (factotum's diagnostics - here's me looking a gift horse in the mouth - are no adequate) and that is where everything sticks.  I don't want to mess with the factotum code unless it becomes essential, but I guess it's one route to identify the problem.

i believe one needs to run services that need to talk to factotum
from service.auth.  i don't run smtp with authentication, but i 
do run ssh.  ssh needed it's key in factotum and to be run from
service.auth.

- erik

Re: [9fans] Authenticated SMTPD or factotum's p9cr

[geoff]

We run tcp25 from /bin/service and smtpd is able to received mail via TLS.

>From factotum(4):

          The factotum owner can use any key stored by factotum.  Any
          key may have one or more owner attributes listing the users
          who can use the key as though they were the owner.  For
          example, the TLS and SSH host keys on a server often have an
          attribute owner=* to allow any user (and in particular,
          `none )' to run the TLS or SSH server-side protocol.

Re: [9fans] Authenticated SMTPD or factotum's p9cr

[lucio]

> We run tcp25 from /bin/service and smtpd is able to received mail via TLS.
> 
>>From factotum(4):
> 
>           The factotum owner can use any key stored by factotum.  Any
>           key may have one or more owner attributes listing the users
>           who can use the key as though they were the owner.  For
>           example, the TLS and SSH host keys on a server often have an
>           attribute owner=* to allow any user (and in particular,
>           `none )' to run the TLS or SSH server-side protocol.

I guess I don't read the man pages very carefully.  In reality,
factotum is novel enough for me to have trouble grasping all its
facets.  The above clarifies some bits I was really baffled about.
Thank you for point it out.

++L