howto/IPsec-with-PublicKeys.md
... ...
@@ -0,0 +1,58 @@
1
+# IPsec with public key authentication
2
+## Stop using pre-shared keys!
3
+### Pre-shared keys suck, because _reasons_
4
+* __The key must be kept secret__, which means it must be shared only over a secure channel e.g. PGP, face-to-face
5
+* Most implementations will accept insecure (too short, too simple) keys
6
+* The [insecure][1] [IKE][2] [aggressive mode][3] must be used to support distinct PSKs for multiple dynamic peers, or
7
+* All dynamic peers must use the same PSK in order to use the more secure IKE main mode
8
+
9
+[1]: http://www.sersc.org/journals/IJAST/vol8/2.pdf "Vulnerabilities of VPN using IPSec and Defensive Measures"
10
+[2]: http://carnal0wnage.attackresearch.com/2011/12/aggressive-mode-vpn-ike-scan-psk-crack.html "Aggressive Mode VPN -- IKE-Scan, PSK-Crack, and Cain"
11
+[3]: http://rayas-security.blogspot.com/2013/06/ipsec-vpn-main-mode-vs-aggressive-mode.html "IPsec VPN, Main mode Vs Aggressive mode"
12
+
13
+### Public keys are _better_
14
+* They can be transmitted over insecure channels without compromising security
15
+* No need to generate a new key for each connection; just send the same public key to each new peer
16
+* Most implementations generate keys using high quality random numbers by default; one must _try_ to generate an insecure key
17
+* Dynamic peers can all have distinct public keys and still use IKE main mode
18
+
19
+### So why isn't everyone using public keys already?
20
+* The various IKE implementations don't all use the same format to represent public keys _(but we can **easily** [convert](#Conversion-tool) between them)_
21
+* Documentation on [how to](#How-To-examples), and why you should, configure public keys instead of PSKs is lacking _(which is why this page exists)_
22
+* Some implementations don't expose the ability to use public keys directly, only allowing a choice between PSKs and X.509 certificates
23
+
24
+### Public keys means certificates, right? Certificates are hard :(
25
+Many IKE implementations support manually configuring trusted public keys, without having to create a CA, generate CSRs, sign certificates, or remember/look up the commands to do those things.
26
+
27
+Keep in mind that certificates are just public keys wrapped with some extra metadata so that your router can automatically verify that it belongs to someone you trust. Certificates are useful for instances where there are so many peers that it's infeasible to manually configure each one's public key, such as a "road warrior" configuration or DMVPN. In those scenarios it makes sense to set up a Certificate Authority to handle it.
28
+
29
+## Ok fine, how do I public key?
30
+### Conversion tool
31
+Different implementations use different formats to represent public keys, and it's necessary to be able to convert between them. Here is a script for that purpose:
32
+
33
+https://github.com/ryanriske/pubkey-converter
34
+
35
+### How-To examples
36
+| Implementation | Key format |
37
+| :----------------------- | --------------: |
38
+| [Cisco IOS][a] | Hexadecimal DER |
39
+| [Mikrotik RouterOS][b] | PEM |
40
+| [OpenBSD][c] | PEM |
41
+| [Racoon][d] | Base64 RFC 3110 |
42
+| [strongSwan < 5.0.0][e] | Base64 RFC 3110 |
43
+| [strongSwan >= 5.0.0][f] | PEM |
44
+| [VyOS/EdgeOS][g] | Base64 RFC 3110 |
45
+
46
+[a]: /howto/IPsecWithPublicKeys/CiscoIOSExample
47
+[b]: /howto/IPsecWithPublicKeys/RouterOSExample
48
+[c]: /howto/IPsecWithPublicKeys/OpenBSDExample
49
+[d]: /howto/IPsecWithPublicKeys/RacoonExample
50
+[e]: /howto/IPsecWithPublicKeys/strongSwan4Example
51
+[f]: /howto/IPsecWithPublicKeys/strongSwan5Example
52
+[g]: /howto/IPsecWithPublicKeys/VyOSExample
53
+
54
+### Notes
55
+1. Best practice is to generate the private key on the router itself, and not transfer it to another machine. This part should be kept secret!
56
+2. Generate a key of at least 2048 bits, preferably 4096 if both ends support it.
57
+3. Some implementations support more than one key format. The examples here only show how to use one of them (usually PEM) for brevity.
58
+4. RFC 3110 format is the same as that described in RFC 2537. The former obsoletes the latter.
... ...
\ No newline at end of file
howto/IPsecWithPublicKeys.md
... ...
@@ -1,58 +0,0 @@
1
-# IPsec with public key authentication
2
-## Stop using pre-shared keys!
3
-### Pre-shared keys suck, because _reasons_
4
-* __The key must be kept secret__, which means it must be shared only over a secure channel e.g. PGP, face-to-face
5
-* Most implementations will accept insecure (too short, too simple) keys
6
-* The [insecure][1] [IKE][2] [aggressive mode][3] must be used to support distinct PSKs for multiple dynamic peers, or
7
-* All dynamic peers must use the same PSK in order to use the more secure IKE main mode
8
-
9
-[1]: http://www.sersc.org/journals/IJAST/vol8/2.pdf "Vulnerabilities of VPN using IPSec and Defensive Measures"
10
-[2]: http://carnal0wnage.attackresearch.com/2011/12/aggressive-mode-vpn-ike-scan-psk-crack.html "Aggressive Mode VPN -- IKE-Scan, PSK-Crack, and Cain"
11
-[3]: http://rayas-security.blogspot.com/2013/06/ipsec-vpn-main-mode-vs-aggressive-mode.html "IPsec VPN, Main mode Vs Aggressive mode"
12
-
13
-### Public keys are _better_
14
-* They can be transmitted over insecure channels without compromising security
15
-* No need to generate a new key for each connection; just send the same public key to each new peer
16
-* Most implementations generate keys using high quality random numbers by default; one must _try_ to generate an insecure key
17
-* Dynamic peers can all have distinct public keys and still use IKE main mode
18
-
19
-### So why isn't everyone using public keys already?
20
-* The various IKE implementations don't all use the same format to represent public keys _(but we can **easily** [convert](#Conversion-tool) between them)_
21
-* Documentation on [how to](#How-To-examples), and why you should, configure public keys instead of PSKs is lacking _(which is why this page exists)_
22
-* Some implementations don't expose the ability to use public keys directly, only allowing a choice between PSKs and X.509 certificates
23
-
24
-### Public keys means certificates, right? Certificates are hard :(
25
-Many IKE implementations support manually configuring trusted public keys, without having to create a CA, generate CSRs, sign certificates, or remember/look up the commands to do those things.
26
-
27
-Keep in mind that certificates are just public keys wrapped with some extra metadata so that your router can automatically verify that it belongs to someone you trust. Certificates are useful for instances where there are so many peers that it's infeasible to manually configure each one's public key, such as a "road warrior" configuration or DMVPN. In those scenarios it makes sense to set up a Certificate Authority to handle it.
28
-
29
-## Ok fine, how do I public key?
30
-### Conversion tool
31
-Different implementations use different formats to represent public keys, and it's necessary to be able to convert between them. Here is a script for that purpose:
32
-
33
-https://github.com/ryanriske/pubkey-converter
34
-
35
-### How-To examples
36
-| Implementation | Key format |
37
-| :----------------------- | --------------: |
38
-| [Cisco IOS][a] | Hexadecimal DER |
39
-| [Mikrotik RouterOS][b] | PEM |
40
-| [OpenBSD][c] | PEM |
41
-| [Racoon][d] | Base64 RFC 3110 |
42
-| [strongSwan < 5.0.0][e] | Base64 RFC 3110 |
43
-| [strongSwan >= 5.0.0][f] | PEM |
44
-| [VyOS/EdgeOS][g] | Base64 RFC 3110 |
45
-
46
-[a]: /howto/IPsecWithPublicKeys/CiscoIOSExample
47
-[b]: /howto/IPsecWithPublicKeys/RouterOSExample
48
-[c]: /howto/IPsecWithPublicKeys/OpenBSDExample
49
-[d]: /howto/IPsecWithPublicKeys/RacoonExample
50
-[e]: /howto/IPsecWithPublicKeys/strongSwan4Example
51
-[f]: /howto/IPsecWithPublicKeys/strongSwan5Example
52
-[g]: /howto/IPsecWithPublicKeys/VyOSExample
53
-
54
-### Notes
55
-1. Best practice is to generate the private key on the router itself, and not transfer it to another machine. This part should be kept secret!
56
-2. Generate a key of at least 2048 bits, preferably 4096 if both ends support it.
57
-3. Some implementations support more than one key format. The examples here only show how to use one of them (usually PEM) for brevity.
58
-4. RFC 3110 format is the same as that described in RFC 2537. The former obsoletes the latter.
... ...
\ No newline at end of file