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>