Key length variation; Stopping bandwidth theft with IPsec

-----BEGIN PGP SIGNED MESSAGE-----



lists.freeswan.org Email Summary for Tuesday October 28, 2003
===============================================================================
by Claudia Schmeing                                        [email protected]


This week's issue is short and sweet. A technical discussion about the
advantages of varying key lengths has begun on the design list; that's 
in Item 1. In Item 2, Jan Spitalnik has an interesting potential use for
FreeS/WAN: to stop a bandwidth thief who's using IP and Mac spoofing.

Enjoy.



This Week in Brief....

1.  Becoming more secure: RSA Key length variation 
2.  Preventing Bandwidth theft with IPsec
3.  Neat stuff: Debian UML patch, NAT-T for 2.03, FRAB


 ------------------------------------------------------------------------------


1.  Becoming more secure: RSA Key length variation 
    ==============================================
    3 posts Oct 21-23
    http://lists.freeswan.org/archives/design/2003-October/msg00081.html


Longtime project supporter John Gilmore made an argument for significant
variation in the lengths of FreeS/WAN's RSA keys, used to authenticate
two FreeS/WAN boxes to one another. The crux: avoid a commonly used key 
length, for attackers to focus their efforts on. Here's an excerpt from 
John's post:

    If 85% of the traffic uses 1024-bit keys, there's a real incentive for
    Bad Guys to build something that cracks 1024-bit keys, no matter how
    difficult it is to do -- assuming it can be done at all.  In the first
    year in which it *can* be done, it *will* be done.  It's a "sweet spot".
                                                                                
    If 95% of the traffic uses keys shorter than 4096 bits, but you can't build
    a 4096-bit key cracker, what gain do you get by building a smaller cracker?
    Let's say that 50% had standardized on 2192-bit keys.  There's
    a big advantage to the Bad Guys if they build a 2192-bit cracker.  Even if
    they can't tap 95% of the traffic, they'll still tap 50% of it.
                                                                                
    Now look at a situation where a wide range of key lengths is used.
    50% of the traffic WON'T be using 2192-bit keys or less; only 12% will.
    Another 0.05% will be using 2200-bit keys.  Another 2% will be using keys
    up to 2300 bits.  Another 2% up to 2400 bits.  At no point is there a
    "cliff" that encourages the Bad Guys to focus their efforts at that
    "sweet spot".

FreeS/WAN technical architect Michael Richardson responded to several of
Gilmore's points. Although there are some open questions about a potential
implementation, I'd hazard a guess that an upcoming FreeS/WAN version will
feature greater variation in key lengths.



2.  Preventing Bandwidth theft with IPsec
    =====================================
    4 posts Oct 10
    http://lists.freeswan.org/archives/users/2003-October/msg00309.html


Jan Spitalnik has an interesting potential application of IPsec: to 
prevent bandwidth theft by an intruder who's using IP and Mac spoofing.
Jan manages a community network. Here's they've encountered:

    we have central access point (AP) which has omnidirectional antenna with 
    with all our clients are connected. So actually everyone can connect to 
    our network....

    ...when we blocked the IP address of the intruder.... ....he used mine 
    MAC&IP address to access the network.

Jan asked, "We are considering deploying IPSec, but the question is, will 
IPSec help us with this problem?"

Based on experience in a similar situation, James Carter suggested that it
would. James wrote:

    Here at UCLA-Mathnet, we're deploying IPSec and using X.509 certificates
    to allow only our own people to establish tunnels.  Among the other
    benefits of IPSec, our department pays for content (e.g. AMS online
    journals) which is made available to Mathnet hosts, authenticated by the IP
    address, and thus, if a tunnel is used (plus NAT on our end), our people
    can use the licensed content from home.  But we have to restrict access to
    only our own people.  The motivation is different from yours, but the
    technical issues are similar.

Certificates (or properly managed bare RSA keys) would allow Jan to know who 
was connected at any given time, and would prevent an intruder from 
connecting. James recommended that Jan look at a couple of documents he'd 
written up and posted on the 'net:

    http://harlech.math.ucla.edu/services/ipsec.html
    http://www.math.ucla.edu/~jimc/documents/vpn.html

These are quite dense and cover several topics of broader interest, 
including a discussion of MTU (Maximum Transmission Unit) issues in a NATted 
(Network Address Translated) environment. Thanks, James, for writing up your 
notes and making them accessible to the FreeS/WAN user community.



3.  Neat stuff: Debian UML patch, NAT-T for 2.03, FRAB
    ==================================================
    1 post Oct 16
    http://lists.freeswan.org/archives/users/2003-October/msg00473.html
    1 post Oct 27
    

Daniel Pocock has contributed a patch that will help Debian users build
FreeS/WAN for UML (user-mode linux) kernels. He's also created a nice
web page describing how to use it. Daniel wrote:

    I've been working on a patch that allows building the Debian
    freeswan-modules-source package for a user-mode-linux kernel.
                                                                                
    There are also details of how to patch freeswan-modules-source for
    Debian's 2.4.22 i386 kernel using Herbert Xu's patch.
                                                                                
    http://www.pocock.com.au/linux-doc/freeswan/freeswan-uml-debian/
                                                                                
Users of NAT traversal will be happy to know that the NAT-T patch has
been ported to 2.03. The port also features X.509 patch 1.4.7a. See this 
post:

    http://lists.freeswan.ca/pipermail/sfs-dev/2003-October/000368.html
                                                                              
A reminder to users who are experiencing technical difficulty and wish
to upload a FreeS/WAN barf for others' comments, but don't have a place to
do this: there's a publicly available utility to do so over at freeswan.ca.
FRAB, which stands for FreeS/WAN Read and Analyze Barf, allows users to post
barfs to the web without clogging the users' list with extra long mails.
See http://www.freeswan.ca/frab for more detail.


 ------------------------------------------------------------------------------
lists.freeswan.org Email Summary                         Tuesday, Oct 28, 2003



-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBP57RU3DIYXPDEHodAQHBVgQAlbAIBMSZInSn3ZfC509LSRF5T+EGcoUO
+PYlOXgOzNbqX9Yo/3G5G+7g1JNHmo0+ilm7XdyeuQh39vQHIUJLM87csQftFclP
Qs2W9GeEgFvHFSmT1tILoAQAFztil1HqpneUxjSUmdpMxffx5ylH7wlP+yDH3JGe
qii/D0TXmEM=
=uVHV
-----END PGP SIGNATURE-----