Return to README.plainrsa CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / ipsec-tools / src / racoon / doc

ipsec-tools

    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: 2012/02/21 22:39:10 $