Subject: [http-auth] Reboot: Protecting users and institutions from victimization by eavesdroppers & cyber criminals

From: Jim McAlear <[email-masked]>
Date: Wed, 28 Nov 2012 17:03:27 -0800 (PST)

Hi All -

Let me try to reboot this (in a way that tries to avoid election-campaign-like emotional button pushing):

Time after time, through efforts like: SSH, HTTPS and IPSEC and much more, the IETF has tried to protect users and institutions from victimization by network eavesdroppers and man-in-the-middle operators. But cybercriminals easily defeat our goals by implanting malware on servers and PCs – resulting in victimization on a massive, industrial scale. The aim of this contribution is to show that a solution to our longstanding goal is potentially within reach – and that if we carefully craft a new authentication procedure that is flexible enough to handle some novel hardware configurations, then we can finally provide users and institutions with our long-desired protection against victimization by cyber criminals – at least in the important areas of protecting critical credentials and transactions (safe e-commerce). The attachment outlines the solution at a high level.
 
Do you agree that this is a laudable goal? Questions/comments/next steps?
 
Jim McAlear
Ottawa, Canada

---

From: Nico Williams <[email-masked]>
Date: Fri, 30 Nov 2012 16:12:21 -0600

> Do you agree that this is a laudable goal? Questions/comments/next steps?

Local security is something that our protocols all assume: they extend
local security to the network, not the other way around.  This is true
of *all* of our security protocols: IPsec, SSHv2, TLS, Kerberos, SASL,
...  We work on protocols here, not so much local security, but we do
try to make our protocols easier to protect from local compromises.
For example, Kerberos has temporary credentials the compromise of
which is easier to recover from than the compromise of long-term
credentials; PKIX is amenable to smartcard and other token solutions.
This is all very nice, but sadly, that's about as far as we can go
with network protocols, maybe we can go as far as NEA (an attempt to
authenticate end-point state), combined with TPMs and OSes that are
amenable to secure bootstrapping with TPMs.

I'd like to separate what features we want in protocols to improve
security in the face of local compromises (namely, we want temporary
credentials and/or suitability for smartcards) from what we want done
for local security.  The two are very different fields of work that
barely intersect, and mostly only because we must assume that local
security will be compromised from time to time.

(Yes, I know, I mostly only dealt with client-side local security above.)

Nico
--