Annotation of embedaddon/ipsec-tools/src/racoon/doc/README.plainrsa, revision 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>