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