IETF Logo Mail Archive

Re: [websec] [saag] [http-auth] re-call for IETF http-auth BoF

Yutaka OIWA <y.oiwa@aist.go.jp> Wed, 15 June 2011 14:32 UTC

Return-Path: <yutaka-oiwa-aist-temp@g.oiwa.jp>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8234C11E8122; Wed, 15 Jun 2011 07:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.885
X-Spam-Level:
X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4V5d0z9ErsH; Wed, 15 Jun 2011 07:32:34 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC30111E80A9; Wed, 15 Jun 2011 07:32:33 -0700 (PDT)
Received: by yxt33 with SMTP id 33so441341yxt.31 for <multiple recipients>; Wed, 15 Jun 2011 07:32:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.13.17 with SMTP id 17mr870058ybm.394.1308148353251; Wed, 15 Jun 2011 07:32:33 -0700 (PDT)
Sender: yutaka@g.oiwa.jp
X-Google-Sender-Delegation: yutaka@g.oiwa.jp
Received: by 10.151.103.4 with HTTP; Wed, 15 Jun 2011 07:32:32 -0700 (PDT)
In-Reply-To: <BANLkTikTWE0Jj3GG=roqjq2-fsRZkm48yw@mail.gmail.com>
References: <BANLkTi=9TZU=pguCGhLHY+=GbCNjR6w-dA@mail.gmail.com> <E1QWLjG-0007nd-EG@login01.fos.auckland.ac.nz> <BANLkTikQ_FHo3_A8fNSDzzGk_puQwDKzTA@mail.gmail.com> <BANLkTikTWE0Jj3GG=roqjq2-fsRZkm48yw@mail.gmail.com>
Date: Wed, 15 Jun 2011 23:32:32 +0900
X-Google-Sender-Auth: qJq8zE8oN7vb9v05HcDSM661CcM
Message-ID: <BANLkTimn5MQtBpiFzkM2GyHHZbwyP7+HuQ@mail.gmail.com>
From: Yutaka OIWA <y.oiwa@aist.go.jp>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: http-auth@ietf.org, websec@ietf.org, public-identity@w3.org, saag@ietf.org
Subject: Re: [websec] [saag] [http-auth] re-call for IETF http-auth BoF
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2011 14:32:34 -0000

2011/6/15 Nico Williams <nico@cryptonector.com>:
>> * a method that hands over a password (or a password-equivalent)
>> * a method whose UI can be imitated by malicious sites.

> The protocol and UI are not that closely related.  I can't think of
> any method that satisfies the first requirement that couldn't have a
> secure UI.

How about a simple form-field extension which
encrypts some password with timed challenges?

OK, but your point suggests the following rephrasing:

 * a UI which can be imitated by malicious sites.

Although they are not closely related, but we cannot completely
ignore the UI issues . I think that protocol designs
should, in some extent, consider how such UI is to be provided
(especially when and how they are kicked in). How about it?

v2.39.1 | Report a Bug | By Email | System Status