Under this scheme, TCP and UDP port numbers less than 1024 were allocated only to system processes. Ordinary user programs couldn't use these low-numbered ports on the local machine, although they could connect to low-numbered ports on a foreign machine. A connection to foreign host was regarded as trusted if the foreign port number was less than 1024, meaning that a system process was on the other side of the connection.
So, for example, if userA on hostX wanted to grant login access to userB on hostY, he'd specify userB@hostY in his .rhosts file, telling the system to allow logins from that remote user. An incoming rlogin connection from hostY would be checked to make sure the remote port number (on the hostY side) was less than 1024. If so, and it claimed to represent userB, then it was admitted, on the assumption that the remote machine's operating system had properly authenticated userB. Some other user on hostY would be unable to impersonate userB, since a direct connection (from port 1024 or higher) would be rejected, and a connection from a privileged port would have to go through hostY's operating system.
The trusted port system was implemented before the availability of strong cryptographic authentication, and is now obsolete. Newer programs like ssh provide all the functionality of the older r-programs, typically using public key authentication to verify the identity of remote users and programs. Trusted ports should no longer be viewed as adequate security.