🚀 go-pugleaf

In article <1992Aug14.191748.11505@reed.edu> nelson@reed.edu (Nelson
Minar) writes:

>   I do think RFC 931 would improve security on the Internet, but not by
>   very much..
>
>   [ quote from rfc931 about trustworthyness deleted]
>
>   No kidding. I don't trust root@some.site at all. I don't let root NFS
>   mount my disks, I don't let root rsh to my machine. In particular, I
>   don't trust anything a restricted port tells me.

Yes, but the rfc931 information is there for root@some.site to use,
and not for you to use. If I wanted to I could provide an encrypted
name as my rfc931 identifier.  You wouldn't know that
"SDdf;sadf344sagfarg" was "rouilj".  However, if you told me that you
had what you believed to be a forged letter with this rfc931 id, I
could use that info to find out that it was sent from the rouilj
account.

>   Why don't I trust root? I don't know you. And, on the majority of UNIX
>   machines it is fairly simple for any user to become root.

Well, how simple it is depends on the system. Currently I have systems
that can be rebooted into root mode.  However, when that is done, the
experimental rfc931 server (no, it is not available for public access
or use yet) that runs on that machine loses its encryption key. Thus
by getting an rfc931 identifier that says "rouilj" I can tell you
immediately that it isn't a valid identifier since there was no way
you should be able to get an unencrypted identifier out of one of my
properly operating servers.  Thus there is a high degree of
probability that that letter was forged.

I won't get any valid audit info from that connection, but I do know
for certain that something was rotten in the state of Denmark.

What would be ideal for this scheme is a public key system. That way,
you could validate the rfc931 identifier, but until the patents wear
off, that is unlikely.

-- John