From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 3 Apr 2007 07:57:01 -0400 From: "Russ Cox" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] inferno/pop secrets In-Reply-To: <8977c47617d8e422a0d383a4c2a311dd@quintile.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8977c47617d8e422a0d383a4c2a311dd@quintile.net> Topicbox-Message-UUID: 3cb2c0ca-ead2-11e9-9d60-3106f5b1d025 On 4/3/07, Steve Simon wrote: > I understand how p9sk1 auth works but have never quite understood how > the inforno/pop password is distributed - this is used for quite a few > protocols plan9 serves - imap, pop, vnc (server) inferno, httpd etc. > > It seems to me that all these servers would need to run in the namespace of > auth/keyfs so they can read /mnt/keys/$user/secret to run their auth. > > If these servers are to run on a seperate cpu server rather than the auth server > itself then this namespace must be securly exported - how is this done? > > This piece of the jigsaw doesn't fit in my brain. The servers don't get to see the raw password. Instead they offload the authentication parts of their respective protocols to the auth server. This means that the auth server (auth/authsrv) knows all the various password-based protocols. All the protocols start off looking like a standard p9sk1 ticket request but use a different op code and sometimes omit the user field. The different op code tells the auth server to run a protocol-specific conversation (usually some form of challenge response) before replying with usable tickets. See authsrv(6). Now that we have factotum, the apps actually offload to factotum, which offloads the server side password computations to auth/authsrv. No one sees the plaintext password except auth/authsrv. Russ