Re: User interface, security, and simplicity

2008-05-07 Thread Victor Duchovni
On Wed, May 07, 2008 at 10:27:48AM +1000, James A. Donald wrote:

 Dynamic strings tempt people to forget about enforcing
 length limits and forget about correctly handling the
 case when the length limits are exceeded.

This too is dealt with. Message sizes are bounded, recipient counts
are bounded, duplicate elimination cache sizes are bounded, command
lengths are bounded, logical header lengths are bounded, body content
is processed 2K bytes at a time...

The requirement is stronger than just not running a single process out of
memory, the entire multi-process Postfix is designed to run in (realistic)
bounded memory (no fork: out of memory).

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-07 Thread Peter Gutmann
James A. Donald [EMAIL PROTECTED] writes:

In any program subject to attack, all strings should have known, documented,
and enforced maximum length, a length large enough for all likely legitimate
uses, and no larger.

Precisely.  An example of where dynamic strings can lead you is what happens
to old (very old) versions of Netscape when you feed them a cert with, say, an
MPEG of a cat in the X.500 DN.  Netscape happily accepts the cert but you then
have to reinstall the browser because while it'll quite readily accept
ridiculously long values it doesn't actually cope with them very well.  A
security component that's trivially taken out by a DoS isn't a security
component, it's a vulnerability.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-06 Thread Victor Duchovni
On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote:

 I believe that those who supply security products have a responsibility
 to consider the knowledge, experience, and tendencies of their likely
 users to the greatest extent to which they're able, and supply products
 which will function properly _as users are likely to apply them_.

The TLS support in Postfix tries to behave sensibly with easy setings.

- Cipher list selection is indirect, via grades: export, low,
medium and high. The actual ciphers for each grade are buried
in parameters users are advised to not mess with.

- The cipher grade for opportunistic TLS is export, but you single
out a destination for mandatory TLS, the grade rises to medium.

- The secure peer cert validation level compares the peer's cert to
the nexthop domain (allowing a sub-domain match by default). Hostnames
derived from MX lookups are of course subject to DNS MITM and are not
trusted.  If you want to trust your DNS you can use verify instead.

http://www.postfix.org/TLS_README.html#client_tls_limits
http://www.postfix.org/TLS_README.html#client_tls_may
http://www.postfix.org/TLS_README.html#client_tls_encrypt
http://www.postfix.org/TLS_README.html#client_tls_verify
http://www.postfix.org/TLS_README.html#client_tls_secure

- With the upcoming EECDH support, users don't choose curves
directly, they again choose a security grade, and the correspnding
curves are configurable via parameters they are not expected to
ever look at or modify.

If you don't botch your CAfile, it is rather easy to provision
secure-channel connections to a select set of high-value peers.

If you don't trust any CAs:

http://www.postfix.org/TLS_README.html#client_tls_fingerprint

once you have a system designed in all its features to behave sensibly
by default (e.g. with an empty main.cf file), making security behave
sensibly by default is not that unnatural.

So I think there should be a broad design bias towards *implicit* correct
behaviour in all system features, with rope available for advanced users
to *explicitly* craft more complex use-cases. Once you have that, practical
security is not too difficult.

The same is true in the source code, unsafe practices are avoided
globally, (e.g. both strcpy() and strncpy() are absent together with fixed
size automatic buffers) rather than used with care locally. I won't bore
you with all the implementation safety habits, but there are many.

-- 
Viktor.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-06 Thread Steven M. Bellovin
On Sun, 04 May 2008 11:22:51 +0100
Ben Laurie [EMAIL PROTECTED] wrote:

 Steven M. Bellovin wrote:
  On Sat, 03 May 2008 17:00:48 -0400
  Perry E. Metzger [EMAIL PROTECTED] wrote:
  
  [EMAIL PROTECTED] (Peter Gutmann) writes:
  I am left with the strong suspicion that SSL VPNs are easier to
  configure and use because a large percentage of their user
  population simply is not very sensitive to how much security is
  actually provided.
  They're easier to configure and use because most users don't
  want to have to rebuild their entire world around PKI just to set
  up a tunnel from A to B.
  I'm one of those people who uses OpenVPN instead of IPSEC, and I'm
  one of the people who helped create IPSEC.
 
  Right now, to use SSH to remotely connect to a machine using public
  keys, all I have to do is type ssh-keygen and copy the locally
  generated public key to a remote machine's authorized keys file.
  When there is an IPSEC system that is equally easy to use I'll
  switch to it.
 
  Until then, OpenVPN let me get started in about five minutes, and
  the fact that it is less than completely secure doesn't matter
  much to me as I'm running SSH under it anyway.
 
  There's a technical/philosophical issue lurking here.  We tried to
  solve it in IPsec; not only do I think we didn't succeed, I'm not at
  all clear we could or should have succeeded.
  
  IPsec operates at layer 3, where there are (generally) no user
  contexts.  This makes it difficult to bind IPsec credentials to a
  user, which means that it inherently can't be as simple to
  configure as ssh.
  
  Put another way, when you tell an sshd whom you wish to log in as,
  it consults that user's home directory and finds an authorized_keys
  file. How can IPsec -- or rather, any key management daemon for
  IPsec -- do that?  Per-user SPDs?  Is this packet for port 80 for
  user pat or user chris?
  
  I can envision ways around this (especially if we have an IP address
  per user of a system -- I've been writing about fine-grained IP
  address assignment for years), but they're inherently a lot more
  complex than ssh.
 
 I don't see why.
 
 The ssh server determines who the packets are for from information
 sent to it by the ssh client.
 
 The ssh client knows on whose behalf it is acting by virtue of being 
 invoked by that user (I'll admit this is a simplification of the most 
 general case, but I assert my argument is unaffected), and thus is
 able to include the information when it talks to the server.
 
 Similarly, the client end of an IPSEC connection knows who opened the 
 connection and could, similarly, convey that information. That data
 may not be available in some OSes by the time it gets to the IPSEC
 stack, but that's a deficiency of the OS, not a fundamental problem.
 
The problem is more on the server end.




--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-06 Thread Steven M. Bellovin
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]


Re: User interface, security, and simplicity

2008-05-06 Thread Jack Lloyd
On Tue, May 06, 2008 at 03:40:46PM +, Steven M. Bellovin wrote:

 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.)

Is there any reason (in principle) that IPsec/IKE could not be done
entirely in userspace / application space, though?

-Jack

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-06 Thread Nicolas Williams
On Tue, May 06, 2008 at 03:40:46PM +, Steven M. Bellovin wrote:
 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.)

Connection latching and connection-oriented IPsec APIs can address
this problem.

Solaris, and at least one other IPsec implementation (OpenSwan?  I
forget) makes sure that all packets for any one TCP connection (or UDP
connection) are protected (or bypassed) the same way during their
lifetime.  The same way - by similar SAs, that is, SAs with the same
algorithms, same peers, and various other parameters.

A WGLC is about to start in the IETF BTNS WG on an I-D that describes
this.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-06 Thread Victor Duchovni
On Tue, May 06, 2008 at 11:40:53AM -0700, David Wagner wrote:

 - With the upcoming EECDH support, users don't choose curves
 directly, they again choose a security grade, and the correspnding
 curves are configurable via parameters they are not expected to
 ever look at or modify.
 
 This struck me as poor design, not good design.  Asking the user to
 make these kinds of choices seems like the kind of thing that only a
 cryptographer could consider sensible.

They are not *asked* to make any cipher choices. The are able to make:

- no explicit choice, and get sensible default behaviour

- a high level choice (secure verification + high grade cipher
without having to spell out the gory details of what these mean.

- an exteremely detailed specification of all the details.

 In this day and age, software
 should not be asking users to choose ciphers.

The users in question are email administrators, not end users, and you
missed my point. They are not asked to choose ciphers, these are chosen
for them, and the default choice is even context dependent, so you get
sensible combinations of security properties:

- Opportunistic TLS allows SSLv2 and export ciphers

- Mandatory TLS, enforces SSLv3/TLSv1 and medium or high
ciphers.


 Rather, the software
 should just pick a sensible high-grade security level (e.g., AES-128,
 RSA-1024 or RSA-2048) and go with that

This is what is done (using OpenSSL's HIGH, MEDIUM, ... selectors).

 and avoid bothering the user.
 Why even offer low as an option?  (And this export business sounds
 like a throwback to a decade ago; why is that still there?)

You don't know how TLS is used with SMTP. Most TLS is opportunistic and
plain text is used if TLS is absent. In such an environment insisting
on 128 bits is silly, even 40 bits is better than plain-text.

 Good crypto is cheap.  Asking a user is expensive and risky.

Breaking interoperability by limiting cipher selection and causing mail
to queue is not cheap.

 So I think there should be a broad design bias towards *implicit* correct
 behaviour in all system features, with rope available for advanced users
 to *explicitly* craft more complex use-cases. Once you have that, practical
 security is not too difficult.
 
 Amen.  I know of quite a few software packages that could use more of
 that philosophy.
 
 The same is true in the source code, unsafe practices are avoided
 globally, (e.g. both strcpy() and strncpy() are absent together with fixed
 size automatic buffers) rather than used with care locally. I won't bore
 you with all the implementation safety habits, but there are many.
 
 It's too bad that today such elementary practices are something to brag
 about.  Perhaps one day we'll be lucky enough that the answer to these
 questions becomes more like of course we use safe programming practices;
 what kind of incompetent amateurs do you take us for?.

Practices are culture not technology, and it is difficult to displace
existing cultures with new ones :-(

-- 
Viktor.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-06 Thread James A. Donald

  The same is true in the source code, unsafe
  practices are avoided globally, (e.g. both strcpy()
  and strncpy() are absent together with fixed size
  automatic buffers) rather than used with care
  locally. I won't bore you with all the
  implementation safety habits, but there are many.

David Wagner wrote:
 It's too bad that today such elementary practices are
 something to brag about.  Perhaps one day we'll be
 lucky enough that the answer to these questions
 becomes more like of course we use safe programming
 practices; what kind of incompetent amateurs do you
 take us for?.

Dynamic strings tempt people to forget about enforcing
length limits and forget about correctly handling the
case when the length limits are exceeded.

There is no such thing as a string with no maximum
length, merely strings of UNKNOWN maximum length.  If
one has dynamic buffers and fully dynamic strings, it is
always possible for an attacker to discover the
previously UNKNOWN maximum length, and exceed it,
causing the program to fail in a manner likely to be
useful to the attacker.

In any program subject to attack, all strings should
have known, documented, and enforced maximum length, a
length large enough for all likely legitimate uses, and
no larger.

If enforcing length limits, it is frequently advisable,
and often necessary, to use, not strcpy or strncpy, but
routines such as _mbscpy_s, string manipulation routines
which can, and frequently do, employ buffers of fixed
and known length, sometimes pre-allocated fixed length.

In C++, incomprehensibly obscure functions such as
_mbscpy_s should never be called directly, but rather
called through a template library that automatically
does the sensible thing when the destination parameter
is a fixed length buffer, and can be relied upon to
object when commanded to do the stupid thing.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-05 Thread James A. Donald

Steven M. Bellovin wrote:
 IPsec operates at layer 3, where there are (generally)
 no user contexts.  This makes it difficult to bind
 IPsec credentials to a user, which means that it
 inherently can't be as simple to configure as ssh.

 Put another way, when you tell an sshd whom you wish
 to log in as, it consults that user's home directory
 and finds an authorized_keys file. How can IPsec -- or
 rather, any key management daemon for IPsec -- do
 that?  Per-user SPDs?  Is this packet for port 80 for
 user pat or user chris?

 I can envision ways around this (especially if we have
 an IP address per user of a system -- I've been
 writing about fine-grained IP address assignment for
 years), but they're inherently a lot more complex than
 ssh.

This is a particular case of the layer problem I have
been ranting about for years:  Private and authenticated
sessions at layer X do not in themselves correspond to
private and authenticated sessions at layer Y, and for
users to arrange their affairs so that layer X does
indeed secure layer Y generally requires users to stand
on their heads and stick their right big toe in their
left ear.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-05 Thread Ed Gerck

Ian G wrote: (on Kerckhoffs's rules)

=
6. Finally, it is necessary, given the circumstances that command its 
application, that the system be easy to use, requiring neither mental 
strain nor the knowledge of a long series of rules to observe.

=
...
PS:  Although his 6th is arguably the most important


Yes. Usability should be the #1 property of a secure system.

Conventional security thinking says that usability and security are 
like a seesaw; if usability goes up, security must go down, and 
vice-versa. This apparent antinomy actually works as a synergy: with 
more usability in a secure system, security increases. With less 
usability in a secure system, security decreases. A secure system that 
is not usable will be left aside by users.


Cheers,
Ed Gerck

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-05 Thread James A. Donald

Thor Lancelot Simon wrote:

And, in fact, most VPN software of any type fails this test.  My concern
is that an excessive focus on how hard is it to set this thing up? can
seriously obscure the important second half of the question and if you
set it up in the easiest possible way, is it safe?


If there is a wrong way to do it, the end user will do it wrong.  Expert 
cryptographers frequently fail to act correctly on their understanding 
of cryptography.  The end user has no chance - and the chances are still 
not all that good even if your end user is highly qualified cryptographer.


What users comprehend, and are used to, is you that set up an account 
with username and password, and an admin blesses the account with 
appropriate privileges as a result of some out of band communication - 
which username and password has to be secured, invisibly to the user, 
against offline and phishing attacks, without requiring any thought or 
vigilance by the user - see my web page for 
http://jim.com/security/how_to_do_VPNs.html for attacks on the 
password model, and defenses against those attacks.


This comes naturally to humans, for humans have long relied on 
shibboleths for security against treachery by outsiders.  Thus the 
computer interface to our clever cryptographic algorithms must resemble 
as closely as possible the ancient human reliance on shibboleths for 
security.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-04 Thread Ben Laurie

Steven M. Bellovin wrote:

On Sat, 03 May 2008 17:00:48 -0400
Perry E. Metzger [EMAIL PROTECTED] wrote:


[EMAIL PROTECTED] (Peter Gutmann) writes:

I am left with the strong suspicion that SSL VPNs are easier to
configure and use because a large percentage of their user
population simply is not very sensitive to how much security is
actually provided.

They're easier to configure and use because most users don't want
to have to rebuild their entire world around PKI just to set up a
tunnel from A to B.

I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one
of the people who helped create IPSEC.

Right now, to use SSH to remotely connect to a machine using public
keys, all I have to do is type ssh-keygen and copy the locally
generated public key to a remote machine's authorized keys file.
When there is an IPSEC system that is equally easy to use I'll switch
to it.

Until then, OpenVPN let me get started in about five minutes, and the
fact that it is less than completely secure doesn't matter much to me
as I'm running SSH under it anyway.


There's a technical/philosophical issue lurking here.  We tried to
solve it in IPsec; not only do I think we didn't succeed, I'm not at
all clear we could or should have succeeded.

IPsec operates at layer 3, where there are (generally) no user
contexts.  This makes it difficult to bind IPsec credentials to a user,
which means that it inherently can't be as simple to configure as ssh.

Put another way, when you tell an sshd whom you wish to log in as, it
consults that user's home directory and finds an authorized_keys file.
How can IPsec -- or rather, any key management daemon for IPsec -- do
that?  Per-user SPDs?  Is this packet for port 80 for user pat or user
chris?

I can envision ways around this (especially if we have an IP address
per user of a system -- I've been writing about fine-grained IP address
assignment for years), but they're inherently a lot more complex than
ssh.


I don't see why.

The ssh server determines who the packets are for from information sent 
to it by the ssh client.


The ssh client knows on whose behalf it is acting by virtue of being 
invoked by that user (I'll admit this is a simplification of the most 
general case, but I assert my argument is unaffected), and thus is able 
to include the information when it talks to the server.


Similarly, the client end of an IPSEC connection knows who opened the 
connection and could, similarly, convey that information. That data may 
not be available in some OSes by the time it gets to the IPSEC stack, 
but that's a deficiency of the OS, not a fundamental problem.


It seems to me there's no real difference between the two cases.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-04 Thread Ray Dillinger
On Sat, 2008-05-03 at 23:35 +, Steven M. Bellovin wrote:

 There's a technical/philosophical issue lurking here.  We tried to
 solve it in IPsec; not only do I think we didn't succeed, I'm not at
 all clear we could or should have succeeded.
 
 IPsec operates at layer 3, where there are (generally) no user
 contexts.  This makes it difficult to bind IPsec credentials to a user,
 which means that it inherently can't be as simple to configure as ssh.

Let me restate things just to make sure I understand the problem.
You're talking about binding IPsec credentials to a user, but 
I want to look at it from the point of view of exactly what 
problems this causes, so is the following an accurate position?

The problem is that we're trying to have entities with different 
security needs share a common set of authentications.  When user 'pat' 
and user 'sandy' have different security needs (different authorized
or trustable communication partners, to start with) we can't give 
them IPSEC because IPSEC operates on channels between machines 
rather than on channels between trusting/trusted entities.   Even 
if 'pat' and 'sandy' both have a trusted/trusting entity on a given
remote machine from theirs, IPSEC fails them because it cannot
differentiate between the various entities (users, agents, services)
using that remote machine, when 'pat' and 'sandy' need it to.  
Similarly, it fails the entities on that remote machine because it 
cannot differentiate between 'pat', 'sandy' and any other entities 
using the local machine, when trust relationships might exist only
for some subset of those entities.

Bear


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-04 Thread Perry E. Metzger

Jacob Appelbaum [EMAIL PROTECTED] writes:
 Perry E. Metzger wrote:
 Until then, OpenVPN let me get started in about five minutes, and the
 fact that it is less than completely secure doesn't matter much to me
 as I'm running SSH under it anyway.
[...]
 I'm always curious to hear what designers of protocols actually use on a
 daily basis. I'm also really curious how said designers evaluate their
 choices.

 I really like OpenVPN. It's really smooth to setup, it's very easy to
 use on the Big Three Platforms.

 Have you read the source to OpenVPN? Do you think that it's
 cryptographically sound? Is it properly implemented?

 I've found some stuff I wonder about and I'm curious if anyone else has?

I can't claim to like the innards, and it seems bizarre to me that the
designers didn't simply use IPSec encapsulated in UDP as the
underlying protocol. (Were I writing such a thing today, I might use
DTLS.)

That said, in my usage pattern, I don't care much about the possible
security flaws. I would not recommend the package to clients, however.

It is obvious to anyone using modern IPSec implementations that their
configuration files are a major source of pain. In spite of this, the
designers don't seem to see any problem. The result has been that
people see IPSec as unpleasant and write things like OpenVPN when the
underlying IPSec protocol is just fine and it is the implementations
that are unpleasant.

-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-04 Thread Thor Lancelot Simon
On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote:
 
 Steven M. Bellovin [EMAIL PROTECTED] writes:
  There's a technical/philosophical issue lurking here.  We tried to
  solve it in IPsec; not only do I think we didn't succeed, I'm not at
  all clear we could or should have succeeded.
 
  IPsec operates at layer 3, where there are (generally) no user
  contexts.  This makes it difficult to bind IPsec credentials to a user,
  which means that it inherently can't be as simple to configure as ssh.
 
 I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't
 do, and yet is is fairly easy to configure.

And yet there's no underlying technical reason why it is any easier to
configure than IPsec is; it is all a matter of the configuration interface
provided by your chosen SSL VPN (in this case, OpenVPN) or IPsec
implementation.

I find it amusing (but somewhat sad) that in fact one can find basically
the same set of flaws in each, but they're considered damning in IPsec
while they're handwaved away or overlooked in SSL VPNs.  Of course you
(Perry) or I can configure either IPsec or OpenVPN in a safe and sane way;
and, of course, there are some VPN packages of either type (IPsec or SSL
VPN) which have configuration interfaces so bad that we _couldn't_, in
fact, set them up safely -- because they prevent safe, sane configuration.

The problem is that whether you or I _can_ set software X up safely isn't
the question that matters.  The question that matters is _will_ a naive
user who does not understand the underlying security questions set software
X up securely.

And, in fact, most VPN software of any type fails this test.  My concern
is that an excessive focus on how hard is it to set this thing up? can
seriously obscure the important second half of the question and if you
set it up in the easiest possible way, is it safe?

Thor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-04 Thread Ian G

Perry E. Metzger wrote:


It is obvious to anyone using modern IPSec implementations that their
configuration files are a major source of pain. In spite of this, the
designers don't seem to see any problem. The result has been that
people see IPSec as unpleasant and write things like OpenVPN when the
underlying IPSec protocol is just fine and it is the implementations
that are unpleasant.



Kerckhoffs' 6th, providing great entertainment for the 
security world, since 1883.


=
6. Finally, it is necessary, given the circumstances that 
command its application, that the system be easy to use, 
requiring neither mental strain nor the knowledge of a long 
series of rules to observe.

=



iang


PS:  Although his 6th is arguably the most important, his 
others are well worth considering:


https://www.financialcryptography.com/mt/archives/000195.html

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-04 Thread Perry E. Metzger

Thor Lancelot Simon [EMAIL PROTECTED] writes:
 On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote:
 I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't
 do, and yet is is fairly easy to configure.

 And yet there's no underlying technical reason why it is any easier to
 configure than IPsec is;

Absolutely. There is no reason one couldn't build an easy to configure
IPSec. Indeed, OpenVPN could simply use IPSec if its authors wanted
to.

No one has created the easy to configure IPSec, however, so I don't
use IPSec for my own needs.

 I find it amusing (but somewhat sad) that in fact one can find basically
 the same set of flaws in each, but they're considered damning in IPsec
 while they're handwaved away or overlooked in SSL VPNs.

Myself, I don't handwave away said flaws. I don't recommend that
clients use OpenVPN, for example. On the other hand, most of my
clients can afford to pay admins to spend lots of time on this, and I
couldn't afford to spend the time myself.

 And, in fact, most VPN software of any type fails this test.  My concern
 is that an excessive focus on how hard is it to set this thing up? can
 seriously obscure the important second half of the question and if you
 set it up in the easiest possible way, is it safe?

Well, it is pretty easy to configure SSH safely. Set it to only use
public keys, copy your private key to the remote host in the
authorized_keys file, and you're more or less done. There is no reason
all the defaults can't be set up for a nice easy to use IPSec based
package in such a way that it requires a deliberate effort to make the
thing unsafe and it is more or less that easy to use.

Unfortunately, people just don't spend nearly the amount of time on
the UI for their IPSec systems that they do on the crypto, so they
spoil all the hard work they've done making the implementation sound
by making it impossible for ordinary people to understand.


-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-03 Thread Peter Gutmann
Thor Lancelot Simon [EMAIL PROTECTED] writes:

The upshot is that, indeed, at least as shown here, this particular
configuration frontend to OpenVPN is very easy to configure -- if you are
willing to settle for much less security than OpenVPN was designed to
provide,

I think you mean:

]... if you're willing to avoid a huge pile of pointless PKI cruft.

which is a major feature of OpenVPN.

I am left with the strong suspicion that SSL VPNs are easier to configure
and use because a large percentage of their user population simply is not
very sensitive to how much security is actually provided.

They're easier to configure and use because most users don't want to have to
rebuild their entire world around PKI just to set up a tunnel from A to B.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-03 Thread Jeff Simmons
On Saturday 03 May 2008 14:00, Perry E. Metzger wrote:
 Right now, to use SSH to remotely connect to a machine using public
 keys, all I have to do is type ssh-keygen and copy the locally
 generated public key to a remote machine's authorized keys file.
 When there is an IPSEC system that is equally easy to use I'll switch
 to it.

OpenBSD has recently added the ipsecctl command, which greatly simplifies 
setting up IPSEC VPNs, especially between OpenBSD machines. A config file can 
be as simple as (from the man page):

ike esp from 192.168.3.1 to 192.168.3.2
ike esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2

And the file structure for storing certs, public/private keys, and shared 
secrets (which ipsecctl searches automatically) is equally simple.

-- 
Jeff Simmons   [EMAIL PROTECTED]
Simmons Consulting - Network Engineering, Administration, Security
You guys, I don't hear any noise.  Are you sure you're doing it right?
--  My Life With The Thrill Kill Kult

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-03 Thread Steven M. Bellovin
On Sat, 03 May 2008 17:00:48 -0400
Perry E. Metzger [EMAIL PROTECTED] wrote:

 
 [EMAIL PROTECTED] (Peter Gutmann) writes:
 I am left with the strong suspicion that SSL VPNs are easier to
 configure and use because a large percentage of their user
 population simply is not very sensitive to how much security is
 actually provided.
 
  They're easier to configure and use because most users don't want
  to have to rebuild their entire world around PKI just to set up a
  tunnel from A to B.
 
 I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one
 of the people who helped create IPSEC.
 
 Right now, to use SSH to remotely connect to a machine using public
 keys, all I have to do is type ssh-keygen and copy the locally
 generated public key to a remote machine's authorized keys file.
 When there is an IPSEC system that is equally easy to use I'll switch
 to it.
 
 Until then, OpenVPN let me get started in about five minutes, and the
 fact that it is less than completely secure doesn't matter much to me
 as I'm running SSH under it anyway.
 
There's a technical/philosophical issue lurking here.  We tried to
solve it in IPsec; not only do I think we didn't succeed, I'm not at
all clear we could or should have succeeded.

IPsec operates at layer 3, where there are (generally) no user
contexts.  This makes it difficult to bind IPsec credentials to a user,
which means that it inherently can't be as simple to configure as ssh.

Put another way, when you tell an sshd whom you wish to log in as, it
consults that user's home directory and finds an authorized_keys file.
How can IPsec -- or rather, any key management daemon for IPsec -- do
that?  Per-user SPDs?  Is this packet for port 80 for user pat or user
chris?

I can envision ways around this (especially if we have an IP address
per user of a system -- I've been writing about fine-grained IP address
assignment for years), but they're inherently a lot more complex than
ssh.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-03 Thread Perry E. Metzger

Steven M. Bellovin [EMAIL PROTECTED] writes:
 There's a technical/philosophical issue lurking here.  We tried to
 solve it in IPsec; not only do I think we didn't succeed, I'm not at
 all clear we could or should have succeeded.

 IPsec operates at layer 3, where there are (generally) no user
 contexts.  This makes it difficult to bind IPsec credentials to a user,
 which means that it inherently can't be as simple to configure as ssh.

I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't
do, and yet is is fairly easy to configure. I believe that I could
easily come up with a simpler configuration still, but we have a
worked example, so I don't think we can claim it is impossible any
longer.

It is true that I can't make it easy to configure all possible
uses of IPSec easily, but it should be easy to do the easy things and
it isn't. If it was easy to do easy things and possible to do
complicated things, that would be a reasonable place to get to -- I
know of no IPSec configuration system that is like that.

 Put another way, when you tell an sshd whom you wish to log in as, it
 consults that user's home directory and finds an authorized_keys file.
 How can IPsec -- or rather, any key management daemon for IPsec -- do
 that?  Per-user SPDs?  Is this packet for port 80 for user pat or user
 chris?

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.

-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: User interface, security, and simplicity

2008-05-02 Thread James A. Donald

Thor Lancelot Simon wrote:

It's fashionable in some circles (including, it seems, this one) to bash
IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what
are basically user interface grounds.

I cannot help repeatedly noting that -- I believe more so than with actual
IPsec deployments, whether with or without IKE -- OpenVPN deployments are
often configured in hideously insecure ways.  This is no more the fault of
OpenVPN's designers, of course, than the ghastly configuration interfaces
imposed by many IKE impledmentations are the fault of IPsec's designers.


We are dropping on end users, sysadmins and nno crypto programmers 
decisions that seasoned cryptographers tend to screw up, and that end 
users and sysadmins are never going to comprehend.


The way programmers approach modularity and code locality tends to leave 
the end user outside the cryptographic boundary.  The cryptography 
module is very carefully made entirely independent of the user 
interface, merely sending up arcane errors from time to time.


Consider, for example, the recent cookie stealing security failure in 
Wordpress, fixed just a few days ago.  It seems that for a very long 
time, there was very straightforward, indeed in retrospect glaringly 
obvious, security hole that allowed anyone on the internet to take 
control of any host running Wordpress - which most hosts do run.  You 
can take control from Nigeria, you don't need to tap any lines.  Anyone 
anywhere in the world could have exercised any power over one's server 
that one's Wordpress application can exercise, which is usually near 
total power.


The defenders of SSL will quite correctly point out that the security 
hole had absolutely nothing to do with SSL.  The hole exists whether one 
uses SSL or not, and almost no one uses SSL with Wordpress.  And that 
was exactly the problem.  The writers of Wordpress, like the writers of 
every other application, had to handroll their own authentication, and 
of course fucked up.  SSL sessions are not user sessions, thus SSL 
authentication does not authenticate that user admin is the same 
entity (or even has the same  IP address) as the entity that correctly 
logged in as user admin, does not, cannot, attempt to provide such 
authentication, that being a higher layer issue - indeed, SSL 
authentication is pretty much irrelevant to authenticating anything that 
the attackers or defenders are likely to care about, which is why user 
admin on a Wordpress application does not use SSL.  SSL is so 
wonderfully localized that attackers just stroll around it.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]