Re: User interface, security, and "simplicity"

[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"

[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: New result in predicate encryption: disjunction support

[Scott Guthery]

Those interested in predicate encryption might also enjoy 

Group Authentication Using The Naccache-Stern Public-Key Cryptosystem 

http://arxiv.org/abs/cs/0307059

which takes a different approach and handles negation.

A group authentication protocol authenticates pre-defined groups of
individuals such that: 
- No individual is identified 
- No knowledge of which groups can be successfully authenticated is known to
the verifier 
- No sensitive data is exposed 
The paper presents a group authentication protocol based on splitting the
private keys of the Naccache-Stern public-key cryptosystem in such a way
that the Boolean expression defining the authenticable groups is implicit in
the split

Shamelessly, Scott

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

Re: User interface, security, and "simplicity"

[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"

[Perry E. Metzger]

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

Perry

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

Re: User interface, security, and "simplicity"

[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]

New result in predicate encryption: disjunction support

[Ivan Krstić]

This is fairly interesting: AFAIK the first generalization of  
predicate encryption to support disjunctions. I find the result mostly  
interesting mathematically, since I expect we won't be seeing  
predicate encryption in widespread use anytime soon due to complexity  
and regulatory concerns. --IK




"Predicate Encryption Supporting Disjunctions, Polynomial Equations,  
and Inner Products"

Jonathan Katz and Amit Sahai and Brent Waters

Preprint: 

Abstract: Predicate encryption is a new paradigm generalizing, among  
other things, identity-based encryption. In a predicate encryption  
scheme, secret keys correspond to predicates and ciphertexts are  
associated with attributes; the secret key SK_f corresponding to the  
predicate f can be used to decrypt a ciphertext associated with  
attribute I if and only if f(I)=1. Constructions of such schemes are  
currently known for relatively few classes of predicates.
We construct such a scheme for predicates corresponding to the  
evaluation of inner products over N (for some large integer N). This,  
in turn, enables constructions in which predicates correspond to the  
evaluation of disjunctions, polynomials, CNF/DNF formulae, or  
threshold predicates (among others). Besides serving as what we feel  
is a significant step forward in the theory of predicate encryption,  
our results lead to a number of applications that are interesting in  
their own right.


--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

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

Re: SSL and Malicious Hardware/Software

[Steven M. Bellovin]

On Fri, 2 May 2008 08:33:19 +0100
"Arcane Jill" <[EMAIL PROTECTED]> wrote:

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Phillips
> Sent: 28 April 2008 23:13
> To: Cryptography
> Subject: SSL and Malicious Hardware/Software
> 
> > I can't think of a great way of alerting the user,
> 
> I would be alerted immediately, because I'm using the Petname Tool
> Firefox plugin.
> 
> For an unproxied site, I get a small green window with my own choice
> of text in it (e.g. "Gmail" if I'm visiting https://mail.google.com).
> If a proxy were to insert itself in the middle, that window would
> turn yellow, and the message would change to "(untrusted)".
> 
Assorted user studies suggest that most users do not notice the color
of random little windows in their browsers...


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

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