Re: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements)

"Ben Laurie" <benl@google.com> Mon, 03 July 2006 13:51 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOpf-00049v-H5; Mon, 03 Jul 2006 09:51:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOpe-00049q-41 for dix@ietf.org; Mon, 03 Jul 2006 09:51:22 -0400
Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxOpS-00069c-60 for dix@ietf.org; Mon, 03 Jul 2006 09:51:22 -0400
Received: from vegeta.corp.google.com (vegeta.corp.google.com [172.24.0.3]) by smtp-out.google.com with ESMTP id k63DotDY026181 for <dix@ietf.org>; Mon, 3 Jul 2006 06:50:55 -0700
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=W9ePVZIR6z8vEJNMsDcXcMAaOwCaMCwRNM0GY35hEPCIUPlHjlUuQSfWOLSSwCZx0 XjHLY5isiFlgm55AjGYnw==
Received: from smtp-out2.google.com (fpx33.prod.google.com [10.253.24.33]) by vegeta.corp.google.com with ESMTP id k63DmK0t014366 for <dix@ietf.org>; Mon, 3 Jul 2006 06:50:46 -0700
Received: by smtp-out2.google.com with SMTP id 33so432101fpx for <dix@ietf.org>; Mon, 03 Jul 2006 06:50:46 -0700 (PDT)
Received: by 10.253.14.20 with SMTP id 20mr1268262fpn; Mon, 03 Jul 2006 06:50:46 -0700 (PDT)
Received: by 10.253.14.2 with HTTP; Mon, 3 Jul 2006 06:50:46 -0700 (PDT)
Message-ID: <1b587cab0607030650r344ddd1w6d3171dbb331fb8e@mail.google.com>
Date: Mon, 3 Jul 2006 14:50:46 +0100
From: "Ben Laurie" <benl@google.com>
To: "thayes0993@aol.com" <thayes0993@aol.com>
Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements)
In-Reply-To: <8C868351930B201-1384-5@FWM-R33.sysops.aol.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20060619220742.40B85222427@laser.networkresonance.com> <p07000c00c0c5023c5dc0@12.105.228.215> <1b587cab0606270525i7a10e0daic3988d426bf0a09d@mail.google.com> <44A16387.5040602@cisco.com> <8C868351930B201-1384-5@FWM-R33.sysops.aol.com>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org
X-BeenThere: dix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Digital Identity Exchange <dix@ietf.org>
List-Id: Digital Identity Exchange <dix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:dix@ietf.org>
List-Help: <mailto:dix-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=subscribe>
Errors-To: dix-bounces@ietf.org

On 6/27/06, thayes0993@aol.com <thayes0993@aol.com> wrote:
>
>
> I doubt it will be possible to use exactly the same methods for HTTP, XMPP,
> SMTP and IMAP.  The latter three (XMPP, SMTP and IMAP) are session based,
> and might require authentication/authorization only once during a session.
> HTTP is stateless (at least in general), so some thought needs to be given
> to extending the auth across multiple requests.
>
>  A method for HTTP will need to consider potential performance issues,
> replay protection, and possible tie-in with other available session state
> (such as a TLS channel), among other things.  The others can generally get
> away with a on-time verification step per session.
>
>
>  It may be possible to share portions of the mechanism.  In fact, TLS/SSL
> with client authentication supports all 4 protocols.  However it seems to be
> rejected because of other issues: PKI lifecycles, physical portability of
> the key, trust management, etc.

Assuming TLS is all about X.509 is completely missing the point. TLS
supports several other authentication mechanisms, such as pre-shared
secrets or Kerberos. There's nothing to stop us defining some new ones
if we need them.

>
>  Terry Hayes
>  AOL LLC
>
>
>  -----Original Message-----
>  From: lear@cisco.com
>  To: dix@ietf.org
>  Cc: ietf-http-auth@lists.osafoundation.org
>  Sent: Tue, 27 Jun 2006 9:57 AM
>  Subject: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web
> authentication enhancements)
>
>
>
> Ben Laurie wrote: >> >> - Does the mechanism use or extend currently
> deployed web >> authentication mechanisms (client side and server side)? If
> not, why >> not? > > No - because if you use web authentication, then it
> will not work for > protocols that are not HTTP based - XMPP and IMAP are
> obvious examples > that spring to mind. I'm not sure I'd go so far as No,
> but the mechanism or an analog must be easily ported to other application
> protocols such as XMPP, SMTP, or IMAP. I would think an existence proof of 2
> (one being HTTP; the other being IMAP) would be a very useful thing for any
> WG. Eliot ______________________________
> _________________ Ietf-http-auth mailing list
> Ietf-http-auth@osafoundation.org
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>  ________________________________
>  Check out AOL.com today. Breaking news, video search, pictures, email and
> IM. All on demand. Always Free.
>
> _______________________________________________
> Ietf-http-auth mailing list
> Ietf-http-auth@osafoundation.org
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>
>
>

_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix