Annotation of embedaddon/ipsec-tools/src/racoon/doc/README.plainrsa, revision 1.1.1.1
1.1 misho 1: HOW-TO use plainrsa auth, contributed by Simon Chang <simonychang@gmail.com>
2:
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.
17:
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:
24:
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:
36:
37: plainrsa-gen -b 2048 -f /var/tmp/boston.keys
38:
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".
53:
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.
62:
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:
72:
73: path certificate "/etc/racoon";
74:
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:
78:
79: certificate_type plain_rsa "/etc/racoon/boston.priv";
80: peers_certfile plain_rsa "/etc/racoon/chicago.pub";
81:
82: Notice the option "plain_rsa" for both directives.
83:
84: Finally, under the "proposal" statement section, you should specify
85: the "rsasig" option for "authentication_method".
86:
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.
90:
91: TROUBLESHOOTING
92:
93: In the event that the hosts fail to communicate, first go back to the
94: instructions above and make sure that:
95:
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.
104:
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.
108:
109: Last modified: $Date: 2006/12/10 05:51:14 $
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>