Greg Troxel wrote:

>  psk.txt contains the right IP for the other endpoint and a 256-bit key
>  preceeded by 0x - is this fed in exactly to the phase 1 negotiation, or
>  is it treated as a string? I've always been curious about that.
>
>A good question, and inspection of the source should reveal the
>answer.  Without looking, I'd guess it is a string.
>
>  
>
The documentation says it should be entered directly. It shouldn't
matter much anyway, either way it's long enough to be impractical to
brute force (and even then they'd have to use the resulting AES key and
verify packets to see if it worked).

>PSKs are used to authenticate Phase 1; a fresh DH is used to derive
>the actual IPsec keys just as it would be if you used public/private
>keypairs with or without certificates.   256-bit AES and 2048-bit DH
>seem like reasonable choices.
>  
>
'Reasonable' as in 'definitely good enough' or 'light enough on
processing but might be crackable'?

>Certificates are not more secure than PSKs in any meaningful way.
>They are more convenient in large installations since you can have a
>CA and not have to configure n^2 psks.  But, using them introduces
>security risks you don't have with PSKs:
>  
>
Well you'd only need n^2 if you intend for each machine to communicate
with each other: if they're going to one central machine it's only 2n,
which is entirely within reasonable expectation. To add more machines
you only need to add to the gateway and (obviously) the client.
Certificates aren't really any better in this regard, in fact easier
since psk's are much easier to generate.

>On the upside, PSK distribution has to be safe.
>  
>
Assuming my OpenSSH setup is safe, PSK distribution is too.

Off topic for a moment, ss there any way to check or better yet force an
SSH2 key generation (DH) session to use large exponentiations? Or does
this not really matter all that much? My latest real-world security
policy hinges on the security of a single OpenSSH server with multiple
PuTTY clients (all on 2048 bit pubkey login, AES256 and HMAC-SHA1) so
this matters. This is over a strong wireless link so there is a large
range in which data can easily be sniffed (WEP is off, since it's no
more than an administration hassle now) and I want the encrypted content
to be as close to completely private as possible.

This is the only way I could get reliable, clean, scalable, etc.
tunneling for Windows clients, and apart from being useless for some
protocols (including FTP) it's working very well. Windows' IPSec is a
cruel joke.

Out of curiosity, is there any severe problem with DSA keys? I have read
that many poor implementations rely too much on quality entropy
generation, which is (apparently) not a problem in RSA, but have also
read conflicting documentation that says DSA is usually more 'secure'
than RSA for authentication on the same key length. Any clarification is
appreciated.

Also, any way to make OpenSSH's sshd limit login attempts on a per-user
basis would be really helpful. Just to thin the chances that someone
could get in a 'lucky' brute force session while I'm not tailing the logs.

>Note that bugs in racoon or other parts of NetBSD would compromise
>security.  I'd be much more worried about that then either 2048-bit DH
>or 256-bit AES failing.
>
>  
>
I'm not worried about the security aspect nearly as much as the privacy
aspects. But if it's really impractical to brute force 256 bits worth of
AES even /with/ some verifiable plaintext, then there's nothing to worry
about. I'm more worried about the hassles of no easy way to force both
Racoons to re-negotiate - I must be missing something. But it's not
urgent because static keys are 'good enough' for the part of the network
using IPSec.