From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from tb-mx0.topicbox.com (localhost.local [127.0.0.1]) by tb-mx0.topicbox.com (Postfix) with ESMTP id 151A249E673F for <9fans@9fans.net>; Fri, 24 Jan 2020 01:12:40 -0500 (EST) (envelope-from lyndon@orthanc.ca) Received: from tb-mx0.topicbox.com (localhost [127.0.0.1]) by tb-mx0.topicbox.com (Authentication Milter) with ESMTP id 3F0118CD427; Fri, 24 Jan 2020 01:12:40 -0500 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t= 1579846360; b=NGbXJvZQmHyla4LDiLf8MmTQ2FwdAv3Hbd8+WNmhjGehStswxK u+u+y00gN18S2fVbdrxJoZcm2hifuGDWab/oy1lUw1xccHpK1Rlj/LMEShdfX0P9 CdfLgvm4r8PQ9SrTjVX/ureW9muPxGDZFxA8woj67AX5bQkLJ8jO9uTCasMzTHCQ os1iEvtafrbkFMxqBCGysD2RLszXC5Z+RPc6sBiwoXv68/U1AnoCy8FB1SnoGOSO ARFXbQHH04xukd782JTWy4mZj67chPcd6DRC8CCLf86dn5mK+tchHeGhvL//3EsP akh9M2nNNAzZ2NVOMyn+fGHuG2d0S+DGZ7XA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=from:to:subject:mime-version:content-type :content-id:date:message-id; s=arcseal; t=1579846360; bh=HmVJYM5 5/3KWeBen5i286LkgSW0OaHDqe2lIkleMJGI=; b=QtR1GJOQz/VqWWsLmuZNXB3 Jq+ts1GJg8IsOk0q6lzl2WuqrC7DWTuiz7JLNegGvuLUUdBjS0mto6O/935ou1aO dGN0EMylv5Glb9FqOK+hz9cM35/tYrCNrWDQavETcfzgsJkmI+bIip6U/N1oNNEE VTD8yfgaYihsLHhM69SMZPlpE+Wa6SBbwEkXxFEuhHMoJwBzl73r72yjU7rmiOJc M3xsqzUMallvtf6i662bzTYVXc9H2/pavGQB8IV9aRLMlyAiCcyIPn27/OBXOB0Q 0swxjAKM9nS9UPKdc+RKAagt4+TL+tsSp/1JlFS7RBBzCfWELWNHqmjdslCUXbQ= = ARC-Authentication-Results: i=1; tb-mx0.topicbox.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=orthanc.ca; iprev=pass smtp.remote-ip=208.79.93.154 (orthanc.ca); spf=pass smtp.mailfrom=lyndon@orthanc.ca smtp.helo=orthanc.ca; x-aligned-from=pass (Address match); x-ptr=pass smtp.helo=orthanc.ca policy.ptr=orthanc.ca; x-return-mx=pass header.domain=orthanc.ca policy.is_org=yes (MX Record found); x-return-mx=pass smtp.domain=orthanc.ca policy.is_org=yes (MX Record found); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 Authentication-Results: tb-mx0.topicbox.com; arc=none (no signatures found); dkim=none (no signatures found); dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=orthanc.ca; iprev=pass smtp.remote-ip=208.79.93.154 (orthanc.ca); spf=pass smtp.mailfrom=lyndon@orthanc.ca smtp.helo=orthanc.ca; x-aligned-from=pass (Address match); x-ptr=pass smtp.helo=orthanc.ca policy.ptr=orthanc.ca; x-return-mx=pass header.domain=orthanc.ca policy.is_org=yes (MX Record found); x-return-mx=pass smtp.domain=orthanc.ca policy.is_org=yes (MX Record found); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgedugedrvdefgdegtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufggtg ffkfesthdtredttddtvdenucfhrhhomhepnfihnhguohhnucfpvghrvghnsggvrhhguceo lhihnhguohhnsehorhhthhgrnhgtrdgtrgeqnecukfhppedvtdekrdejledrleefrdduhe egnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvddtkedrjeel rdelfedrudehgedphhgvlhhopehorhhthhgrnhgtrdgtrgdpmhgrihhlfhhrohhmpeeolh ihnhguohhnsehorhhthhgrnhgtrdgtrgeq X-ME-VSCategory: clean Received-SPF: pass (orthanc.ca: 208.79.93.154 is authorized to use 'lyndon@orthanc.ca' in 'mfrom' identity (mechanism 'ip4:208.79.93.154' matched)) receiver=tb-mx0.topicbox.com; identity=mailfrom; envelope-from="lyndon@orthanc.ca"; helo=orthanc.ca; client-ip=208.79.93.154 Received: from orthanc.ca (orthanc.ca [208.79.93.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tb-mx0.topicbox.com (Postfix) with ESMTPS for <9fans@9fans.net>; Fri, 24 Jan 2020 01:12:39 -0500 (EST) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (OpenSMTPD) with ESMTP id b50b7cd7 for <9fans@9fans.net>; Thu, 23 Jan 2020 22:12:38 -0800 (PST) From: Lyndon Nerenberg To: Plan 9 from Bell Labs <9fans@9fans.net> Subject: factotum vs. SASL+TLS+applications MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95332.1579846358.1@orthanc.ca> Date: Thu, 23 Jan 2020 22:12:38 -0800 Message-ID: Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 892ebade-3e70-11ea-9905-b734878cf151 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