IETF Logo Mail Archive

Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02

Nico Williams <nico@cryptonector.com> Fri, 08 April 2011 19:34 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6543A69EF for <kitten@core3.amsl.com>; Fri, 8 Apr 2011 12:34:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.943
X-Spam-Level:
X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 MUdF0xs2LDOs for <kitten@core3.amsl.com>; Fri, 8 Apr 2011 12:34:12 -0700 (PDT)
Received: from homiemail-a34.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 52BEA3A6975 for <kitten@ietf.org>; Fri, 8 Apr 2011 12:34:12 -0700 (PDT)
Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id E7AFC1006D for <kitten@ietf.org>; Fri, 8 Apr 2011 12:35:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=F+O/xOJewUdBORjUV5qV99LoGLh/tCdUXcK8DZob3sAj l0GAFYExX+9WY2iDXBychdRQ8uMgrDe0wDcWDRIDIJ2lacS8D6io0cy2EsE1rvQj fhKPE6h1hoTJ/4zU7nDiFlLNCopfb/EPaTQEQAk3l0/y1LjUlsiB3g9cGXd1J3Q=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=lQo9xSMye2/P+uGnxVHIWIy6E4U=; b=M2Qhabn6BJ5 BF7yDVeFz8TNaUjRA7ihMeeC4zHUdO1Diy26XZw2al67txpnReX6hbaS/9V9GlC1 iiDXKyYsuCD5TijvyVeqGl4yboU2Eva+ZulBV1aqsIGcSEmc/0c8JUkGwLCFH7Zz fMVkCV46gsjldoltfHnRfIMz7NlSM5Rg=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id C4C7210062 for <kitten@ietf.org>; Fri, 8 Apr 2011 12:35:57 -0700 (PDT)
Received: by vxg33 with SMTP id 33so3595992vxg.31 for <kitten@ietf.org>; Fri, 08 Apr 2011 12:35:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.1 with SMTP id eu1mr601567vdb.174.1302291357239; Fri, 08 Apr 2011 12:35:57 -0700 (PDT)
Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 12:35:57 -0700 (PDT)
In-Reply-To: <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu>
References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <tsl4o684s5q.fsf@mit.edu> <754979.46407.qm@web32303.mail.mud.yahoo.com> <tslr59c3asv.fsf@mit.edu> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <tslipuo378b.fsf@mit.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu>
Date: Fri, 08 Apr 2011 14:35:57 -0500
Message-ID: <BANLkTi=XyB7cAF7wmC0mjQKgNsbWhT7QgA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Cantor, Scott E." <cantor.2@osu.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "kitten@ietf.org" <kitten@ietf.org>, Simon Josefsson <simon@josefsson.org>, Tim Showalter <timshow@yahoo-inc.com>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 19:34:13 -0000

On Fri, Apr 8, 2011 at 2:27 PM, Cantor, Scott E. <cantor.2@osu.edu> wrote:
>> Unless I'm missing something (wouldn't be the first time) I think 1 and
>> 2 are sufficient for a non-HTTP use case.
>
> It's sufficient for a persistent connection. I think you answered the other case by mentioning cookies. Normally that has a fairly perjorative connotation, but since the client here isn't a browser (read browser as "security sinkhole"), such a cookie isn't a cookie in the "anybody can probably steal it" sense.

HTTP, by its nature, only really allows you to use cookies to tie all
the requests (and responses) that make up an application "session".
Ideally there'd be a little more to it.  For example, the application
could use TLS session IDs to map HTTPS requests and responses to
application sessions, but this is complicated (there could be many TLS
sessions mapping onto one application session, with new TLS sessions
added at any time) and not actually done in practice.  Or the client
and server could share an established GSS security context and place a
MIC in the request/response headers -- a MIC of the request/response
body, and maybe some security-sensitive headers.  But that's not the
HTTP that we have.  HTTP as it is and as we use it allows us only the
use of cookies for this purpose.

Fortunately we also have HTTPS, and we're talking about doing CB.  So
setting a secure-only cookie has been, is, and will continue to be a
reasonable thing to do to solve this particular problem.

Nico
--

v2.23.0 | Report a Bug | By Email