[abfab] Why we need Nico's text

Sam Hartman <hartmans@painless-security.com> Wed, 25 August 2010 13:29 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: abfab@core3.amsl.com
Delivered-To: abfab@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F653A69A2 for <abfab@core3.amsl.com>; Wed, 25 Aug 2010 06:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ieCBNm2DngS for <abfab@core3.amsl.com>; Wed, 25 Aug 2010 06:29:12 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 298E33A69AC for <abfab@ietf.org>; Wed, 25 Aug 2010 06:29:11 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 87F97202C7; Wed, 25 Aug 2010 09:29:42 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 70E4A4831; Wed, 25 Aug 2010 09:29:24 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: Eliot Lear <lear@cisco.com>
References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <tsl39u23ndk.fsf@mit.edu> <4C750E2B.9070703@cisco.com>
Date: Wed, 25 Aug 2010 09:29:24 -0400
In-Reply-To: <4C750E2B.9070703@cisco.com> (Eliot Lear's message of "Wed, 25 Aug 2010 14:35:55 +0200")
Message-ID: <tsl1v9m253f.fsf_-_@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: "abfab@ietf.org" <abfab@ietf.org>, Nicolas Williams <Nicolas.Williams@oracle.com>
Subject: [abfab] Why we need Nico's text
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2010 13:29:13 -0000

I'm noticing that the folks who have worked with GSS-API seem more
comfortable with Nico's text than the rest of the community.
Let me go through Nico's requirements and explain why they're needed in
order to accomplish our goals.

* Mutual authentication: Required by RFC 4462 in order to work with SSH
  and RFC 5801 for XMPP, SMTP, IMAP, LDAD, and the like.  You introduce
  MITM attacks for CALDAV, WEBDAV, ATOM and the like if you use GSS to
  authenticate without mutual authentication.

* Channel binding: required by RFC 5801 if we want to support IMAP,
  XMPP, LDAP, and the like.

* Per-message security services (gss_wrap, gss_get_mic, the like):
  Required by RFC 4462 if we want to support SSH. Required by
  NFS. Required by CIFS.
\
* Host based service naming: Required by RFc 4462 for ssh, RFC 5801 for
  XMPP, IMAP, SMTP, and the like. Required for CALDAV, WEBDAV, ATOM, and
  the HTTP protocols. Required by NFS. Probably required by CIFS
  although that's more complicated.

* gss_pseudo_random: Required by some of the JANET applications and by
  RXGK, the AFS distributed filesystem security class. This is less of a
  requirement than the previous items, although once you have
  per-message security, gss_pseudo_random is trivial.

* key confirmation: Required for channel binding to provide meaningful
  security.

So, if we don't meet Nico's requirements then we cannot actually work
with most of the applications we want to work with.

However, for me, that's not the most important motivation.  I've been
working on security systems that are more resistant to phishing than the
web for a long time. These technical requirements will meet the higher
level requirements necessary to provide the technical aspects of good
phishing defense. It happens these requirements are a fairly good
mapping of the most important issues discussed in
draft-hartman-webauth-phishing to non-web applications.  So, that's why
I personally care a lot about these issues and whether these are going
to be part of the solution significantly affects how good of an idea I
think doing the work is.  I can totally appreciate that someone might
disagree with me, but I hope you can understand why I care about the
issue.