1HOW-TO use plainrsa auth, contributed by Simon Chang <simonychang@gmail.com> 2 3Before you begin, you should understand that the RSA authentication 4mechanism hinges upon the idea of a split cryptographic key: one used 5by the public, the other readable only to you. Any data that is 6encrypted by a public key can be decrypted only by the corresponding 7private key, so that the private key user can be assured that the 8content of the transmission has not been examined by unauthorized 9parties. Similarly, any data encrypted by the private key can be 10decrypted by the public key so that the public knows that this 11transmission came from this user and nobody else (this idea is called 12non-repudiation). Also, the longer the key length, the more difficult 13it would be for potential attacker to conduct brute-force discovery of 14the keys. So, what all this means for the security administrator is 15that the setup needs a pair of reasonably long keys for each host that 16wishes to authenticate in this manner. 17 18With this in mind, it should be relatively straightforward to set up 19RSA authentication. For the purpose of this document, we assume that 20we are setting up RSA authentication between two networked hosts 21called Boston and Chicago. Unless otherwise noted, all steps should 22be performed on both hosts with corresponding key names. Here are the 23steps: 24 251) Included in each default installation of ipsec-tools is a binary 26called plainrsa-gen. This executable is used to generate a pair of 27RSA keys for the host. There are only two parameters that you should 28be concerned about: -b, which sets the number of bits for the keys, 29and -f, which specifies the output file for plainrsa-gen to send the 30results. On an ordinary Pentium-II with 128 MB of RAM, it takes only 31seconds to generate keys that are 2048 bits long, and only slightly 32longer to generate 4096-bit keys. Either key length should be 33sufficient; any longer key length actually reduces performance and 34does not increase security significantly. You should therefore run it 35as: 36 37 plainrsa-gen -b 2048 -f /var/tmp/boston.keys 38 392) When the process completes, you should have a text file that 40includes both public and private keys. GUARD THIS FILE CAREFULLY, 41because once a private key is compromised it is no longer any good, 42and you must generate a new pair from scratch. Reading the file 43itself, you should see several very long lines of alphanumeric data. 44The only line you should be concerned with is the line towards the top 45of the output file that begins with "# pubkey=0sAQPAmBdT/" or 46something to that effect. This line is your public key, which should 47be made available to the other host that you are setting up. Copy 48this line to a separate file called "boston.pub" and change the 49beginning of the line so that it reads ": PUB 0sAQPAmBdT/". 50Alternatively, you can also grab the first line of the boston.keys 51file and uncomment the line so that it reads the same as above. Now 52rename the file you generated initially to "boston.priv". 53 543) You should now have two files, boston.priv and boston.pub 55(chicago.priv and chicago.pub on Chicago). The first file contains 56your private key and the second file your public key. Next you should 57find a way to get the public key over to the other host involved. 58Boston should have (1) its own key pair, and (2) Chicago's public key 59ONLY. Do not copy Chicago's private key over to Boston, because (a) 60it is not necessary, and (b) you would now have two potential places 61for losing control of your private key. 62 634) You should now configure the racoon.conf configuration file for 64each host to (a) turn on RSA authentication, and (b) designate each 65host's private key and the remote host(s)'s public key(s). Take all 66your keys and place it in one directory and use the global directive 67"path certificate" to specify the location of the keys. This step is 68especially important if you are running racoon with privilege 69separation, because if racoon cannot find the keys inside the 70directory you have just specified it will fail the authentication 71process. So, write the directive like the following: 72 73 path certificate "/etc/racoon"; 74 75Next, you need to specify the host's own private key and the public 76keys of all the remote peers involved. For your local private key and 77remote public key(s), you should use the following directives: 78 79 certificate_type plain_rsa "/etc/racoon/boston.priv"; 80 peers_certfile plain_rsa "/etc/racoon/chicago.pub"; 81 82Notice the option "plain_rsa" for both directives. 83 84Finally, under the "proposal" statement section, you should specify 85the "rsasig" option for "authentication_method". 86 875) You have finished configuring the host for RSA authentication. 88Now use racoonctl to reload the configuration or simply restart the 89machine and you should be all set. 90 91TROUBLESHOOTING 92 93In the event that the hosts fail to communicate, first go back to the 94instructions above and make sure that: 95 961) You have placed all the keys in the directory that is specified by 97the "path certificate" directive. Keep in mind that privilege 98separation will force racoon to look into that directory and nowhere 99else. 1002) You have specified correctly the host's own private key and the 101remote peer's public key. 1023) You have specified the "rsasig" method for authentication in the 103proposal statement. 104 105If you run into any further problems, you should try to use "racoon 106-v" to debug the setup, and send a copy of the debug messages to the 107mailing list so that we can help you determine what the problem is. 108 109Last modified: $Date: 2006/12/10 05:51:14 $ 110