[Sam Hartman] [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing
Sam Hartman <hartmans-ietf@mit.edu> Wed, 24 May 2006 16:19 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiw5C-0001Cp-Eo; Wed, 24 May 2006 12:19:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiw5A-0001CS-Pp; Wed, 24 May 2006 12:19:36 -0400
Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiw59-0007ZP-C2; Wed, 24 May 2006 12:19:36 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id ECC68E0074; Wed, 24 May 2006 12:19:27 -0400 (EDT)
To: saag@mit.edu, ietf@ietf.org, dix@ietf.org
From: Sam Hartman <hartmans-ietf@mit.edu>
mail-copies-to: ietf-http-auth@lists.osafoundation.org
mail-followups-to: ietf-http-auth@lists.osafoundation.org
Date: Wed, 24 May 2006 12:19:27 -0400
Message-ID: <tslu07fjsz4.fsf@cz.mit.edu>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae
Cc:
Subject: [Sam Hartman] [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
Hello. I'd like to draw your attention te the following BOF proposal. Please discuss on ietf-http-auth@ietf.org. I'd appreciate comments and indications of interest. I'd also like to draw your attention to two resources besides the BOF proposal: http://lists.osafoundation.org/pipermail/ietf-http-auth/2006-May/000241.html contains a better describption of what I think the BOF presentations should cover. http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-00.txt contains my comments on anti-phishing requiremnts and I hope will be a starting point for what it means for web authentication to be resistant to phishing. I believe that similar requirements should apply to other proposals including things in the DIX space.
--- Begin Message ---[Sent to the ADs; comments very much appreciated.] BOF Description: At IETF 65, the DIX BOF demonstrated a consensus to work on a solution to the problem that there are two many passwords for the web. This BOF proposes to develop a authentication architecture for the web and other HTTP-based applications using existing technology with at most small changes necessary to improve deployability that addresses this problem. One of the critical challenges facing the web today is the problem of phishing, where users are directed to fraudulent websites that request confidential information. Any solution to the phishing problem will require UI changes in web browsers. However the HTTP authentication architecture needs to work with these UI changes and provide clear technical requirements for the security features required from the UI. Proposed Charter: Web Authentication Resistant to Phishing (WARP) Applications Area Director(s): Ted Hardie <hardie@qualcomm.com> Lisa Dusseault <lisa@osafoundation.org> Applications Area Advisor: Lisa Dusseault <lisa@osafoundation.org> Mailing Lists: General Discussion: ietf-http-auth@lists.osafoundation.org To Subscribe: ietf-http-auth-requst@lists.osafoundation.org In Body: In Body: subscribe Archive: http://www.imc.org/atom-syntax/mail-archive/ Description of Working Group: WARP is chartered to develop a method for using existing authentication technology to address two critical problems with authentication for the web and other HTTP-using applications. The first problem is that users must remember and maintain passwords for each HTTP service they use. The second problem is that of phishing. While browser UIs must change in order to combat the problem of phishing, WARP must work with these UI changes and must provide clear technical requirements for the security features needed from authentication UI. WARP will attack the problem of multiple passwords in two ways. First, it will be safe from a security standpoint to use the same password with multiple HTTP services. Second, WARP will support the concept of an identity provider, which is a service that clients can authenticate to and that can make assertions about their identity to third parties. Employers authenticating their employees to business partners, distributed communities that share a concept of identity and services like Microsoft's Passport service demonstrate the wide variety of identity providers. There will never be a single identity that a user can use on the web: many users would not choose to use the same identity in a work context that they use personally; similarly business relationships and policies will dictate what identities services can accept. However WARP will support the concept of identity providers so that when policies permit, users can minimize the number of identities they use. WARP must support identity providers associated with servers and should support identity providers that have relationships with users. WARP needs to support mobile users, including users that use HTTP services from computers they have never used before. WARP must not require per-service or per-identity-provider configuration. While WARP is focused on passwords as that is expected to be the primary means of authentication, WARP needs to support other credentials including smart cards, one-time passwords and zero-knowledge password protocols. It is desirable that WARP be able to carry assertions about identity such as Security Assertion Markup Language assertions. The WARP working group will first write a problem statement and a requirements draft describing what it means to produce an authentication solution that is resistant to phishing. Then WARP will choose a mandatory-to-implement authentication technology and protocol for the interaction between the identity provider and website. WARP will coordinate with W3C in working on the UI implications of phishing. WARP will not propose specific UI nor specific extensions to HTML, although WARP may recommend requirements for both as these requirements directly impact the security or deployability of WARP. Deliverables: * Problem statement for WARP * Requirements for authentication resistant to phishing * WARP protocol document describing how an existing authentication system is used to meet the requirements of WARP. This document may specify mandatory to implement modes in addition to those specified in the underlying system. * A proposed standard describing how an identity is registered with an identity provider or website. * A proposed standard describing how an identity associated with a user is linked to an HTTP service's concept of an account. BOF Agenda (2.5 hour slot requested): * Presentation on the multiple passwords problem (10 minutes) * Presentation on phishing (30 minutes) * Presentation arguing that existing technology is available (30 minutes) * Description of Charter (10 minutes) * Discussion _______________________________________________ Ietf-http-auth mailing list Ietf-http-auth@osafoundation.org http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth--- End Message ---
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf