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>