factotum vs. SASL+TLS+applications

factotum vs. SASL+TLS+applications

[Lyndon Nerenberg]

The following is all hypothetical.  I'm curious about how people
think auth(2)/factotum(4) could be adapted to support the use
case ...

factotum was intended to handle the authentication dance on behalf
of network apps. But in the case of things like IMAP, it really
just stores the client's login/password, and provides a bit of
helper glue for CRAM-MD5. Similarly for ftpfs.

I'm curious why upasfs and ftpfs are outliers in only using factotum
as a credential store, but leaving the actual authentication protocol
dance in the clients/servers.  The "Security" paper (/sys/doc/auth)
strongly hints that these parts of the application protocols were
meant to be outsourced to factotum.  Section 2.2 in particular
argues that the auth modules should be implemented once in factotum,
for consumption by the rest of the system.

Beyond the layering issue, how upasfs does IMAP authentication has
always bugged me.  The "/imaps/..." path handles the "native TLS
on port 993" case, but upasfs(4) says "... Authentication is delegated
to factotum(4)" which is mostly a lie in the "/imap/..." case.

Given a connection to port 143, upasfs will negotiate a simple
cleartext login, while blithely ignoring the server's advertised
security policy.  Specifically, it ignores the LOGINDISABLED and
STARTTLS capability advertisments, and there's no way to require
STARTTLS, even in the absence of the capability (e.g. work around
MITM downgrade attacks).  And the supported SASL mechanisms are
woefully out of date.

Obviously none of this is factotum's fault.  But getting this right is
a bit tricky, which strongly argues for implementing this, once and
correctly, in a single location.

I've looked at pushing this into factotum before.  The current big fail
is the flat 'proto=XXX' part of the factotum key namespace.  This
doesn't scale with SASL.  E.g. for some protocol 'imap' we end up
with:

	proto=imap		Plain old IMAP LOGIN (and SASL PLAIN)
	proto=imap-cram-md5	SASL CRAM-MD5
	proto=imap-scram-md5	SASL SCRAM-MD5
	[...]

plus all the '+tls' variants.  And yet it's going to be the same
passphrase underlying all of these.  In theory there should only
be one factotum entry for each IMAP server/userid instance; it
should not be necessary to update your sectore just because the
server's authentication scheme has changed.  And there's no reason
at all to duplicate factotum records just to handle the '+tls'
variants of each of the above.

What this really needs is for factotum to gain knowledge of SASL
as a general mechanism, apart from any specific application protocol.
Then there needs to be a mapping between the application protocol
being authenticated and the underlying SASL mechanism drivers.  The
challenge then becomes how to express this mapping in the factotum
records.

As an example, let's consider an IMAP (port 143) server.  The default
policy should be to use TLS if the server advertises it (STARTTLS),
and select the strongest compatible SASL mechanism the server
supports (based on re-issuing CAPABILITY after STARTTLS, and honouring
LOGINDISABLED).  This would have a key lookup like:

  proto=imap user=lyndon server=orthanc.ca !password=notlikely

To require a successful STARTTLS even if the capability is not
advertised, add "tls=required" to the record.

To require a specific SASL mechanism, add "sasl=scram-md5" (using
"sasl=*" as a default if you need to fall back for some reason).

Of course all of this needs to be glued into auth(2) in a way that
doesn't destroy the existing API.  But it does need to handle
factotum replacing the underlying connection to the client/server
with one that has been pushtls()ed by factotum itself.

--lyndon

Re: [9fans] factotum vs. SASL+TLS+applications

[Lucio De Re]

And work under p9p. Me too! Plug in a proper X-based WM and I can get
some performance out of my rather dated equipment again.

Lucio.

On 1/24/20, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
> The following is all hypothetical.  I'm curious about how people
> think auth(2)/factotum(4) could be adapted to support the use
> case ...
>

Re: [9fans] factotum vs. SASL+TLS+applications

[hiro]

i'd like to see the auth server do more of the work.

Re: [9fans] factotum vs. SASL+TLS+applications

[Ori Bernstein]

> The following is all hypothetical.  I'm curious about how people
> think auth(2)/factotum(4) could be adapted to support the use
> case ...
> 
> factotum was intended to handle the authentication dance on behalf
> of network apps. But in the case of things like IMAP, it really
> just stores the client's login/password, and provides a bit of
> helper glue for CRAM-MD5. Similarly for ftpfs.
> 
> I'm curious why upasfs and ftpfs are outliers in only using factotum
> as a credential store, but leaving the actual authentication protocol
> dance in the clients/servers.  The "Security" paper (/sys/doc/auth)
> strongly hints that these parts of the application protocols were
> meant to be outsourced to factotum.  Section 2.2 in particular
> argues that the auth modules should be implemented once in factotum,
> for consumption by the rest of the system.

Probably simple expediency.
 
> <snip>
>
> To require a specific SASL mechanism, add "sasl=scram-md5" (using
> "sasl=*" as a default if you need to fall back for some reason).

This all sounds fairly reasonable. I think that patches to this effect
would be worth integrating.

> Of course all of this needs to be glued into auth(2) in a way that
> doesn't destroy the existing API.  But it does need to handle
> factotum replacing the underlying connection to the client/server
> with one that has been pushtls()ed by factotum itself.

I'm not sure how factotum can have this action at a distance. I think
the pushtls is stuck in the client itself -- though, the auth code can
probably return the parameters needed for this.