Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

SSH or Kerberos?

By Stuart Ward in News
Mon Jun 12, 2000 at 10:10:21 AM EST
Tags: Security (all tags)

I am trying to convince the manufactures of various bits of proprietary equipment to improve the security of their equipment. The sorts of things are PBX's, SDH equipment, protocol converters, etc. At the moment they either have serial or telnet interfaces with local authentication.

I have been looking at two alternatives, Kerberos, which seems quite good at managing the authentication on a server system and having a simple server-side code that could be implemented by the equipment manufacture. But everyone in the Unix community seems to use SSH, this seems more complicated to implement but provides a better level of security?

Sponsor: rusty
This space intentionally left blank
...because it's waiting for your ad. So why are you still reading this? Come on, get going. Read the story, and then get an ad. Alright stop it. I'm not going to say anything else. Now you're just being silly. STOP LOOKING AT ME! I'm done!
comments (24)
active | buy ad
Firstly the local authentication is a major problem, it means that passwords never get changed as to change to passwords of several thousand systems is impractical, and secondly the maintenance of individual user ID's doesn't happen, the engineers use generic usernames and passwords.

What we must have is a system that is easy for the engineers who need to access these systems on a daily basis but also gives us the greatest level of security. But it must be simple enough that the manufactures of this stuff see it as not too difficult to implement on their equipment, none of which is Unix.

I have looked for discussions on the pros and cons without success. Which way should we push them, SSH or Kerberos?


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Kerberos
o Also by Stuart Ward

Display: Sort:
SSH or Kerberos? | 29 comments (29 topical, editorial, 0 hidden)
Ask "That Other Site" - Ask Away... (1.00 / 1) (#2)
by davidu on Mon Jun 12, 2000 at 05:55:05 AM EST

davidu voted -1 on this story.

Ask "That Other Site" - Ask Away

Spell 'Kerberos' correctly, first.... (1.50 / 2) (#4)
by pwhysall on Mon Jun 12, 2000 at 07:32:01 AM EST

pwhysall voted -1 on this story.

Spell 'Kerberos' correctly, first.
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.

It's spelt Kerberos, but it relies ... (4.00 / 1) (#1)
by Fish on Mon Jun 12, 2000 at 07:50:21 AM EST

Fish voted 1 on this story.

It's spelt Kerberos, but it relies on high physical security of one of the machines involved (the authentication service, I believe). Windows 2000 supposedly has support for this, but you need to have a domain controller and I believe it's a right hassle to set it up.

It sounds like you may be trying to implement the code yourself on these propreitary(sp?) machines - hmm, in that case don't go for SSH2 which is a more complicated protocol than SSH1.

Use SSH. In case you're still thin... (2.00 / 1) (#5)
by Neuromancer on Mon Jun 12, 2000 at 08:55:42 AM EST

Neuromancer voted 1 on this story.

Use SSH. In case you're still thinking of Kerberos after reading all of this, don't let them fall into "I'm locked into a proprietary software because it claimed to be Kerberos" trap.

If you can edit articles, get rid o... (2.00 / 1) (#3)
by alisdair on Mon Jun 12, 2000 at 09:43:18 AM EST

alisdair voted 1 on this story.

If you can edit articles, get rid of the Katz-like ?s for sexed quotes. Otherwise, I wanna know the answer too!

Neither - use https (4.00 / 2) (#6)
by Anonymous Hero on Mon Jun 12, 2000 at 11:00:09 AM EST

It is becoming standard practice to have a web-based interface for all kinds of equipment (switches, printers, etc.). Just add OpenSSL and you have a pretty secure system, even with simple password authentication.

An alternative is to use plain http with a java applet to perform some type of challenge-response password authentication scheme.

If you insist on using one of SSH and Kerberos I would go with SSH. While Kerberos is quite transparent to the user it requires a lot of work from the system administrator to set up.


Re: Neither - use https (4.00 / 1) (#7)
by Hurst Dawg on Mon Jun 12, 2000 at 11:15:10 AM EST

The problem I see by using a web interface for everything is its speed. If someone has to use a web interface for a db or a call logging sytem (as I do) (Specifically AR User) you start to really notice the speed as compared to having a native client. The web interface is much slower and its quite frustrating at times. Here where I work we use kerberos authentication to log into the win9x, NT, and 2k boxes here. I think it works pretty well. I'm not sure about the admistrative aspect of it, though, maybe in a few years I'll be there ;)


[ Parent ]
Am I way off? (4.50 / 2) (#8)
by eann on Mon Jun 12, 2000 at 11:42:26 AM EST

There's a good chance I've misunderstood something, since this isn't really my area of specialty, but it seems like this isn't the right question to be asking.

Kerberos, from what I've seen done with it, is a double-blind server-based authentication system. It lets you do things like keep one password server (with designated backup servers, of course) to use with multiple other services. Once you've authenticated with Kerb, it's up to the client and server software what they do with that connection. Hopefully, step 1 is "encrypt it", since you've just gone through a lot of trouble to verify the user is who he says he is.

SSH, literally, is "Secure SHell". I don't know all the gory details of the protocol handshake, but my impression is that it establishes the encrypted connection first, then by default uses whatever local auth exists as if you were sitting at the console. SSH may simply be a telnet-like application over SSL ("Secure Socket Layer"). I don't know.

Theoretically (but without actually checking any documentation anywhere, 'cos I'm lazy like that), SSH could be set up to use Kerb-based authentication. Then you'd have secure ports on your PBXen, etc., that checked users against a common password file. That sounds like what you want.

So I guess your first question should be to find out if I'm totally off-base about how these things work. And your second is whether those particular pieces of software will fit together like that, or if you need to be looking in other directions.

Our scientific power has outrun our spiritual power. We have guided missiles and misguided men. —MLK

$email =~ s/0/o/; # The K5 cabal is out to get you.

Re: Am I way off? (2.50 / 2) (#16)
by Anonymous Hero on Mon Jun 12, 2000 at 12:56:05 PM EST

With Kerberos, your passphrase *NEVER* goes across the wire wether it be cleartext or encrypted.  With SSH, unless you are using the RSAAuthentication, your passphrase will go over the wire in an encrypted form.  This is an important difference...

[ Parent ]
Re: Am I way off? (5.00 / 1) (#20)
by Anonymous Hero on Mon Jun 12, 2000 at 07:09:47 PM EST

With SSH, your password never goes across the line. When you invoke ssh to another host, the host will use your public key (stored on that host in authorized_keys) to encrypt a random number. It then sends the encrypted random number to you. Your machine decrypts the random number with your private key and sends the decrypted random number back to the remote host. It compares its generated random number with the number which you have transmitted, and if they are the same, will log you in, usually as root. All subsequent communications between hosts will be encrypted, usually in Blowfish or 3DES. A utility known as sftp is available, but I haven't tried it. scp comes with OpenSSH and works just like cp, except that everything is encrypted over the line, with the logon as described earlier.

[ Parent ]
Kerberos! (4.70 / 3) (#9)
by Alhazred on Mon Jun 12, 2000 at 12:08:56 PM EST

SSH allows the creation of encrypted and optionally authenticated network sessions to most any service. It fixes the problem of using telnet/ftp and having clear text passwords going over the wire, BUT it certainly doesn't solve the other problems. In other words you still end up with a password file on each system and you still have the hassle of maintaining all the various accounts etc. The problem with that is that of course in any large heterogenious network you will quickly run into problems with "human engineering". People will pick bad passwords, share passwords with each other, write them down, give them away, email each other with their passwords, etc. Soon you have little real confidence in your security once again. Plus, since passwords tend to end up being the same from system to system once a cracker gets into one service on one machine they generally can start expanding that access simply by trying the same account on other systems.

Kerberos centralizes the management of all authentication to one key server. Its MUCH easier to physically and logically secure that one machine, and much easier to monitor it closely. Services can be pretty easily "kerberized" and once thats done you have all the advantages of SSH, plus the central management. In other words a user can be given exactly the rights they need to use whatever services they need to use in ONE SINGLE PLACE, and if say a user's key is stolen it is a simple task to revoke their access completely until they can be supplied with a new key, and you can be pretty confident that you can track all of that.

Plus in REALLY large networks Kerberos's features for dealing with authentication realms and related capabilities means that you can have a large network with individually administered sections which can mutually authenticate each other in trust hierarchies which are well defined and centrally manageable. Thus if one site on your network is compromised its relatively easy to revoke ALL access from there to anywhere else.

Its also technically simpler to kerberize applications than it is to set them up to work with SSH, except for very simple protocols like telnet and SMTP. FTP simply CANNOT be made to work with SSH at all, and has to be replaced by something which can. There are really no good solid SSH based FTP server replacements around at this time. Kerberizing FTP on the other hand IS possible.

Its really kind of apples and oranges in any case. I think vendors need to provide both types of solution because a lot of small organizations and individuals are not likely to have the expertise to set up and properly manage kerberos. On the other hand SSH is a poor choice in larger more complex networks and just doesn't provide you all the pieces you need there. In fact there is no reason why SSH itself can't be used WITH kerberized apps too, so deploying SSH doesn't in any way prevent use of kerberos, though there might end up being some redundancy there.

No system will ever get rid of the need to properly manage your userbases and services. Thats just life. People will always need access, and there will always need to be authentication and authorization mechanisms, and people being what they are, there will always be ways user's can be exploited. If you want a really secure network, you would just have to offer no services and have no users!
That is not dead which may eternal lie And with strange aeons death itself may die.
Re: Kerberos! (4.00 / 1) (#15)
by Anonymous Hero on Mon Jun 12, 2000 at 12:51:16 PM EST

In other words you still end up with a password file on each system and you still have the hassle of maintaining all the various accounts etc.

Well, with Kerberos, you still need an entry in the password file on the machine (or in a NIS map or something similar.)  Also, with SSH, you can use your public/private key-pair to log in (turn on 'RSAAuthentication yes' in the sshd_config) which then makes the password set on the system irrelevant.


[ Parent ]

Clue (1.50 / 2) (#10)
by End on Mon Jun 12, 2000 at 12:14:16 PM EST

It's spelled Kerberos, not 'kerbros'. A look at any kerberos-related website would have told you that.


Re: Clue (none / 0) (#21)
by Inoshiro on Mon Jun 12, 2000 at 07:22:34 PM EST

Perhaps you should see that Kerberos is spelt correctly 4 times, and was only misspelt once. You could infer that it was thus a typo.

[ イノシロ ]
[ Parent ]
Clue to you too (2.00 / 1) (#24)
by rusty on Tue Jun 13, 2000 at 02:46:54 AM EST

I fixed the misspellings. Originally it was misspelled every time. Clue to you too. :-)

Not the real rusty
[ Parent ]
Re: Clue to you too (none / 0) (#25)
by Inoshiro on Tue Jun 13, 2000 at 02:48:56 AM EST

Ahh, but you missed the one on the very end, which I fixed. :)

[ イノシロ ]
[ Parent ]
Re: Clue to you too (none / 0) (#26)
by rusty on Tue Jun 13, 2000 at 02:49:28 AM EST

Oops. Thanks. :-)

Not the real rusty
[ Parent ]
if you can add another machine to the mix ... (3.00 / 1) (#12)
by Arkady on Mon Jun 12, 2000 at 12:20:59 PM EST

What I do, and this may not be possible for you, depending on how much space and electricity are available, is add in another machine.

For example, you could put in a 486 or similar running OpenBSD with a serial port plugged into the PBX or whatnot's terminal port. Then you can ssh to the OpenBSD machine and use a terminal program like minicom to log into the PBX. If you need to control lots of devices from one server, you can put in a Digi multi-port serial card (though I don't know if they work in OpenBSD; I use Slackware Linux on the server that has that in).

Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere Anarchy is loosed upon the world.

Kerberos and SSH (4.00 / 1) (#13)
by dlc on Mon Jun 12, 2000 at 12:35:18 PM EST

A quick search for kerberos on SSH's site brings back 2 responses, both from the patches subdirectory, so I guess it is possible to uses SSH and Kerberos together. Also, grep -il kerberos *.{h,c} | wc -l in the ssh-1.2.27 source tree tells me 13 files mention kerberos (or 276 individual lines).

I'd say SSH and Kerberos are not mutually exclusive.



Re: Kerberos and SSH (none / 0) (#14)
by Anonymous Hero on Mon Jun 12, 2000 at 12:45:06 PM EST

so I guess it is possible to uses SSH and Kerberos together.

All that Kerberos support in SSH will do is get a TGT upon signin.  It's not like it can do something magical and somehow transform your SSH passphrase into a Kerberos TGT.

[ Parent ]

No need for passwords... (4.00 / 1) (#17)
by Alhazred on Mon Jun 12, 2000 at 02:24:08 PM EST

With a kerberized system there is NO NEED for passwords of any kind. Once you get your ticket granting ticket your known. Any system can authenticate you to the ticket server, and your rights can be established too. Granted that a Unix machine is going to want to know who you are and most systems are tied to the password file to do that, but with PAM and a kerberized LDAP you could take care of that for at least Linux and Solaris machines. NIS is just too ghastly to contemplate in a secure environment though...
That is not dead which may eternal lie And with strange aeons death itself may die.
A ?Better? Solution (3.00 / 1) (#18)
by Rich on Mon Jun 12, 2000 at 05:08:53 PM EST

I think the best solution for an ultra high security network would be some sought on of Kerberos authentication with a high level Encryption wrapper i.e. the Actual header info is all left unencrypted but whatever is inside the ip header is encrypted as it leaves the machine and then unencrypted as it is received. You would probably need some sought of Public Key server to handle the encryption. This scheme shouldn't require a-lot more resources than SSH and it shouldn't be to hard to implement.
Or am i completly wrong? Possibly
I Expect history will be kind to me as i intend to write is. Winston Churchill
The two are hardly exclusive (4.70 / 3) (#19)
by Nugget94M on Mon Jun 12, 2000 at 05:10:17 PM EST

ssh has supported kerberos for a long time. It's a simple matter of ./configure --with-kerberos5 and there you are. ssh is a transport facility, and kerberos is an authentication facility. They do different things. A quick look at openssh.org shows that it, too, supports kerberos as well.

Kerberos has some known weaknesses... (none / 0) (#22)
by core on Mon Jun 12, 2000 at 08:13:16 PM EST

SSH is the way to go. If you choose Kerberos, you're stuck with Kerberos authentication and the central KDC architecture (read: single POF, non-distributed). If you choose SSH on the other hand, you can use your choice of encryption algorithms and key management protocols (including Kerberos, if you like). SSH supports any number of ciphers whereas you're stuck with slow 3DES with many _newer_ Kerberos 5 implementations, IIRC.

Kerberos also has some weaknesses; the most glaring of which is the fact that (with Kerberos 5), if you can sniff the session setup packet, you can perform offline dictionary attacks to recover user passwords that can allow you to compromise any user's account with a bad password. Also, the kerberos keys are still based on user passwords (bad) where ssh keys are based on gathered system entropy. You can't sniff and dictionary attack an ssh key (although you can dictionary attack an ssh key if you steal it from one of the hosts but you can probably do even easier attacks than that if you have access to an ssh client or server...)

SSHv2 is newer than Kerberos v5, has evolved beyond the problems with SSHv1.x protocol. Both K and SSH are evolving. From what I've heard, you're much more likely to find that SSH implementations interoperate than Kerberos implementations.


Lots of problems in this (none / 0) (#27)
by Anonymous Hero on Tue Jun 13, 2000 at 05:25:31 AM EST

Your question is really not one but many:
  • How can I log in using encrypted terminal sessions and transfer files securely?

    Available alternatives here include SSH, SSL-Telnet and Kerberized Telnet.

  • How can I manage passwords centrally for my network?

    SSH does its own key management if you use its RSA feature. However, this is not enough since you might want to use the password for other purposes than just a simple login (think IMAP, POP3, or HTTP Basic Auth.). That will also require you to share home directories with a non-authenticated system, like NFS (which basically sucks, but lets not get into that right now).

    NIS(+) is in very widespread use. However, it is not secure. LDAP is slowly starting to replace NIS. Together with SSL or IPsec it has support to be secured, storing X.509-certificates in the database. Only bad thing about it is that it can be a hassle to set up and there exists no good (or free) software to do it yet.

    Kerberos is well-proven and widespread. It works, and is secure. It uses symmetric encryption only which means it is not sensitive to public-key stuff which we do not know as much about yet.

    Most applications (including SSH) has support for Kerberos authentication. If you write your own software it is easy to Kerberize it with any one of the available libraries.

  • How do I centrally manage users?

    This question is not solved by either SSH nor Kerberos. You will still need to use NIS(+) or LDAP for this purpose. However, if you go with Kerberos both these protocols can be secured with it, solving the security problems.

So, does that clarify things a bit? If you want to centrally manage users you have to choose between NIS (used to be default) and LDAP (starting to get a cross-platform standard).

To centrally manage keys and encrypt your network traffic, you can choose between SSL, Kerberos and nowadays IPsec. Of these choices, Kerberos is by far easiest to set up. You do not have the hassle with public keys. Most applications are ready for this (including the nice AFS file system).

Using SSH is completely orthogonal to this. You can use it no matter what your other choices are.

They seem to be complementary (none / 0) (#28)
by miggins on Fri Jun 16, 2000 at 08:43:38 AM EST

If I am understanding right, Kerberos securely authenticates users in an easy to manage way, while SSH provides an encrypted channel for data. So Kerberos is really what you want, but SSH might be usefull on top to actually encrypt the data once the user has been authenticated. Or is there a better standard for session encryption?

Corrections re: Kerberos misconceptions (none / 0) (#29)
by johan on Fri Jun 23, 2000 at 04:32:34 AM EST

First, let me answer your question.

If you're looking for a secure communications protocol that you can (attempt to) coerce vendors into using, i'd said go with something like HTTPS, SSH, SSL or SRP.

There are some weaknesses inherent in the SSH v1 protocol, which must be considered by a careful developer who plans to use the protocol. In particular SSH v1 is more vulnerable to man-in-the-middle attacks than SSH v2 or Kerberos v5.

I don't recommend Kerberos for your goal because a Kerberized-service (E.g. telnetd running on your network device) must have access to it's own service key in order to function. (A service key is more-or-less the server's secret.) To be truly secure, this service key should be transferred in a secure manner from the KDC to the application server. How would one do this? Typically, one first sets up the machine hosting the Kerberized application server as a Kerberos client, so that it can use a Kerberized ftp or rcp, and then pull the service-key file over using a secure (encrypted) session. (It could also be done using a floppy and sneaker-net.)

This requires more work than SSH, HTTPS or SRP, and means you aren't going to be able to just turn on a piece of network hardware and have it start working. (Though a piece of network hardware would need to be able to generate a SSH host key, which might be troublesome if the remote machine does not support the same (patented) encryption scheme used for the host key.)

That said, let me make a few comments to correct some common misconceptions about Kerberos. I have setup and run a number of Kerberos systems over the past few years, and am often quite surprised at the mistaken assertions people make regarding Kerberos.

Kerberos v5

Kerberos is an authentication protocol (system) requiring (at minimum) three different types of members (though all three of these could be running on one machine):

  1. The Client
    Typically a human sitting in front of a PC or workstation who wants to be able to do something like securely connect from their machine to a service on a remote machine. For example, me sitting in front of a Mac, wanting to securely telnet to a Sun running a "Kerberized" telnet daemon.
  2. The Application Server
    In the above example, it's the "Kerberized" telnetd running on a UNIX machine. It could also be a Kerberized ftpd, Oracle SQL server, rlogind, etc. The key is that it's a service made available to a (relatively) public network that understands the Kerberos authentication protocol.
  3. The KDC or "Key Distribution Server"
    This is the server that hands out keys (AKA "credentials" or "tickets"). There can be more than one "readable" server, but so far, only one "writable" server. If you understand how DNS servers work, it's very similar. There's a "primary" (AKA "master") for a particular "realm" (very similar to a DNS domain) which can replicate read-only copies of the principal database to multiple secondary (AKA "slave") servers. Users (AKA "principals") and their secrets ("password") can be changed (or added) on the master but no changes can be made on a slave. As with DNS, servers are typically queried (credentials requested) via UDP packets. If server #1 does not respond before the timeout, a packet is sent to server #2 or #3. The order is determined by the client's configuration file.

Kerberos has a number of strengths:

  • Secrets (passwords) are never sent over the network in the clear.
  • Secrets can be long (typically up to 255 chars.)
  • Protocol protection against reply attacks.
  • After the initial authentication, a user should not need to re-enter their secret for some realm-wide time limit. (Typically 8-12 hours.) In other words, you authenticate just once once, and then you can telnet, ftp, pop, rsh, rlogin, isql (or whatever) to as many machines in your realm as you want, as long as they can accept your Kerberos credentials.
  • The KDC provides a shared unique session key that the client and application server (like telnet-telnetd or ftp-ftpd) can then use to encrypt their communications. The encryption is typically strong: 3DES.
  • What's stored on disk for the user is a "TGT" (ticket-granting-ticket) that expires after some preset time. (typically 8-12 hours) So even if the account is compromised, the TGT can only be used for a limited time.
  • Free and open-sourced, unless you are using a vendor's binary distribution. (Microsoft, Sun, CyberSafe, etc.)
  • Inter-operable across multiple architectures (PC, Mac, UNIX) unless you are using Microsoft's KDCs (servers), which are not 100% compatible with other servers. Apple has stated they will support an MIT-compatible Kerberos in MacOS X.
  • Free telnet clients for Windoze, Macintosh or UNIX. (There is not a free SSH telent for Macs in the U.S. because of RSA patent issues.)

Kerberos weaknesses:

  • Non-trivial to setup. As with DNS, there must be a server that stores and serves data to "the public." However, SSH requires host key management, which is also a non-trivial (but smaller) amount of work.
  • All the secrets are encrypted and stored in the DB on the KDCs. So if a KDC is compromised, the data in the DB can (with a significant amount of work) be decrypted and every principal's secret known. Note that it's not necessary to store the master key (which is used to encrypt all the secrets in the DB) in a stash file on a KDC. If a stash file is not used, the realm is less vulnerable, but it means the daemons that serve tickets and handle admin requests cannot startup without human intervention.
  • No (V5) Kerberized FTP for Macintosh. (There is a V4 Kerberized version of Fetch.)
  • Until recently, Kerberos-development and support in other apps was greatly hampered by U.S. export regulations. (Unlike SSH, which was developed in Finland.)

Other issues:

  • Several serious bugs were just patched in the latest MIT distributions. They're might be more. Then again, maybe the increased attention to the source means that the serious bugs have now been eliminated.
  • SSH v2 is somewhat commercial.

Misconceptions i have heard or seen at various times (not necessarily here)

  • Kerberos transmits passwords over the network in the clear.

    This is completely false. As a protocol, Kerberos never does this. When a user first authenticates, the client-side program (on a UNIX machine, it's called "kinit") sends a request to the KDC for a TGT for the user. The KDC generates the TGT from a bunch of stuff (current UNIX time, requesting host IP address, plus more) and encrypts it with the user's secret, and then sends the encrypted TGT to the requesting program (kinit). If the user does not know the password, they cannot decrypt the TGT.

  • Kerberos is vulnerable to dictionary attacks

    This is true of V4 Kerberos, but not necessarily true for V5. V5 supports the option of "Pre-Authentication" which essentially requires the client to demonstrate that it knows the secret before the KDC will respond to the request for the TGT.

  • Kerberos has a single-point of failure.

    This is mostly-false. Just like DNS, the system is designed to be setup with multiple servers (KDCs), any of which can answer any and all requests for authentication. Changes to the principal DB must be made to the sole primary server, so this is a single point of failure, just like with DNS. Worst case, this would typically mean that some users with expired passwords would be unable to authenticate (and login) until the primary KDC was repaired, or a secondary was reconfigured to take its role. (Not difficult, if you've planned ahead) I believe there are plans to eliminate this weakness.

More info:

SSH or Kerberos? | 29 comments (29 topical, 0 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!