Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation

Jeffrey Hutzelman <> Tue, 21 December 2010 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A30DA3A6AAA; Tue, 21 Dec 2010 11:01:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 16h67Bq4jn5A; Tue, 21 Dec 2010 11:01:46 -0800 (PST)
Received: from (SMTP03.SRV.CS.CMU.EDU []) by (Postfix) with ESMTP id 703D63A6AF1; Tue, 21 Dec 2010 11:01:46 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id oBLJ3ekW003791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Dec 2010 14:03:40 -0500 (EST)
From: Jeffrey Hutzelman <>
To: Phillip Hallam-Baker <>
In-Reply-To: <>
References: <> <p06240809c928635499e8@> <> <> <> <> <> <> <> <> <2229.1292235952.971571@puncture> <> <2229.1292239384.281779@puncture> <> <2229.1292253372.639419@puncture> <>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 21 Dec 2010 14:03:39 -0500
Message-ID: <1292958219.2800.22.camel@destiny>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on
Cc: General discussion of application-layer protocols <>, websec <>, Common Authentication Technologies - Next Generation <>, "" <>, " Group" <>,, "" <>
Subject: Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Dec 2010 19:01:48 -0000

On Sat, 2010-12-18 at 16:48 +0000, Phillip Hallam-Baker wrote:

> As Web sites discover that their account holders cannot remember their
> username, most have adopted email addresses as account identifiers.
> That is what we should use as the basis for federated web
> authentication. 
> So if the user account identifier looks like, how
> does an entity verify that a purported user has a valid claim to that
> account?
> The obvious mechanism in my view is to use DNS based discovery of an
> authentication service. For example, we might use the ESRV scheme I
> have been working on:
>  ESRV 0 prot "_saml._ws"
>  ESRV 0 prot "_xcat._ws"
> Which declares that the SAML and 'XCAT' (presumably kitten in XML)
> protocols may be used to resolve authentication requests.

I see two fundamental technical problems with this approach:

1) It relies on unsecured DNS to be secure.  Particularly, you suggest
that, in order to discover a means to securely authenticate users
associated with some entity with which I have no prior relationship, I
should look up information about that entity in the DNS.  But DNSSEC is
not widely-deployed enough (yet) for that to be realistic.  Further, I'm
generally opposed to schemes that rely on the integrity of the DNS to
secure applications, because, at the enterprise level and below, the
operators of the DNS are frequently not entrusted with the security of
applications.  I mistrust any system which insists on forcing that to
change, while providing no recourse to those for whom such a policy is
unacceptable (and no, "advertise in the DNS whether to use the DNS" is
not such a recourse!).

2) It makes the assumption that my email service provider is interested
in providing authentication services to me, and that I'm interested in
giving them the ability to impersonate me to my bank.

I'd be much happier to see a model wherein, at registration time, I tell
a service my public key, and then it uses public-key cryptography to
authenticate me in the future.  Unfortunately, there are a number of
practical problems there, such as dealing with multiple clients per
user, kiosks, reinstalling machines, stolen credentials, etc., and it's
really preferable to avoid having every service provider deal with those
issues, rather than a much smaller number of authentication providers.