On Sat, 03 May 2008 19:50:01 -0400
"Perry E. Metzger" <[EMAIL PROTECTED]> wrote:
> Almost exclusively the use for such things is nailing up a tunnel to
> bring someone inside a private network. For that, there is no need for
> per user auth -- the general assumption is that the remote box is a
> single user laptop or something similar anyway. You really just want
> to verify that the remote host has a particular private key, and if it
> does, you nail up a tunnel to it (possibly allocating it a local IP
> address in the process). That solves about 95% of the usage scenarios
> and it requires very little configuration. It also covers virtually
> all use of IPSec I see in the field.
>
> Again, there are more complex usage scenarios, and it may be more
> complicated to set one of *those* up, but it is a shame that it is
> difficult to do the simple stuff.
>
So here's an interesting experiment. Part one: Take a common IPsec
implementation -- Linux, *BSD, Windows, what have you. Assume this
common scenario: laptop connecting to a corporate server. Assume a
user authentication credential. (I'd prefer that that be a public/
private key pair, for many reasons, not the least of which is the bug
in IKEv1 with main mode and shared secrets.) Do not assume a 1:1 ratio
between laptops and internal IP address, because such servers are
frequently underprovisioned. Challenge: design -- and implement -- a
*simple* mechanism by which the client user can set up the VPN
connection, both on the client and on the server. This part can
happen while the client is physically on the corporate net. Variant A:
the VPN server is a similar box to which the client has login-grade
access. Variant B: the VPN server is something like a restricted-access
Cisco box, in which case a trusted proxy is probably needed. User
setup should be something like 'configvpn cs.columbia.edu', where I
supply my username and authenticator. User connection should be
'startvpn cs.columbia.edu' (or, of course, the GUI equivalent); all I
supply is some sort of authenticator. Administrator setup should be a
list of authorized users, and probably an IP address range to use
(though having the VPN server look like a DHCP relay would be cool).
Experiment part two: implement remote login (or remote IMAP, or remote
Web with per-user privileges, etc.) under similar conditions. Recall
that being able to do this was a goal of the IPsec working group.
I think that part one is doable, though possibly the existing APIs are
incomplete. I don't think that part two is doable, and certainly not
with high assurance. In particular, with TLS the session key can be
negotiated between two user contexts; with IPsec/IKE, it's negotiated
between a user and a system. (Yes, I'm oversimplifying here.)
--Steve Bellovin, http://www.cs.columbia.edu/~smb
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
