On Fri, 8 Jan 1999, Nick Maclaren wrote: > Consider things like job schedulers, printing systems and so on. User > A calls one of those, which runs as user B. It then calls mail - the > examples were chosen because both of them do precisely that. Which > is the user identification that the mailer should use? Job schedulers == cron? It runs as you anyway. So getuid() works fine. getlogin won't though, unless cron does a setlogin(). It is times like these that I truly wish UNIX had something remotely similar to Capability Systems. [ Snip: Possible solutions pretty much involve trusting user B, or getting him to do a little work. Neither are suitable. ] > > When all email is cryptographically signed (and signitures enforced) > > with keys that are not trivial to guess and aren't easily forged, then > > we will have a better chance of being assured of a "user's identity". > > Over my dead body. In the UK, the government insists on choosing the > "trusted third parties" to hold copies of the private keys :-( Persistant authentication is called for. A non-crypto ticket perhaps? My understanding is, that if you don't have the whole notion of "keys" the goverment won't mind. Use a cookie. Are cookies allowed? The mailer keeps a number of secrets. Each secret could be as big as a 512-bit number. Every user has a queue of secrets -- so if you have 100 users, you would have 100 files with a list of secrets. The user runs "mail-secret" gets a secret that is good for 30 days. He hashes his username with the secret, and attaches it with his username to the message. Note: no public/private key -- it's just a secret. (shhh be vewy vewy quiet) He hands the message to user B, who does not need to be concerned about any secret type business. User B does his thing and hopefully calls the mailer with the message in 30 days. If not he gets a big fat error with "too late -- expired secret." The mailer tries to hash up the same username with its 30 keys. If it finds a match, it delivers the message under user A's name. No public keys, no secret keys -- well just one secret. > Be that as it may, even perfectly secure signatures don't solve the > problem completely, either, because the intermediate agent can easily > use one user's signature and identification for another's request. The only way to solve this is to have each secret expire after a single use. This throws a cork screw into my not-so-original plan, but you can work around this if you added ID numbers to each message. Something else you could put in an auxiliary header. Each secret is hashed with the name, an ID number that the user passes to user B. ID numbers are unique, of course, to each message. You can't reuse ID numbers. This effectively makes it a one shot ticket. Granted that this is ugly, it does allow you to proxy messages through a middle man -- as long as you can specify headers. -- Thamer Al-Herbish PGP public key: shadowsat_private http://www.whitefang.com/pgpkey.txt [ Maintainer of the Raw IP Networking FAQ http://www.whitefang.com/rin/ ]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:28:23 PDT